2938 Members
Join Permit's SlackChoosing how to represent an AI agent in enterprise IAM now feels like a deceptively small decision with outsized blast radius. One path says: treat the agent like any other workload, give it a service account, scope the token, rotate it, done. That is exactly where many teams start—and to be fair, it's where some mature teams still start. Starburst, for example, describes treating MCP clients as scoped service accounts with short-lived credentials and accountable owners in its federated query security model — an approach detailed in a Help Net Security interview on June 9, 2026.
At the same time, newer agent tooling is pulling in delegated identity on purpose. Codex access tokens are tied to a specific ChatGPT workspace user, not an org-wide shared key, and runs are associated to that user identity for governance — the Codex CLI v0.138 release analysis covers the governance rationale in detail. That is a major step forward.
But here's the engineering tension: both instincts are right, and both are incomplete. Scoped tokens solve who can start an agent and roughly what it can touch. They do not, by themselves, solve whether this exact action should execute right now. If your architecture stops at token issuance, you've moved risk around, not eliminated it. Scoped credentials still need runtime authorization.
A traditional service account model was built for deterministic software: daemons, CI jobs, sync workers. Those actors are predictable enough that static permission envelopes usually hold. AI agents are different because behavior is generated at runtime, tool choice is emergent, and context can mutate mid-session. You are not authorizing a fixed program path; you are authorizing a decision engine.
That's why service account vs AI agent is not a semantic debate—it's a control-plane design decision. A service account asks, "what system is calling?" An agent identity must answer: which human delegated this, for what purpose, in which context, with what trust level, using which tool right now?
In practice, this is agent identity vs machine identity. Both are non-human actors, yes, but only one routinely acts with delegated human intent.
Useful terms:
Let's give scoped credentials their due. They are mandatory baseline hygiene. Starburst's approach—MCP clients as scoped service accounts with short-lived credentials and explicit ownership—is exactly the kind of discipline enterprises need, as that Help Net Security interview makes clear. Codex access tokens being tied to workspace users and governance context is another concrete improvement over shared keys — read the Codex v0.138 release analysis for the full context. AWS AgentCore similarly focuses on audience-scoped token management through its Identity/Gateway layer, issuing downstream tokens scoped to specific tool invocations rather than sharing broad credentials with the agent runtime, as AWS's MCP integration post describes. Snowflake Cortex Code RBAC also demonstrates session-scoped execution under the invoking user's role, not magical privilege escalation — a point the Capgemini analysis of Cortex Code makes explicit.
So yes: scoping, expiry, ownership, and attribution reduce blast radius. They matter.
A robust agent token should include:
This is the part teams discover in production, usually after a "how did that happen?" incident review and a very quiet Slack channel.
Tokens are issuance-time artifacts. Agent risk is execution-time behavior. That gap is where failures live.
Before each failure mode, remember the core mismatch: a token scope says "may do X class of things." It does not judge whether this specific call is sensible under current reality. The agent can still do dumb things perfectly within scope—like an intern with a valid badge and catastrophic initiative.
A) Intent drift
You granted read/write to a project directory for "cleanup + refactor." The agent decides "obsolete" means "delete old migration files." Technically within scope. Operationally wrong. The token didn't fail; your control model did.
B) Risky tool call at runtime
Yesterday's granted scope includes table modification for planned maintenance. Today, incident response has frozen destructive changes. The token is still valid and still scoped. Without runtime checks, drop table is authorized by inertia.
C) Prompt injection
Hostile instructions embedded in docs can produce valid-looking tool calls. Starburst explicitly calls out prompt injection and keeps authorization at the query layer because the model is not the authorization layer — its federated query security discussion is worth reading on this point specifically. Scoped credentials do not inspect intent integrity.
D) Context changed mid-session
The user lost a role, consent was revoked, or trust posture was downgraded after suspicious behavior. Token expiry might be hours away. Authorization must adapt immediately; token lifetime cannot be your revocation strategy.
Now the crucial comparison: short-lived credentials vs zero standing permissions.
Short-lived credentials mean a grant exists, but expires soon. That's better than long-lived grants, but it is still standing privilege during the token lifetime. Zero standing permissions means there is no persistent broad grant waiting to be used; permission is derived just-in-time per action based on current policy and context.
This is also OAuth token vs runtime policy. The token carries coarse authority and identity context. Runtime policy decides, deterministically, whether this exact action on this exact resource right now is allowed.
In mature agent systems, each tool invocation is evaluated against: actor chain (human + agent), stated intent, requested action/resource, active context, live risk signals, and policy. If that sounds heavier than classic API auth, it is. So is post-incident forensics when you skipped it.
"Service account X called API Y" is acceptable logging for batch jobs. For agents, it's almost useless. You need enough structure to reconstruct delegation, intent, and enforcement decisions—not just network events.
The event model should capture the full chain: human delegator, agent identity/version, token metadata, stated intent/task, tool invocation details, policy decision, and outcome. If any of these are missing, attribution collapses into finger-pointing between model vendor, prompt author, platform team, and security.
Concrete example: on June 9, 2026, agent A-17 acting for user U-442 attempted delete_file on repo R-payments-ledger; token scope included repo write; policy P-risk-43 denied execution because session trust was downgraded after injection signal SIG-INJ-8821 and incident mode change_freeze=true.
That single record tells a real story. Without it, you get blame theater in high definition.
This is where Permit.io's agent-authorization approach is directionally right for enterprise deployment: bind each decision to the delegating human, the agent identity, intended task, target resource, and runtime trust level—then derive permission just-in-time from identity, intent, consent, context, and policy.
The Permit MCP Gateway is designed as the enforcement point between agents and tools, so authorization is evaluated when call_tool happens, not assumed from static token scope. The model explicitly frames runtime allow/deny per tool call with identity-aware attribution and trust-level controls—authorization as a decision that runs at execution time, not a grant that was handed out at session start.
That's the right architecture split: keep scoped tokens for authentication and coarse boundaries, but stop pretending token scope is authorization. It isn't. It's admission. Authorization is a runtime decision system.
Yes—for baseline machine authentication and coarse scoping. But not only service accounts. Agents acting on behalf of users need delegated human identity and runtime authorization on each sensitive action, because behavior is generated rather than deterministic, and token scope alone cannot substitute for a live policy evaluation.
Log the full chain: delegating human, agent identity and version, session ID, intent or task class, requested tool action and resource, policy decision with the specific rule that fired, and outcome. "Bot token called endpoint" is insufficient for forensic accountability and makes it nearly impossible to determine responsibility when something goes wrong.
Zero standing permissions is a model where agents hold no broad persistent execution privileges. Permission is computed just-in-time per action from current identity, policy, context, and risk signals — meaning no action is pre-authorized by default and every sensitive call requires a live evaluation before it executes.
At minimum: delegating user ID, agent ID, owner, purpose or task class, scope, expiry, trust level, session ID, and consent reference. Adding a jti or nonce prevents replay, and a policy version field helps audit which rule set was active at issuance, which matters when policies change between issuance and execution.
Machine identity (non-human identity or NHI) identifies a workload or service. Agent identity includes that workload identity plus delegation and runtime context: who delegated, for what stated intent, in what session or workflow, and at what current trust level. The difference matters for both authorization logic and audit attribution.
Prompt injection steers the model into producing malicious tool calls that still fit token scope syntactically. The token checks "is this an allowed class of action?" and answers yes, because the injected call resembles a legitimate one. Runtime policy can check whether this specific action makes sense given current intent, context, and trust posture — a semantic check the token itself cannot perform.
Short-lived credentials still grant standing access for a time window — the privilege exists and is usable until the token expires. Zero standing permissions grants no persistent action authority at all; each action is independently authorized in real time against live identity, policy, and context. ZSP eliminates the grant; short-lived credentials just put a countdown on it.
Co-Founder / CEO at Permit.io
