The first question
When an AI agent does something it should not, the first question is rarely about the model. It is simpler and harder: whose agent was it, who was it acting for, and who said it could do that?
The Medicare breach disclosed in September put that question in front of the Australian public. Which agent ran, under whose authority, and what was it permitted to access? Those are the questions any investigation has to answer first. It is not a uniquely Australian problem. It is what happens when software that acts on its own meets systems that were built to recognise people and servers, not delegated agents.
NIST puts agents on the standards agenda
When something goes wrong, the first question is rarely what the model did. It is whose agent it was, and who said it could.
In February 2026, NIST's Center for AI Standards and Innovation launched an AI Agent Standards Initiative, aimed at the interoperability and security of agents that act on people's behalf.
Alongside it, NIST's National Cybersecurity Center of Excellence published a concept paper on software and AI agent identity and authorisation on 5 February 2026. Public comments closed on 2 April 2026. The paper does not invent a new identity system. It looks at how existing standards could be combined, naming among others OAuth 2.0 and 2.1, OpenID Connect, SPIFFE and SPIRE for workload identity, the Model Context Protocol, SCIM for provisioning, and Next Generation Access Control.
It is also candid about what is unsolved. Two problems stand out: multi-hop delegation, where an agent calls another agent that calls a tool, and authority has to be provable at every step; and audit and non-repudiation, meaning records of what an agent did that its operator cannot later credibly deny.
The IETF drafts
At the Internet Engineering Task Force, several individual Internet-Drafts are exploring the same ground. Examples include draft-klrc-aiagent-auth, on authentication and authorisation for AI agents; draft-oauth-ai-agents-on-behalf-of-user, on how an agent can act for a user under OAuth with that delegation made explicit; and draft-aap-oauth-profile, an OAuth profile for agents.
Most of the building blocks already exist. The hard part is chaining them together across agents that call other agents.
These are early drafts. Internet-Drafts are work in progress, they can change completely or expire, and none of them is a standard. What they show is direction: the community is converging on extending OAuth and related protocols so that "this agent, acting for this person, with these limits" becomes something a server can check rather than assume.
Transparency logs grow up
A separate thread matters just as much. The IETF's SCITT work, on Supply Chain Integrity, Transparency and Trust, defines how signed statements can be registered in an append-only log and later verified. Its architecture was published as RFC 9943 in June 2026. SCITT was designed for software supply chains, but the pattern fits agents well: a signed statement about an agent, registered somewhere public, that anyone can check later.
Identity is not the whole answer
Identity answers "who". It does not, on its own, answer "what did they say this agent would do, and is that still true?" That is where public records come in.
Identity tells you who. A signed public record tells you what they said they would do.
The OCC Agent Record, the open format published at Open Conformance, is one attempt at that second half. Each listed agent has a stable identifier, an operator, a declared capability class and scope, a status that can be suspended or retired through T-RUE, and a record that is signed by the register so anyone can verify it has not been altered. The register signs with both a classical key and a post-quantum key. The verification tool is at openconformance.org/occ/verify-record, and the mappings to related formats are at openconformance.org/occ/interop.
An OCC record is not an identity credential and does not replace OAuth, workload identity or a SCITT log. It is designed to sit alongside them: identity systems tell a server who is calling; the public record tells everyone else what that agent was declared to be, by whom, and whether it is still active.
What to watch
Three things will decide how this settles. First, whether NIST's work turns into practical guidance that procurement teams actually ask for. Second, which IETF drafts gain working-group adoption. Third, whether delegation chains and tamper-evident records become expected by default, rather than bolted on after the next incident.
The next time an agent misbehaves, the organisations that can answer "whose agent was it?" in minutes rather than weeks will be the ones that planned for the question.
Sources & Further Reading
- 1.NIST Center for AI Standards and Innovation: AI Agent Standards Initiative
- 2.NIST NCCoE: Software and AI agent identity and authorization (concept paper)
- 3.IETF Internet-Draft: draft-klrc-aiagent-auth (work in progress)
- 4.IETF Internet-Draft: OAuth for AI agents acting on behalf of users (work in progress)
- 5.IETF SCITT working group: Supply Chain Integrity, Transparency and Trust
- 6.Open Conformance: verify a signed OCC record






