Identity Is Not Enough: Continuous Trust for AI Agents
This week I am presenting at SVCC 2026, the Silicon Valley Cybersecurity Conference, on a claim I think the industry is getting half right: agent identity. Ahead of the talk, I want to put the open specifications behind it in front of you, because the strongest argument is not a slide, it is something you can read and run.
We are good at answering who is this agent. We are not yet answering the harder question: is the agent I authorized five minutes ago still safe to act now. Identity is necessary. It is not sufficient.
Identity is a snapshot. An agent is a moving target.
We have known how to give a human an identity for decades: a password, a second factor, a session. We have known how to give a server one for even longer: a TLS certificate signed by an authority that any client can check. Both models assume the same thing. The principal you authenticated is the principal that keeps acting.
An AI agent breaks that assumption. The same agent, with the same permissions, behaves differently depending on its prompt, its memory, and whatever it just read on a web page. It can be talked into misusing a credential it legitimately holds. It can leak a secret simply by being asked nicely.
An identity check at the start of a session is a snapshot of something that changes by the minute.
Knowing who an agent is does not tell you whether it is still trustworthy, right now, for the action it is about to take. That second question, asked continuously, is the one the current stack does not answer. Answering it takes more than identity. It takes trust you can re-verify, and authorization that does not hand the agent a secret it could be talked into leaking.
What continuous trust actually requires
Break the question into parts, and a familiar shape appears. It is the security model the web already runs on, re-pointed from domains and servers to agents. The OpenA2A specifications are our attempt to write that model down as open standards.
The Agent Identity Protocol gives an agent a cryptographic identity, proves possession of the private key through a challenge-response, and expresses how far to trust it as a multi-factor score rather than a yes or no.
This is the TLS handshake, plus a trust calculation.
The Agent Trust eXtension is a signed, self-contained credential an agent presents and any party verifies locally, with no callback to an authority. It lives about seven days. The short lifetime is the point: it forces a re-scan and re-issue on a weekly cadence, so the credential always reflects a recent posture rather than a one-time blessing. Its signatures are hybrid, classical Ed25519 and post-quantum ML-DSA-65, present from day one.
This is the X.509 certificate for agents, with one deliberate difference.
The Agent Trust Protocol issues, verifies, and revokes those trust assertions, and records every change in an append-only Merkle transparency log compatible with RFC 6962. Anyone can audit it. Revocation is a new entry, never a quiet deletion.
This is Certificate Transparency, for agent trust.
The Agent Authorization Protocol lets an agent emit an abstract grant reference while a local broker resolves the scoped access behind a trust boundary. The credential never enters the model's context, so a hijacked agent has nothing reusable to leak.
This is OAuth token exchange, with the token kept out of reach of the thing that can be persuaded.
Underneath all of it, did:opena2a turns an opaque agent into a resolvable name that points at the key everything else verifies against. The thread connecting them is the word continuous. A short-lived credential is a trust decision that expires on purpose. A transparency log is a trust history anyone can audit. A broker is a check at the moment of access, not at the start of a session. None of these is a one-time gate.
Where these specs actually stand
This is a pre-release. I want to be precise about maturity, because for a security audience the honesty is the point. These are open specifications, and specs.opena2a.org groups every one of them by exactly where it stands.
did:opena2a is filed with the W3C DID method registry and under review. The OpenTelemetry semantic conventions for agent identity are proposed upstream and under discussion.
AIP, ATX, ATP, and AAP are complete documents with reference implementations, authored by OpenA2A and openly looking for external co-authors.
AIM is the platform that issues and enforces the chain. It is software, not a specification.
External adoption is early, and I am not going to pretend otherwise. For a security audience, being honest about maturity is a trust signal, not a weakness. If a piece of this should be a real standard, the page tells you where to come and help write it.
Do not take my word for it
The strongest argument here is not a claim, it is something you can run. specs.opena2a.org has an interactive lab where you step through each spec in your browser. The cryptography is real: tamper a field in the ATX credential and the Ed25519 verification fails in front of you. Watch the broker resolve a grant while the agent's context window stays empty. The point of the lab is that you should not have to trust a blog post about trust.
If you are building or securing agents, read the specs and tell me where they are wrong. That is the most useful thing you can do with them before they harden.
See it at SVCC 2026
I am giving the full version of this argument at SVCC 2026 in Silicon Valley this week: why identity is necessary and insufficient, and what continuous trust and scoped authorization look like when you build them as open standards. If you are there, come find me. If you are not, the specifications, the mapping to PKI, and the lab are all open.