ProvelyThe 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. |
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.