Hub
Analysis
Who sent this agent? The quiet race to give AI agents an identity
Digital IdentityAnalysis

Who sent this agent? The quiet race to give AI agents an identity

Standards bodies are working out how an AI agent proves who it is, who it acts for, and what it is allowed to do. The answers will shape every agent you meet.

ArchitectDarryl S Astin2 October 20268 min read

Key Insight: Agent identity is being built from existing parts, such as OAuth, OpenID Connect and workload identity, but two problems remain open: proving authority across several hops of delegation, and keeping records that cannot later be denied.

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. 1.NIST Center for AI Standards and Innovation: AI Agent Standards Initiative
  2. 2.NIST NCCoE: Software and AI agent identity and authorization (concept paper)
  3. 3.IETF Internet-Draft: draft-klrc-aiagent-auth (work in progress)
  4. 4.IETF Internet-Draft: OAuth for AI agents acting on behalf of users (work in progress)
  5. 5.IETF SCITT working group: Supply Chain Integrity, Transparency and Trust
  6. 6.Open Conformance: verify a signed OCC record
AI agentsagent identityNISTNCCoEIETFOAuthSCITTdelegationOCC Agent Record
The engine behind the Signal

Where this connects to Society OS

The Sovereign Intelligence Hub is the free, open front door of Society OS — the sovereign operating system that turns the ideas you just read into working governance. Where this piece names a problem, Society OS is building the machinery to solve it: AI agents that act with your authority, trust you can verify, and compliance that runs as code.

The 42-Protocol Stack

The governance engine beneath every article — led by the Sovereign Trinity: Human-Twin-Agent identity, HEARTrank trust, and WISE Contracts that execute law, not just code.

F-ACT — the open agent standard

The vendor-neutral framework for governing AI agents before they act: Grant, Usage, Audit, Revocation, Data — free to read, cite and implement.

The Sovereign Platform

Put it to work: govern a fleet of AI agents with verifiable authority, tamper-evident evidence, and compliance-as-code across your whole operation.

Explore membershipRead the F-ACT standard

Continue Reading

More from the Sovereign Intelligence Hub

Who Owns Your Identity? The Self-Sovereign Revolution and the eIDAS 2.0 Mandate
Digital Identity

Who Owns Your Identity? The Self-Sovereign Revolution and the eIDAS 2.0 Mandate

19 min read
Identity after the feed
Digital Identity

Identity after the feed

18 min read
The Quiet Pivot from IDs to Evidence
Digital Identity

The Quiet Pivot from IDs to Evidence

11 min read
The hard problem in sovereign identity is not proving who you are but who must accept it
Digital Identity

The hard problem in sovereign identity is not proving who you are but who must accept it

11 min read
Digital identity is becoming public infrastructure
Digital Identity

Digital identity is becoming public infrastructure

14 min
Digital identity is becoming critical infrastructure
Digital Identity

Digital identity is becoming critical infrastructure

14 min

Never miss a signal

Weekly intelligence, no noise

Governance Toolkit

The Evidence
92 % ungoverned
The Framework
GUARD chain
Your Risk
Sourced model
Self-Assess
No login required

The Sovereign Intelligence Hub — Society OS

© 1989–2026 Society OS Pty Ltd. All rights reserved.