At 2:14 on a Tuesday morning, an internal agent at a mid-sized logistics firm opened a support ticket, pulled a customer export, and pushed a config change to staging. Every one of those actions was permitted. Nobody could say who permitted them. The token it used belonged to a service account created in 2023 by an engineer who left the company in 2024, and the audit log recorded the actor as "automation-prod-07".
That is not a security failure in the way most boards understand the phrase. Nothing was breached. The system worked exactly as configured. It is an accountability failure, and it is now sitting inside a standards process at NIST rather than inside a vendor pitch deck.
AI agents are getting production access faster than anyone is issuing them identities. NIST opened a formal track on agent identity and authorization in February 2026. Enterprises that cannot name the human behind an agent action will fail their next audit, not their next penetration test.
Why this matters now
The industry already solved machine identity once. Workloads got certificates and CI runners got short-lived tokens, and everyone quietly agreed that a long-lived API key sitting in a repository was embarrassing. That model holds because a workload does one thing forever. An agent does not. It decides. It picks which tool to call and when to escalate. The thing it decides to do at 2am was not in the ticket that authorized it.
So the common advice, which is to give each agent a service account and move on, is wrong. Not slightly wrong. A service account answers "what is running." Agent identity has to answer four questions instead, and NIST wrote them down almost that plainly: what exactly is the agent, who delegated authority to it, what is it allowed to do, and how are its actions logged and constrained. The governance frameworks that decide which enterprises win with agents all assume those four answers exist. Almost nobody has them.
In February 2026 NIST's Center for AI Standards and Innovation announced the AI Agent Standards Initiative, with agent security and identity as one of three named workstreams. Alongside it the National Cybersecurity Center of Excellence published a draft concept paper, "Accelerating the Adoption of Software and AI Agent Identity and Authorization," and closed public comment on 2 April 2026. It does not invent a protocol. It stretches the ones already in the building: OAuth 2.1, OpenID Connect, SPIFFE and SPIRE for workload attestation, SCIM for lifecycle, NGAC for attribute-based access, and the Model Context Protocol for tool access. And it is blunt about the part vendors skip, asking how to bind agent identity to human identity for on-behalf-of scenarios, and demanding that agents log their actions and intent in a tamper-proof and verifiable manner. Meanwhile the credential surface underneath all of this keeps expanding, and the certificate rules governing it keep tightening on a schedule that has nothing to do with AI and no interest in waiting for it, which is the same structural pressure driving the post-quantum migration deadlines already running against your encrypted traffic.
Certificate lifetime
200 days
Ceiling since 15 March 2026
Shadow AI breach premium
USD 670,000
Added to average breach cost
Secrets leaked publicly
28.65 million
New on public GitHub in 2025
Machine to human ratio
109 to 1
Identities per employee today
The certificate number is the one that should worry an operations lead, because it is the only figure on that grid that is a hard deadline rather than a trend. The ceiling drops again in March 2027 and lands under seven weeks in March 2029, and at that point the window for reusing domain validation data shrinks to ten days. Manual renewal stops being slow and starts being impossible. Any agent that terminates or initiates TLS on your behalf inherits that clock, and if you cannot enumerate which agents hold which credentials, you cannot rotate them on the schedule the rules now require.
You are running more than a hundred non-human actors for every person on payroll, and almost none of them can tell you which human signed off on what they did last night.
What identity for an agent actually means
Strip away the protocol names and agent identity decomposes into six practical obligations. None of them is exotic. All of them are things your existing IAM stack does for humans and mostly fails to do for software that makes choices. The table below is the working checklist, and it is deliberately written as what you have to be able to prove, not what you have to buy.
| Category | Detail | Insight |
|---|---|---|
| Identification | Model, version, tool set, owning team | A name is not an identity |
| Authentication | Attested workload credentials, not static keys | Short lived beats secret and shared |
| Delegation | On-behalf-of chain back to a person | Authority must have a human origin |
| Authorization | Scope bound to task, not role | Least privilege per job, per run |
| Audit | Tamper-evident record of action and intent | Non-repudiation is the actual deliverable |
| Lifecycle | Provisioning, rotation, revocation on exit | Kill it faster than you built it |
Read down the Insight column and the pattern is uncomfortable. Five of the six obligations are things you can implement today with protocols that shipped years ago. Only the audit row really needs new work, because logging an agent's intent, meaning why it chose the action, is not something any existing standard captures well. That is where the standards effort will actually spend its time, and it is also the row your regulator will ask about first.
The NIST agent identity track moved from announcement to closed comment periods in seven weeks during early 2026, and the next milestone is a draft project description rather than a finished standard.
Where this breaks in practice
The first breakage is organisational, not technical. Identity lives with the security team, agents live with the platform or data team, and the person who actually authorized the agent to touch a customer record is a product manager who has never seen an IAM console. Palo Alto Networks' 2026 identity security survey of more than 2,900 security decision-makers found that disconnected identity systems add roughly 12 hours to the average identity-related incident. That gap is not spent fixing anything. It is spent asking who owns this thing.
The second breakage is that agents multiply credentials as a side effect of being useful. Every tool an agent connects to wants a key. Every connector config file becomes a place a key can sit. This is the same failure pattern that made verified caller identity such a fight in telecom, where operators had to be pushed into displaying the KYC name behind a number before anyone could trust who was calling. The lesson transferred badly. We are once again shipping systems that act on our behalf without a verified name attached.
And here is the part I am not sure about, which is worth saying out loud rather than hiding behind a framework. Should an agent hold a first-class identity of its own, or should it only ever borrow a human's? Giving it its own identity makes revocation clean and audit trails honest, but it also creates a permanent non-human principal that outlives the reason it existed. Borrowing keeps accountability tight and makes the agent disappear when the human leaves, but it collapses the moment an agent runs unattended for a week. I lean toward first-class identity with a mandatory delegation link, but I would not call that settled, and anyone selling you certainty on this in 2026 is selling.
Watch-outs before you buy anything:
- Any vendor claiming NIST compliance for agent identity is claiming compliance with a concept paper. There is no standard to comply with yet.
- Inventory before policy. If you cannot list every agent and the credentials it holds, a policy engine just enforces rules against the half you know about.
- Logging the action without logging the delegation is worthless. "Agent X deleted the record" is not an audit trail. "Agent X, acting for Priya, deleted the record under ticket 4471" is.
- Treat agent credentials as in-scope for your certificate automation programme now, not after the next validity cut lands.
Key takeaways
01. Access control, not model quality, is where agent deployments fail. IBM's 2025 breach research found 97% of breached organisations that suffered an AI-related security incident said they lacked proper AI access controls.
02. The credential surface is growing faster than the agents are. Leaked AI-service secrets on public repositories rose 81% year over year in GitGuardian's 2026 count, outpacing the overall secrets growth rate.
03. Start with the delegation link. It is the only obligation on the checklist that no tool can retrofit for you, because the record of who authorized what has to be captured at the moment it happens.
Pick your three highest-privilege agents this week, and for each one write down the human who authorized it, the exact scope it holds, and where its actions are logged. If you cannot complete that sentence for all three, you do not have an agent identity problem to plan for later. You have one now, and it is already in production.
No comments
Post a Comment