The agent holds the credentials that write. Provely holds separate credentials that read, where the provider permits a read-only key. No surface gives an agent the verifier credentials, and no surface returns a provider secret.
| Rule | What it means |
|---|---|
| Separate credentials | The agent writes with its key. The verifier reads with a restricted key that you store through POST /v1/connections. |
| Encrypted at rest | A stored provider credential is encrypted. The configuration never logs it. |
| Redacted telemetry | A provider response is redacted before it reaches a log or a span. |
| Short retention | Raw provider evidence is optional, encrypted, and kept for a short time. A receipt holds a digest, not a payload. |
| Signed webhooks | The runtime validates every event signature and drops a duplicate event. The contract reconciles a replay and a late arrival by the provider clock, not by arrival order. |
| The agent is untrusted | An agent report is evidence level E0. It can never support VERIFIED. |
Where do I store a verifier credential?
Open Integrations, then Connections, in the console. One connection names one provider account, and you give the credential that the verifier uses for it. Give a read-only credential wherever the provider permits one: Provely stores what you give and marks no credential as read or write. The console shows the events URL and the signing secret one time, on the screen that registers the connection. Give both to the provider.
Only a person with a browser session registers a connection. The control plane never issues the connections scope to an API key, so an agent that holds a key cannot read a stored credential, change one, or add one. The scope is marked not issuable in code.
How does an agent authenticate?
- An API key
pv_...in theAuthorizationheader, hashed at rest under a server pepper, with scopes, an expiry, and rotation. - Or an OAuth access token from the pinned issuer, with the scope checked on each call.
- The MCP server reads the bearer token inside each tool handler. No tool takes an API key as an argument.
- The CLI reads the key from its configuration file or the environment. There is no
--api-keyflag.
A receipt that verifies against a key embedded in the receipt proves nothing. The validator needs a trusted key map that you control. Read what a receipt proves.
Can Provely act on my provider account?
No. The runtime never performs the action. It reads. Where a provider offers a restricted read-only key, use one.
What reaches your servers?
The operation, the contract id, the correlation keys, and the observations the contract needs.