Beyond First-Class Agent Identity: The Four Tests That Actually Matter

What "treat agent identity as first-class" actually requires

It's easy to say an agent needs its own identity. It's much harder to answer four questions when that agent does something unexpected: who acted, what was it allowed to do, why did it take that path and how fast can you stop it. That's the actual test, and it's a harder one than naming an object in IAM.

In June, I wrote that organizations adapting to agentic systems "will treat agent identities as first-class identities, not inherited permissions. They'll capture execution context, not just individual events."

That was the right call. It was also where the piece stopped.

Telling a security leader to treat agent identity as first-class is the easy part. Much of what I heard at Black Hat said some version of the same thing. The harder question, the one that piece never answered, is what actually changes when you try to do it. What does a first-class agent identity have that an inherited one doesn't? What does "capturing execution context" mean on a Tuesday, in a real environment, with a real budget?

This is the follow-through.

Why the promise is harder than it sounds

A human identity is first-class because it's anchored to something stable: a person, a role, a manager or an offboarding process. The identity exists independent of any single action it takes. You can revoke it, audit it, reason about it, without knowing exactly what the person did last Tuesday.

An inherited permission, the kind a service account or an API key typically carries, works differently. It borrows trust from whatever created it and rarely gets re-evaluated once it's granted. Nobody expects a service account to explain itself. It does one thing, repeatedly, and that's the whole risk model.

Agents don't fit either pattern. They're not anchored the way a person is; there's no manager, no tenure, no offboarding checklist that was written with them in mind. But they're not static, the way a service account is either. An agent decides, mid-task, which system to touch next, and that decision is shaped by context that didn't exist when anyone configured its access.

That's the actual obstacle to "first-class." It's not that no one has built agent identity into their IAM platform. Plenty of vendors have added an object type. It's that identity was never the hard part. The hard part is that identity, on its own, was designed to answer "who is this and what are they allowed to do." Agents raise a question identity was never built to answer: why did this authorized actor choose this particular path, and does that choice still make sense given what it was asked to do?

You can give an agent a first-class identity and still have no way to answer that question. Which means the June piece's call to action, taken literally, is necessary but not sufficient.

Measuring the gap

If "first-class identity" and "captured execution context" are the goal, the honest next question is: how would you know if you'd actually gotten there? Not "do we have an agent identity platform," but something you could put a number on.

Four measurements do that:

• Time to attribute. Given an action in your environment, how long does it take to determine which agent took it and who authorized that agent to act?
• Time to revoke. How long is the time between a decision to cut off an agent's access and that access actually being gone, everywhere it was granted?
• Time to reconstruct. Given an outcome nobody expected, how long to rebuild the full decision chain, not just the final action, but the sequence of tool calls and context that led there?
• Coverage of continuous evaluation. What percentage of agent actions are checked only at the boundary, authentication and authorization, versus evaluated continuously as the sequence unfolds?

These aren't arbitrary. They're the same shape as the remediation-velocity metrics Chris Konrad laid out for vulnerability response, and the response-time metrics I wrote about in July: time to identify, time to validate, time to contain. Different problem, same underlying logic. Speed and completeness of response are what turn a stated principle into an operating one. An organization that can't measure time-to-attribute doesn't yet have first-class agent identity, regardless of what its IAM dashboard says.

What's already built to answer this

These four measurements don't require inventing something new. WWT's own reference architecture for securing agentic AI, "ARMOR in Practice: A Security Architecture for Foundation Models," lays out mechanisms built specifically to answer each one.

Time-to-attribute is addressed by treating every agent as a non-human identity, using SPIFFE/SPIRE, a real, vendor-neutral standard for cryptographic workload identity, and minting scoped, short-lived tokens just in time for each tool call. That binds access to a specific action rather than issuing one credential and trusting it indefinitely. The guide is blunt about the failure mode: if an agent shares the user's session token, containment is already lost.

Time to revoke has an actual, named mechanism: a graduated-response ladder running from L1 to L5. The lower tiers restrict or pause an agent; L4 is credential revocation, revoking the agent's tokens so it fails closed on its next action; L5 is a global kill, revoking credentials and halting the agent fleet-wide when a problem may be spreading. That's revocation as a designed, tiered capability, not a hope that access happens to be scoped tightly enough to cut off quickly.

Time to reconstruct comes out of the architecture's policy-enforcement model. A request passes through policy-enforcement points that intercept the interaction, a policy-decision point that evaluates it against context and a policy-information point that supplies the identity, data classification and risk signals behind that decision. Every one of those decisions gets logged in the SIEM as evidence, which turns agent permissions into auditable policy-as-code rather than scattered rules that nobody can reconstruct after the fact. The architecture extends this directly to multi-agent workflows: an agent-to-agent bus enforcement point authenticates and authorizes messages between agents using signed cards and mutual TLS, so a decision chain running through several agents remains attributable step by step, not just at the final action.

Continuous evaluation coverage is close to the whole point of the design. The guide frames the shift explicitly: the security question moves from "is this output acceptable?" to "is this action's intent aligned, and can I prove who did it?" Seven separate enforcement zones surround the model: input, memory, tool access, execution, output, network egress and agent-to-agent communication, each required to fail closed and emit telemetry. That's the opposite of checking policy once at the door and trusting the agent from there on.

One narrower framework is still worth borrowing from for a point this guide doesn't spell out as explicitly: independent verification. ARGUS, WWT's autonomous blue team framework, requires outcomes to be confirmed through telemetry separate from whatever system took the action, because trusting a system to grade its own homework is how you get a Three Mile Island. Applied to agent oversight, the same principle holds: don't let the agent's own logs be the only record of what the agent did.

What the market is already doing about it

WWT isn't alone in reaching for this. Zscaler, in its own account of joining Project Glasswing, described the model it's building for agents: every agent gets a verified identity, access to one specific application and a full record of what it did. That's a vendor's framing of its own product, not independent research, but it's a useful data point regardless: a major platform provider is describing the same identity-plus-audit shape as the answer, from a completely different starting point.

The comparison worth drawing from Black Hat is Tanium Atlas, built around governed agentic operations with operator-defined limits, approvals and auditability. Different vendor, different architecture, same underlying bet: that governance has to be built into the operating model, not bolted on after the agent is already acting.

Neither of these specifically validates ARMOR or ARGUS. What they validate is the shape of the problem. When a security vendor, a systems integrator and an infrastructure provider all converge on identity plus continuous audit as the answer, independently, that's a stronger signal than any one of them asserting it alone.

Where this leaves the June question

Treating agent identity as first-class was the right instinct. It just wasn't a complete answer on its own. A complete answer looks like this: an identity that can be quickly attributed, revoked cleanly, reconstructed after the fact and evaluated continuously rather than only at the boundary. WWT's reference architecture for securing agentic AI already builds toward exactly that, not as four scattered principles but as one enforcement model with a policy engine, a graduated response ladder and telemetry at every step.

The organizations that get this right won't be the ones with the most sophisticated agents. They'll be the ones that can answer, in minutes rather than days, who did this, why and how fast we can stop it happening again.

If you're trying to answer those four questions in your own environment, assessing your current state against ARMOR's Identity Security and Secure AI Operations domains can reveal where attribution and revocation are clean today and where they still rely on a shared credential and a promise.