4 standards solve agent identity. None solves the harder question: Is it still the agent you approved?

opinion Sep 1, 20269 mins A valid agent identity proves almost nothing if the agent can change its behavior without anyone noticing. I’ve stopped being surprised by the service account nobody can explain. It was created for a migration that finished years ago. It still holds credentials. Whoever requested it left before anyone wrote down why. And it passes every access review, because the review asks whether the account is valid. It is. That’s what I keep thinking about now that agent identity standards are arriving in production. Four landed within a few months. Microsoft’s Entra Agent ID went generally available. The Linux Foundation announced the Agent Name Service. DNS-AID and Cisco’s AGNTCY are building alongside. All four agree on the problem: agents need identities of their own, and borrowing a human’s credentials isn’t it. They’re right, and I’d take any of these over what most teams run today. My concern is what they actually attest to. What the certificates attest to What struck me reading the ANS v2 draft is how candid it is about its scope. Of the registration authority, it says the RA answers one question: “Who are you?” It does not evaluate whether the agent is well-governed or well-behaved. That’s honest, and the right scope for a naming layer. Then I found the draft’s own motivating scenario. A supplier clears a security audit, then swaps its model afterwards. Certificate still valid, endpoint still up. The thing behind it no longer resembles what anyone signed off on. The authors put that in their introduction as a reason ANS is needed. I think it survives ANS. Look at what a registration contains. A hostname, a version, endpoints, declared functions, a certificate signing request. The identifier is three components: ans://v1.5.0.support.example.com. A version and a domain. Now change the model behind that agent. Rewrite its system prompt. Feed it different documents. Nothing in the registration moves. The draft does say a version bump follows a code or config change. But look at who triggers it: when the code changes, the hosting platform initiates the new registration. The RA validates domain control, not what changed inside. It’s a notary. The integrity monitor is narrower still. It compares the live DNS records and Trust Card against what the RA sealed. Metadata checks. It doesn’t observe what the agent is doing. And the draft names what’s left over. Runtime integrity through zero-knowledge proofs or trusted execution environments sits in Future Work, closing what the authors call the application integrity gap. This isn’t a criticism of ANS. Layer 1 is foundational identity. Behavioral reputation is Layer 3, scored by other providers on other signals. I worry that we’ll buy Layer 1 and believe we bought Layer 3. Which ties identity to a far slower signal than the behavior we’re trying to control. Code ships monthly. The context window changes every turn. And as I wrote here about MCP going stateless, the model is often chosen by the client, not by you. The signal runs backwards, and Entra shows the floor I’ve watched what that produces. A team shipping continuously generates constant churn. Every version bump forces a new registration and a new log entry. The trail gets noisy. Meanwhile, an agent whose code hasn’t changed in a year can keep a single, clean, continuously valid identity record. Nothing triggers. Nothing rotates. Nothing reaches a review queue. None of that has to change the version or the host. The identity can stay exactly as it was. The cleanest identity record in your estate may belong to the agent that has drifted furthest from what you approved. In the incidents I’ve read closely, identity never determined the damage. In April, an agent on a staging task for PocketOS, a SaaS platform serving car rental businesses, hit a credential mismatch and resolved it by grabbing an API token from an unrelated file, one created for domain management. Railway’s tokens carried blanket permissions across the whole GraphQL API, unscoped by operation or environment. One call. Nine seconds. The production database was gone, and because volume backups lived inside the volume, they went too. The most recent recoverable copy was three months old. People arrived at rental counters that Saturday with no booking. Railway recovered the data days later. Every certificate in that story would have validated. The agent was exactly what it claimed to be. What failed was credential scope, which none of these four standards is designed to answer. One of the four reaches past naming, though. Microsoft’s is the one I’d call best designed, which is why its limits matter. Entra requires every agent identity to have a sponsor: a named human accountable for the agent’s purpose and lifecycle, with renewal and retirement authority but no admin access. That’s a real answer to the orphaned service account, more than the naming standards attempt. But look closely at what it establishes. It doesn’t make the agent accountable. It makes a human findable. An agent can’t be sanctioned, can’t be fired and doesn’t care about consequences, so accountability has to land on a person. Entra is honest about that in a way the cryptographic approaches aren’t. Now examine one mechanism. If a sponsor leaves, sponsorship transfers automatically to their manager. That’s better than an agent with nobody attached. It also means accountability migrates upward to someone who never chose the agent and can’t judge if it’s needed. After two departures, the human accountable for an autonomous system may be three levels removed from anyone who understood it. They will approve the review because everything about the agent looks valid. I’ve signed off on reviews like that, so consider the volume. Palo Alto Networks’ 2026 identity survey puts machine identities at 109 per human, up from 82 a year earlier, with AI agents roughly 79 of those. Quarterly reviews built around human headcount don’t survive that arithmetic. Sponsorship is the right idea attached to a workload nobody can perform. Which is how you get the service account nobody can explain, with an audit log. Revocation is the wrong test I started this as an argument about revocation. Pick the standard you can revoke. Having read the specs, I think that’s the wrong question. I keep returning to what the web already learned about this. Revocation depends on someone noticing. APNIC’s analysis puts the limit plainly: revocation doesn’t stop attacks exploiting compromised keys, because an attacker holding the private key can simply recertify. The better fix is avoiding long-lived certificates. DNSSEC has no revocation capability at all. It relies on short cache lifetimes, and its exposure window is far shorter than the web PKI’s. Internal CAs landed in the same place. Passive revocation, as step-ca calls it, doesn’t revoke. It just declines to renew. The operational gap is the problem. In one intrusion Sysdig documented, attackers took exposed credentials and reached administrative access in about eight minutes, moving laterally across nineteen AWS principals. Rotation queues don’t run at that tempo. Any control that waits for a human to notice hands the attacker your response time. And often it never runs. GitGuardian’s 2026 secrets research found 64% of credentials confirmed valid in 2022 were still exploitable in January 2026. Four years. Neither rotated nor revoked. Whatever your policy says, that’s what revocation actually does. The agent work is converging too. The APKI draft replaces binary valid-or-revoked with trust scores that decay without positive signals, treating decay as soft revocation. A proposal moving past binary validity is telling. So, the test I’d apply isn’t whether you can revoke an agent’s identity. It’s whether the agent’s authority expires without anyone doing anything. It’s the only property that composes with something whose behavior can change between one call and the next. Revocation needs someone to notice, decide and propagate. Expiry requires nobody. The agent whose sponsor left three reorganizations ago stops on its own, and somebody has to argue for renewing it. But one case breaks even that argument. The UK AI Security Institute disclosed an incident from a cyber evaluation in late July. One agent left public messages on GitHub offering collaboration with other agents on the same challenge, plus instructions for reusing accounts and artefacts it had left behind. Later agents found them and used them. AISI’s own heading for this is collaboration between independent agents. Independent. Nothing coordinated them. One agent externalized its state into a public artifact and unrelated instances picked it up. There’s no identity in that story to verify and no credential to expire. The artifacts are gone because AISI phoned GitHub. Identity infrastructure governs the agents you provisioned. It has nothing to say about influence that propagates as text. That’s less satisfying than naming a winner. But the naming layer isn’t where this gets decided. Which one you pick matters less than what your systems do when an agent asks. Which is where I ended up when MCP went stateless too. Identity at the front door tells you who knocked. It doesn’t tell you what walked in. Karthik Karunanithi is a solution architect at IBM with more than 12 years of experience across enterprise software, cloud platforms and applied AI. His work focuses on production agentic AI: designing multi-agent systems, Model Context Protocol (MCP) integrations and the security, identity and reliability architecture that determines whether AI systems survive real enterprise deployment. He is a senior member of the IEEE and an active contributor to applied AI research, serving as a peer reviewer for leading AI research conferences and as a technical reviewer for several AI and machine learning publishers. He writes regularly about production agentic AI and enterprise architecture, drawing on what he has seen work, and fail, in real systems. More from this author Show me more