In September, twelve companies, among them AWS, CrowdStrike, Google Cloud, Okta, Salesforce, ServiceNow, Wiz and Zscaler, formed the Blueprint Alliance and published an open reference architecture for securing AI agents. It's a good piece of work. It starts where we start: its first principle is that every agent is a distinct security identity, provisioned, authenticated and deprovisioned with the same rigor as an employee.
The blueprint organizes agent security around four questions:
- Where are my agents?
- What can they do?
- What are they doing?
- How do I respond?
There's a question underneath all four.
The question under the questions
Impersonation is about identity. Something claims to be a specific agent to a relying party, whether that's a website, an API, another agent, or a human. The question is: "Is this really Agent X?"
Every one of the blueprint's questions assumes you can answer it. An inventory of agents is only as good as your ability to tell them apart. A policy for Agent X protects nothing if another agent can present itself as Agent X. A kill switch stops the agent you aimed at only if a copy can't carry on in its place. The blueprint says it plainly: "A policy on an unregistered agent is a policy on nothing." The same holds for a registered agent you can't recognize.
The blueprint asks the question directly, in its Identity Substrate section: "What proves it's really that agent?" Today, for most agents, the honest answer is a credential. A shared API key, a service account, a token from someone's login. Whoever holds it is the agent.
Your AI agents have no identity of their own.
Two attacks, not one
There are two ways to be "not really Agent X", and they need different answers.
- Impersonation. A different agent claims to be Agent X, with Agent X's token, name or credentials.
- Cloning. Agent X's own code and credentials are copied to another machine. Same code, same keys, a different place. Copy an agent and you get the same code with a different fingerprint.
How Oathera answers it
Oathera gives every AI agent an identity bound to the machine it runs on, approved by a named person, and checked every time it acts.
Bound to its machine. The Identity MCP runs beside the agent and creates the agent's key on its own host. At enrollment, the identity service records the host. Every time the agent asks for a token, the host is observed again and compared with that record. In enforce mode a mismatch is refused, so a copied agent reporting a different host doesn't get a pass; in warn mode the pass is issued and the mismatch is flagged as a high-severity finding.
Accountable. A person approves each agent through the company's own identity provider, so every action traces to an agent and to the person who approved it. Revoke an agent and it gets no new pass, and its next call is refused. Deprovision a person and all of their agents stop, without touching the person's own sign-in.
Proven on every call. The agent's pass is short-lived (two minutes by default) and works only with a session key that lives in the agent's memory. Every operation carries a proof signed with that key, over the operation, its arguments and a one-time nonce. Steal the token and you can't use it; replay a proof and it's refused; change an argument after signing and it's refused.
Checked before it acts. The Gateway MCP sits in front of the company's tools. It verifies the proof, applies its per-tool policy, and asks the identity service for a signed decision on each enforced call: is the agent still active, and is the person who approved it still active. If no decision comes back, or it comes back late or unsigned, the call doesn't go through.
Fits what you run. Oathera works with your identity provider. It doesn't replace your IAM, your agent directory or your AI governance; it's the identity layer under them. People approve agents by signing in through your identity provider, and federation lets Microsoft Entra accept an agent's Oathera identity.
Where Oathera fits in the blueprint
The blueprint is a map of many controls, owned by many products. Here is where Oathera meets it.
| Blueprint control | What Oathera does |
|---|---|
| Agent Directory: register a governed identity | Each agent gets its own key, made on its host and proven at enrollment, and a person who approved it |
| Identity substrate: "what proves it's really that agent?" | The agent's key, its host, and a signed proof on every operation |
| Workload identity | Cloud instance attestation bound to the agent's key, verified on Google Cloud; a setting makes it mandatory |
| Governance metadata: status, risk tier, scope | Agent status (active, suspended or revoked), its operational scope, and host findings with a host confidence level on every pass |
| Time-bound access | Two-minute passes; gateway decisions that expire in seconds |
| MCP gateway / agent gateway: bind identity to every request | The Gateway MCP verifies the agent's proof on every call, with per-tool policy and a signed decision |
| Secret-less downstream credentials | The gateway sends the tool a short-lived, single-use assertion instead of a standing key |
| Token and session revocation; continuous authorization | Revoke an agent and it gets no new pass; each enforced call re-checks the agent and the person who approved it, and the agent's credentials when Oathera issues them as verifiable credentials |
| Joiner-mover-leaver | Deprovision a person and all of their agents stop; departures are learned from the identity provider |
| Tamper-resistant records captured at the execution boundary | Signed proofs from the agent, signed decisions from the identity service, and an audit log linked into a hash chain, sealed, verified and exported to a SIEM or WORM store |
| Delegation and inheritance | Bounded delegation from one agent to another |
| Contingent review (a person approves an action over a threshold) | A person's signed approval of one exact operation, bound to its arguments |
| Shadow-AI discovery via the governed execution path | The Gateway MCP refuses agents with no identity and lists them for review |
| Kill switch and access recovery | Suspend an agent, then reinstate it after its host is checked again, with reduced access first |
| Risk signals over SSF and CAEP | Publishing revocations and host changes as shared signals |
| Agent-to-agent verification across organizations | One agent checking another's identity |
Discovery of shadow AI on networks and endpoints, DLP, prompt-injection scanning, sandboxing and network quarantine belong to the security and platform tools beside us.
What we'd add to the blueprint
Three things would make its identity substrate concrete:
- Name the machine. An agent identity that isn't bound to where the agent runs can be copied. Host binding deserves its own line under "What proves it's really that agent?".
- Prove every call, not just the session. The blueprint names HTTP Message Signatures; say where they're required: on every operation an enforcement point accepts.
- Make cloning a named threat, and test impersonation on every call, not only as a finding in a configuration scan.
See it
Watch a stolen token fail, a replayed proof get refused and a tampered call get caught, in the simulator at sim.oathera.org. Our first design partners start in early November 2026. If you're putting agents into production, talk to us at oathera.ai.
Every AI agent, sworn in.