Models & Vendors
Models & Vendors
When an Agent Acts, Who Authorized It?

Most AI agents in production authenticate with whatever was convenient at setup time. Long-lived API keys. Unrevoked developer tokens. Shared service accounts. Every action either passes through an identity layer or it doesn't. Mostly, it doesn't.
Your buyers are circling this problem without calling it identity. NIST stood up an agent authorization project. CISA just named privilege creep and obscure audit trails as primary agentic risks. The MCP authorization spec has changed materially four times in eighteen months. The standards aren't settled, the hyperscalers aren't waiting, and the buyer planning an agentic deployment needs someone who understands identity lifecycle in the room while the architecture is being drawn.
When an Agent Acts, Who Authorized It?
Most AI agents in production authenticate with whatever was convenient at setup time. Long-lived API keys. Unrevoked developer tokens. Shared service accounts. Every action either passes through an identity layer or it doesn't. Mostly, it doesn't.
Your buyers are circling this problem without calling it identity. NIST stood up an agent authorization project. CISA just named privilege creep and obscure audit trails as primary agentic risks. The MCP authorization spec has changed materially four times in eighteen months. The standards aren't settled, the hyperscalers aren't waiting, and the buyer planning an agentic deployment needs someone who understands identity lifecycle in the room while the architecture is being drawn.

Your buyer's NHI conversation will touch three identity types: service accounts, automation bots, and AI agents. Vendors collapse them into one category. They shouldn't. What separates them is how cleanly you can answer "who authorized that action?" for each. Service accounts give you a strong answer that goes stale over months. Bots point to a process instead of a person. Agents give you an answer that starts degrading in seconds. Here's where the provenance chain holds, where it thins, and exact language for the field.

Agent authorization delegation looks like OAuth because it literally is OAuth — MCP assigns the same roles, uses the same token flows, enforces the same headers. Your mental model carries weight. But it breaks at a specific, structural point: OAuth assumes the client knows what it's going to do before it asks permission, and agents are figuring it out as they go. That single failure cascades into the scope problem, the consent problem, and an unsettled question about who is actually authenticated when an agent acts. Seven IETF drafts are working on it. Zero have reached RFC status. The breaks will surface in your next buyer conversation whether you're ready or not.

Your buyer's AI agents are authenticating with the same permissions someone configured when the demo first worked. Those scopes haven't been revisited since. Static roles can't account for non-deterministic behavior, and every security team briefed on agent identity knows it. The question landing in discovery calls right now: who decided the agent needed this level of access for this specific task, and is that decision auditable? Three approaches to scoping agent permissions are circulating in buyer conversations: static role assignment, dynamic attribute-based scoping, and JIT per-task elevation. What follows is what each does mechanically, where each fails, and the specific language that positions you as informed when the CAIO brings it up.

Your buyer's security team will map prompt injection onto session hijacking, CSRF, and XSS. That's the right instinct — each analogy illuminates something real about how the attack works. Each one also breaks at a specific point, and the break is where the conversation gets interesting. Session hijacking steals a credential. CSRF forges a request. XSS injects code into a trusted context. Prompt injection does something else entirely. The agent authenticates normally, retrieves content containing attacker instructions, and acts on them with its own valid credentials. The token stays valid, the request is genuine, the code is clean. The agent's intent gets hijacked while its identity stays perfectly intact. There's no clean fix. The defense model is containment.

When a CAIO asks about AI accountability, they're asking a forensic question across three distinct layers: traditional identity logging, agent orchestration, and model reasoning. Each has a different audit trail, and each degrades in a specific, predictable direction. Your IDAM audit instincts carry you cleanly through the first layer, partially through the second, and nowhere at all through the third. Knowing where each boundary falls is what keeps you from bluffing in that room.

You spent a decade helping customers kill static credentials. Vault-based rotation, dynamic issuance, the whole push. That fight is back. Every major agent framework ships with API keys in environment variables as the documented default. MCP's own spec recommends it for STDIO transport. Worse: agents can be tricked into outputting their credentials through prompt injection, an attack vector that doesn't exist for conventional apps. This piece covers how agents consume credentials mechanically, where your vault intuition maps cleanly to the problem, and the precise point where it breaks — when agents spawn credential consumers that no policy anticipated.

Zero trust for humans rests on four signals your buyers know cold: identity, device posture, network context, behavioral baseline. Each has a rough equivalent for AI agents. Each equivalent breaks in a specific, nameable place. Those break points are where your next conversation actually lives. Your buyer's CISO is in one of two camps. One says ZT principles are identity-type-agnostic — just onboard agents like any non-human identity. The other says agents introduce risks existing mechanisms can't reach, starting with the fact that a properly credentialed agent can be redirected by content it processes. This piece maps both camps so you recognize which one you're sitting across from.

Recap — Every AI Capability Is an Authorization Problem
Seven lessons. One question running through all of them: who authorized that? The agent's tool call, the token spend, the data crossing a jurisdiction boundary. This recap regroups everything from 3.1–3.7 around authorization provenance, organized by the mental models that hold up in a buyer conversation regardless of lesson order. Vocabulary collision tables map AI terms to the IDAM concepts you already carry. The frame at the end is the one worth taking into your next call with a CAIO who's excited about agents but hasn't thought about delegation chains.
