Identity tells you whose position it is. It does not tell you the trade already cleared.

Why Agentic Identity Matters Now

The identity vendors are right about the thing they are right about. An AI agent should be a first-class identity — issued, scoped, monitored, and revocable the way you revoke an offboarded employee’s badge. For years the industry treated service accounts and machine tokens as furniture; agents have finally forced the correction. Microsoft Entra Agent ID, Okta’s move into non-human identity, and the NHI specialists — Astrix, Oasis, Token Security — are all building the registry layer that agentic estates genuinely need. Registering the agent is table stakes. The mistake is believing registration is the control.

Here is the structural problem. Identity resolves at token time. Risk realizes at action time. Between the two sits an agent operating at machine speed, unattended, executing a plan the identity provider never sees. The IdP knows who asked. It does not know that the “who” just opened a labeled-sensitive file, spawned a shell, and pushed data to an egress endpoint — because none of that is an identity event. It is a kernel event.

Metric Figure Source
Mean time to identify + contain a breach ~258–292 days IBM Cost of a Data Breach 2024
Global average breach cost $4.88M IBM Cost of a Data Breach 2024
Unauthorized agent transactions from internal violations through 2028 ≥ 80% Gartner
Ospiri-observed enterprise exposure window 12–18 months Ospiri published research

Read that first row as a duration mismatch. Your detection-and-response clock runs in months. An over-permissioned agent’s blast radius runs in milliseconds. Identity governance is a control that settles T+258. The action already cleared.

Who the Agent Is vs. What the Agent Did

The cleanest way to price this is to separate the two questions and see which layer answers each. Identity is authoritative on the left column. It is silent on the right.

Question Answered by identity (IAM/NHI) Answered by runtime enforcement (kernel)
Who is this agent? Yes — issued credential, owner, scope No
Is the credential still valid? Yes — revoke like an employee No
Did it open the payroll repo? No Yes — file scope, mark-to-disk
Did it spawn an unsanctioned process? No Yes — process scope
Did it exfil to a new endpoint? Partially, via logs, after the fact Yes — network scope, inline
Can it stop the action mid-flight? No Yes — block or copy-on-write

Notice that every row identity answers is a statement about standing — the position exists, the position is valid. Every row the kernel answers is a statement about behavior — what the position did this instant. You cannot infer the second column from the first, any more than you can infer a day’s P&L from the account-opening paperwork.

The Revocation-After-Write Post-Mortem

The failure mode is not exotic. It is the default outcome when identity is your only enforcement point. Walk the sequence:

  1. An agent holds a valid, correctly-scoped token. Everything is compliant at token time.
  2. A prompt-injected instruction — or just an over-broad plan — tells the agent to read a confidential file and write a transformed copy somewhere it shouldn’t.
  3. The agent, acting at machine speed, does exactly that. The write is irreversible the moment it lands on disk.
  4. Behavioral analytics eventually flag the anomaly. Someone revokes the credential.
  5. Revocation prevents the next action. It does nothing about the one that already cleared.

Revoking a credential after an irreversible write is closing the trade after the loss is booked. The identity layer did its job perfectly — and you still took the mark. This is why “we can revoke agents like employees” is a necessary capability that quietly overstates what it buys you. You can fire the intern who leaked the file. The file is still gone.

Pricing the Gap: A Post-Token Exposure Score

If identity is settlement and the kernel is the trade, the exposure you actually carry lives in the window between them. You can size it. The factors below are the ones that compound — standing privilege multiplied by how irreversible the action is, plus how long the token lives multiplied by how far it reaches beyond the IdP’s sightline.

Post-Token Exposure = (Standing Privilege × Action Irreversibility) + (Token Lifetime × Off-IdP Reach)

Factor Low (1) High (5) Why it compounds
Standing Privilege Scoped, per-task Broad, persistent Bigger position, bigger blast radius
Action Irreversibility Read-only Write / delete / egress Realized loss vs. unrealized
Token Lifetime Minutes Long-lived / refresh Duration risk on an open position
Off-IdP Reach Cloud API only Local filesystem, stdio MCP The IdP cannot see what it cannot broker

The insight the formula forces: least-privilege per micro-task — the thing the identity vendors correctly advocate — reduces the first term but never zeroes it. Every micro-task still resolves to an allow-or-deny at some enforcement point. The question is only where that decision lands. For a cloud API call, the IdP can broker it. For a local agent — Cursor, Claude Desktop, a stdio MCP server reading your source tree — the decision lands at the kernel, below the protocol, where no identity provider has jurisdiction.

Two Layers, Not One

So, what’s the moral. Agentic IAM and runtime enforcement are not competitors; they are the identity graph and the enforcement substrate, and a serious estate needs both. The distinction is where each is authoritative.

Control point Authoritative on Blind to
Agentic IAM / NHI (Entra, Okta, Astrix, Oasis) Who the agent is; credential lifecycle; per-task scoping intent The action after the token resolves
Runtime enforcement (agent firewall, kernel) File / process / network actions; inline block or copy-on-write; kernel evidence Nothing about whose credential it was — it needs the identity graph for that
EDR (CrowdStrike, SentinelOne, Defender) Malware, known-bad binaries Sanctioned agents doing unsanctioned things

The two feed each other. The identity graph tells enforcement whose action it is; enforcement tells the identity graph what that identity actually did — the kernel ground truth that turns a revocation decision from a guess into an audited fact. Buy the IAM layer for the token. Buy the firewall for the action that follows it. Attesting to either alone under NIST AI RMF, SOC 2, or the EU AI Act is attesting to half the control.

What CISOs Should Do This Quarter

Step Action Output Effort
1 Inventory agent identities and their off-IdP reach (local FS, stdio MCP) A map of where identity loses sightline Low — connect IdP + endpoint
2 Score your top agents on Post-Token Exposure A ranked list of unhedged positions Low — the formula above
3 Put inline enforcement on the highest-exposure endpoints Block / copy-on-write at action time Medium — kernel agent on dev fleet
4 Wire kernel evidence back into the identity graph Revocation informed by actual behavior Medium — SIEM / SOAR integration

The Bottom Line

Registering an agent tells you whose position it is; it does not tell you the trade already cleared. Identity is necessary and it is not sufficient, because the credential resolves at token time and the loss realizes at action time — and the only control that lives at action time, for a local agent, is the kernel. Revocation is a post-mortem dressed as a control. The identity vendors are building something you need; they are simply not building the enforcement point, and no amount of per-task scoping changes where the allow-or-deny actually lands. Treat agentic IAM and runtime enforcement as two legs of one hedge, and you can say yes to agent deployment without carrying the tail risk unpriced.

If your team is sizing agentic identity for this budget cycle, request a working session. We will walk through your environment, map where identity loses sightline of the endpoint, and scope a runtime-enforcement deployment alongside your IAM rollout. Ninety minutes.

Related reading on Ospiri