A Threat Model for Agent Credentials, Written From What We Measured Rather Than What We Intended

What this document is and is not

There is no value behind these credentials yet, which is the only reason the gaps below are cheap today.

The assets, named plainly

An agent's signing key. A credential bundle, which is what lets its holder present. An operator's account. The passport token. The signed status document. A webhook signing secret.

Composition one: the key you exported is still ours

Three measured properties. The adapters default to managed custody, so the backend generates the key. The backend keeps it encrypted under a single escrow key. And the export path returns the key without deleting the stored copy.

Composed: exporting is not taking custody. An operator who exports, believing they now hold the key alone, is in exactly the position they were in before, plus a copy.

And a compromise of one escrow key exposes every managed agent key at once, which is a concentration the key-management disclosure does not currently name.

Mitigation available today: create agents with your own key explicitly. The adapters cannot do it for you, so it has to be a deliberate call before the adapter is involved.

Composition two: a leaked bundle is a permanent credential against a lenient verifier

This is the sharpest one, and none of its three parts says it alone.

The bundle is a bearer credential: there is no holder key binding, so possession is sufficient to present.

Credentials have no expiry: the table has an issue time and a revoke time and no expiry column, so nothing lapses on its own.

The status reference is supplied by the presenter: with none in the envelope, verification returns a valid verdict and an unchecked revocation state.

Composed: somebody who obtains a bundle holds a credential that never expires and whose revocation they can decline to have checked, against any verifier that reads only the headline field. Revocation works, and it only binds verifiers who require the reference.

Mitigation, and it is entirely the verifying side's: reject an envelope with no status reference, treat an unchecked state as failure, and treat a revoked verdict from either path as revoked.

Composition three: the proof covers less than the request

Over HTTP the proof binds method, path and time. Over a tool call it binds the tool name and not the arguments.

Composed with the acceptance window, a captured proof is reusable across different arguments to the same tool, which matters most exactly where tool arguments carry the consequential detail.

Mitigation: put the consequential distinction in the tool name, or issue your own challenge, which the package itself recommends for anything needing one-time semantics.

Composition four: revocation is fastest where it is least authoritative

A failed on-chain revoke leaves the live path saying active while the cached path says revoked, and nothing retries it.

So the path a careful integrator would choose for a consequential decision is the one that lies in the permissive direction during that window. Reading both is the only correct behaviour, and nothing in the library enforces it.

What the design gets right, at the same volume

Verification is offline, so a relying party's availability never depends on ours.

Status checks fail closed, and an unverifiable list is a distinct outcome from a revoked credential, so broken is never reported as bad.

Webhook delivery re-validates and pins the address at delivery time, which closes the gap between checking an endpoint and connecting to it.

Payloads and the public card are whitelists, so a new database column does not become an outbound field.

The public specification is generated against an allowlist, with a test that fails on any route outside it.

And revocation is ordered safely: the database first, so a partial failure leaves a credential revoked rather than accepted.

What we do not model

The operator's own infrastructure, their key storage, or the agent runtime itself.

The chains. Base and the networks the standard is deployed to are outside anything we could assess.

And the cryptography's own security margin, which is what an external audit would examine and we have not had one.