We Drafted an Open Standard for AI Agent Identity Before NIST Mandates It
The 12-month window is open. Here is the specification.
In February 2026, NIST released a concept paper calling for industry-led standards on AI agent identity and authorization. The paper was unusually direct: agents need cryptographic identities, every action needs non-repudiation, and the standard needs to come from the industry, not after the fact from a government body.
The window for building that standard is open right now. In 12–18 months, Anthropic, Microsoft, or Google will ship a proprietary version, and the ecosystem will fragment. The JWT moment for AI agents is happening, and nobody has written the RFC yet.
We wrote it.
The Problem Has a Name: Identity Laundering
Multi-agent systems have created a new attack surface that nobody has formally addressed. A parent agent (Orchestrator) spawns a child agent (Worker) and delegates capabilities. Without a cryptographic chain, the child agent can:
- Claim permissions were never granted
- Execute actions outside its authorized scope
- Break the audit trail entirely
When that child agent modifies a production file, rotates a credential, or calls an external API, you have no cryptographic proof of what it was authorized to do. You have a log entry. Log entries can be tampered with.
The enterprise security community has a name for this: identity laundering. An action is performed by “the agent” with no traceable connection to the human who authorized it.
What AIT Is
AIT (Agent Identity Token) is an open standard built on JWT (RFC 7519) that defines three token types:
AIT-S — Session Token Issued when an agent session begins. Defines who the agent is, what model it’s running, and what it’s authorized to do.
AIT-A — Action Token Issued for each atomic action: a tool call, a file write, a command execution. Cryptographically references the session token and includes the SHA-256 hash of the model’s active context window at the moment of action.
AIT-D — Delegation Token Issued when a parent agent spawns a child agent. References the parent session and explicitly defines which permissions were delegated and which were withheld.
The three tokens form a chain:
Human Authorization
│
▼
AIT-S (Session) ← parent agent, authorized by human
│
├──► AIT-A (Action) ← every parent agent action
└──► AIT-D (Delegation)
│
└──► AIT-A (Action) ← every child agent action
Every AIT-A traces back to a human authorization event. No orphan actions. No identity laundering.
The Context Hash: Closing the Substitution Attack
One field in the AIT-A payload deserves special attention: context.hash.
This is the SHA-256 hash of the model’s complete active context window at the time of the action. It closes a subtle but serious attack vector: context substitution.
Without context pinning, a malicious actor could show an agent safe data during planning, then substitute malicious content at execution time. The agent sees one thing, signs another. The audit trail is technically accurate but cryptographically meaningless.
With context.hash, the action is cryptographically bound to exactly what the model observed. Any substitution changes the hash and invalidates the signature. The audit trail is now meaningful.
Why RS256, Why JWT
The specification mandates RS256 (RSA Signature with SHA-256) for v0.1. The reasoning:
RS256 over ES256: Wider library support across enterprise environments. Every language ecosystem has RS256 support. ES256 support is improving, but not universal. We will add ES256 as an option in v0.2.
JWT over a custom format: JWT is already understood by every security team. It has a well-defined header, payload, and signature structure. The verification logic is standard. AIT adds semantics on top of JWT — it does not reinvent the wheel.
Offline verifiable by design: A compliant AIT verifier needs only the issuer’s public key. No network call, no central authority, no cloud service. This is non-negotiable for enterprise adoption, where agents may operate in air-gapped environments.
The NIST Alignment
NIST’s February 2026 concept paper on “Accelerating the Adoption of Software and AI Agent Identity and Authorization” identified three requirements for AI agent identity:
- Persistent cryptographic agent identifiers
- Non-repudiation for agent actions
- Verifiable delegation chains for multi-agent systems
AIT addresses all three. The spec was designed to align with the NIST AI Risk Management Framework and ISO/IEC 42001. We intend to submit AIT as an industry-led proposal in the NIST public comment process.
The Open Standard Commitment
AIT is published under CC0 1.0 Universal — public domain. No patent claims, no proprietary extensions, no Depwire lock-in. The goal is a standard that any tool, platform, or AI provider can implement independently.
The reference implementation is Depwire CLI — a deterministic dependency graph tool for AI coding assistants. But the spec is designed so that Claude Code, Cursor, GitHub Copilot Agent, or any other tool can implement it without referencing Depwire at all.
This is the JWT model: a small group writes the spec, the ecosystem adopts it, and the originator is just one of many implementations.
Status and Next Steps
AIT v0.1.0 is a draft RFC open for public comment.
Spec: github.com/depwire/ait-spec JSON Schemas: github.com/depwire/ait-spec/tree/main/schemas Reference implementation: github.com/depwire/depwire
We are actively seeking feedback on:
- The three-token architecture
- The scope inheritance rules for delegation
- The context hashing algorithm
- Key management guidance for v0.2
If you are building AI coding tools, agentic systems, or enterprise AI governance infrastructure — this standard is designed for you. Open an issue, open a PR, or fork the spec and propose changes.
The window is open. Let’s build the standard together before it gets built for us.
AIT Specification v0.1.0-draft — github.com/depwire/ait-spec — CC0 1.0 Universal