IETF drafts put AI-agent identity inside X.509 certificates

IETF drafts put AI-agent identity inside X.509 certificates

by

On 2 October 2026 the IETF published updated Internet-Drafts that would carry an AI agent’s identity, its authority and an emergency stop inside an X.509 certificate — the same kind of certificate that already proves a website’s identity. The aim is that any service can recognise, authorise and, if needed, halt an agent regardless of who deployed it or what software runs it.

These are Internet-Drafts — public work-in-progress documents, not standards. They can change or expire (the two below expire in April 2027), and dozens of agent-identity drafts are circulating. Read them as a direction of travel, not a ratified specification.

What was published

Two of the drafts updated on 2 October 2026 are the most directly relevant to Know Your Agent:

  • X.509 Certificate Profile for Autonomous AI Agent Identity (`draft-sharif-x509-agent-identity-profile-04`), by Raza Sharif of CyberSecAI Ltd. Intended for the standards track.
  • AI Agent Identity Certificate (AIC) Extension for X.509 v3 (`draft-wei-aic-identity-cert-02`), by J. Wei. Experimental, with a companion JWT profile (`draft-wei-aic-jwt-02`) for clients that cannot present a full certificate.

A related draft, the OpenA2A Agent Identity Protocol (`draft-fane-opena2a-aip-03`), also updated around the same time.

The Sharif profile: an AgentIdentity extension

The Sharif draft adds a new, non-critical X.509v3 extension called AgentIdentity that any certificate authority could issue. It carries:

FieldMeaning
`trustLevel`Integer 0–4: unknown, registered, verified, trusted, critical. A ceiling the agent must not exceed.
`capabilities`Named permissions such as `read_data`, `pay`, `deploy`.
`ownerOrganization`The organisation accountable for the agent.
`platformIdentifier`The platform that manages the agent’s lifecycle.
`maxDelegationDepth`Maximum number of further delegation hops.
`killSwitchURI`Endpoint that halts the agent immediately and irrevocably.

The design builds on existing PKI (RFC 5280) and SPIFFE workload identities rather than replacing them, and it is deliberately CA-agnostic: the certificate is meant to be parseable and enforceable regardless of which CA issued it. The certificate’s trust level is a maximum — a platform may enforce a stricter one, never a looser one. The kill switch is specified to fail closed: if the endpoint is unreachable, the platform must treat the agent as revoked rather than let it keep running.

The draft’s own introduction offers a striking estimate: that in 2026, 70% of enterprises report having agents in production, yet only 21.9% treat those agents as independent, identity-bearing entities. That figure is the draft’s own claim, not an independent statistic.

The Wei AIC extension: binding the agent to a principal

The Wei draft takes a complementary angle. Its AIC extension creates a cryptographic binding between the agent and the person or organisation that authorised it — the principal. It encodes an agent identifier, a principal identifier, and a delegation mode:

  • Authorized — the agent acts under its own identity, with the principal’s consent.
  • Representative — the agent acts on the principal’s behalf, carrying a signed authorisation from that principal.

It also carries a capability declaration, authorisation-boundary constraints (such as an IP range and a time window) that can be verified offline, and replay protection on the delegation evidence. The draft deliberately separates cryptographic delegation from authorisation semantics: the certificate proves the cryptographic link between agent and principal, while capability and policy meaning is left to vendors, industries or regulators.

A practical consequence: the authorisation decision can be made entirely on public-key infrastructure, without calling a separate user-management system — useful in closed or offline environments.

One rule both drafts share: delegation can only narrow

Both drafts encode the same principle that runs through all of KYA: delegation may only narrow authority, never widen it. When an agent creates a sub-agent, the sub-agent can hold at most the rights its creator held.

Sharif’s model enforces this by requiring the delegation depth to strictly decrease at every hop, so a chain always terminates. Wei’s model speaks of a permission intersection, and recommends a single hop from principal to agent; longer chains are possible but blur accountability, so the draft leaves them out of scope.

Why it matters for KYA

This is the KYA thesis moving into the certificate layer. If drafts like these are adopted, a relying service could validate an agent much as it validates a TLS certificate today: offline, against a chain of trust, and independent of the platform that provisioned the agent. Identity, principal, scope, revocation and audit attribution — the pieces KYA asks for — would be carried in one artefact.

It maps cleanly onto the vocabulary this site already uses: agent identity, the agent passport, scoped credentials, revocation and audit trails.

Not yet a standard

Both documents are individual submissions, not IETF working-group documents. A wider effort is underway alongside them: the IETF’s WIMSE working group now has a document on agent identity, and the US NIST’s NCCoE has been working on agent identity and authorisation in its own project.

There is still no single, agreed standard. The next question is which drafts move into working-group process and eventually become RFCs. Until then, organisations are solving agent identification with their own arrangements.

Sources

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.