Ship AI without shipping risk.
blog

Four Things Your Identity Stack Needs Before Agents Hit Production

Four primitives your identity stack needs to govern AI agents in production: an identity-aware proxy, credential vaulting, scope minimization, and first-class revocation.

Kevin PaigeKevin Paige, Field CISO

Share

Four Things Your Identity Stack Needs Before Agents Hit Production

I've had some version of the same conversation with about thirty security leaders over the past six months. It always starts the same way: "We know we need to govern our AI agents. We don't know what the stack looks like."

Fair question. The market is noisy. Every vendor has a slide that says "AI-native" and a diagram with too many boxes. So let me cut through it. Whatever stack you eventually pick — buy it, build it, wrap what you have — these are the four primitives it has to have. Miss one and you have a gap. Miss two and you have a breach waiting to happen.

Primitive 1: Identity-aware proxy#

Every agent tool call gets authenticated, permission-checked, and logged with full identity context, in real time. Not batch. Not at the identity provider. At every call.

This is the fundamental shift from how we've governed human access. With humans, you authenticate at the front door — the login — and then trust the session. With agents, there is no session in the traditional sense. An agent might make hundreds of tool calls in seconds, each one touching a different system, each one with different risk. You need enforcement at the call boundary, not the session boundary.

The identity-aware proxy is also your attribution layer. Every tool call gets a trace ID that links back to the originating human, regardless of how many agents are involved in the chain. When your SOC gets an alert at 2 a.m. about an unexpected production write, the first question is "who triggered this?" The proxy makes that a queryable answer, not a forensic investigation.

Model Context Protocol — MCP — is emerging as the universal interface between agents and enterprise tools. And because it's universal, it becomes the universal control point. Every primitive I'm about to describe is enforceable at the MCP boundary, in real time. Whoever owns the proxy owns the governance.

Primitive 2: Credential vaulting#

Service credentials never touch end-user laptops. They rotate automatically. They revoke instantly.

I've used a phrase in every talk I've given this year: "a dot-env file and a prayer." It gets a laugh because everyone recognizes it. It's the current state of agent credential management at most organizations — a service account password hardcoded in a config file, sitting on someone's machine, shared across multiple agents, rotated never.

If a credential lives in a dot-env file on someone's machine, that credential is already compromised. You just don't know it yet.

Proper credential vaulting for AI Access Management means short-lived credentials, vended on demand, scoped to the specific task. Think sub-sixty-second credential lifetimes. The agent requests access, the vault issues a short-lived token with the minimum required permissions, the agent completes its task, the token expires. No long-lived secrets anywhere in the pipeline.

This pattern isn't new — it's how we handle CI/CD credentials in mature DevOps environments using OIDC federation. What's new is applying it to agent-to-tool authentication at scale, across every AI interaction in the organization, not just the deployment pipeline.

Primitive 3: Scope minimization#

Agents get the smallest possible permission set for the smallest possible time window. The default scope is empty. You add permissions. You don't subtract them.

Here's a scenario that makes the difference concrete. You have a support agent that triages incoming tickets. To do its job, it needs read access to the ticket queue and write access to the priority field. That's it. But if you govern it the way you govern a human support rep — assign it the "Support Tier 1" role — it also inherits access to customer billing records, internal escalation notes, and the ability to issue refunds. The agent didn't need any of that. It wasn't going to use any of that. But the day someone finds an exploit in your agent framework, every permission in that role becomes attack surface.

For humans, role-based access is a reasonable trade-off. People need persistent access to do their jobs, and you review quarterly. For agents, it's the wrong model entirely. An agent doesn't need persistent access to anything. It needs access to specific resources, for a specific task, for a specific duration. When the task ends, the access ends. No quarterly review needed because there's nothing to review.

If you're coming from traditional IGA, this is the biggest mental model shift: stop thinking about what role an agent should have. Start thinking about what this specific agent action needs right now. The blast radius of any single agent action should be bounded by the task, not by the role.

Primitive 4: First-class revocation#

Kill switch at the agent, at the chain, and at the credential — in one action.

Revocation is where most existing identity stacks fall apart for agents. Killing a human's access is straightforward — disable the account, revoke the sessions, move on. Killing an in-flight agent mid-chain is a fundamentally different problem.

Consider the scenario: a deployment agent is halfway through a multi-step production migration. Something goes wrong. You need to stop it. Right now. Not "after the current step finishes." Not "after the credential rotates." Now.

First-class revocation means three things happening simultaneously. You can kill the specific agent that's misbehaving without affecting other agents in the system. You can kill the entire chain — every agent spawned from the same originating request — if the whole workflow needs to stop. And you can kill the credential, so even if the agent somehow survives the revocation signal, it can't authenticate its next action.

If your only revocation path is "rotate the password and restart the service," you have a problem. That's a human-scale response to a machine-speed incident. By the time you've rotated the password, the agent has made another hundred calls.

The wire that ties them together#

These four primitives aren't independent features. They're layers of the same enforcement stack, and MCP is the wire that ties them together.

The proxy authenticates and authorizes every call. The vault issues and manages the credentials those calls use. Scope minimization bounds what each call can do. Revocation provides the kill switch when something goes wrong. All four enforced at the MCP boundary, in real time, with full attribution.

IDSA's 2025 report shows that 99% of organizations are now prioritizing identity security investments. The intent is there — but intent without architecture is just budget. And here's what nobody's talking about yet: your auditors are going to ask about this. SOC 2, ISO 27001, NIST — none of these frameworks were written with agentic AI in mind, but every one of them cares about access control, least privilege, and audit trails. The organizations that build these four primitives now will have clean audit stories when the frameworks catch up. The ones that don't will be retrofitting under pressure.

Where to start#

If you're a CISO or security leader reading this and thinking "we're not ready for any of this" — that's fine. Most organizations aren't. Here's the sequencing I recommend.

Start with the audit log. You can't govern what you can't see. Get telemetry on what agents are doing today — which tools they're calling, what credentials they're using, who originated the action. That's your proxy, even if it starts as a monitoring-only deployment.

Then move to credential vaulting. Replace the dot-env files with short-lived, vaulted credentials. This is the single highest-impact change you can make because it eliminates the most common attack surface.

Then layer in scope minimization and revocation as you mature your understanding of how agents actually behave in your environment.

The maturity ladder has four rungs: shadow AI (it's happening, nobody knows where), tracked AI (you have an inventory, you don't have governance), governed AI (policy is enforced at request time, the audit log exists), and full AI Access Management (identity-aware proxy, scope-bounded, revocable, one graph). Most enterprises are on rung one or two. Rung four is where this is going. Pick the rung you want to be on in eighteen months and build backward from there.


Kevin Paige is a security leader with 30+ years of experience across the U.S. military, Salesforce, MuleSoft, Flexport, and ConductorOne. He writes about identity governance in the age of agentic AI.

Ask AI to write a summary of this post

Stay in touch

The best way to keep up with identity security tips, guides, and industry best practices.

Explore more articles

C1 Launches Enterprise-Managed Authorization for MCP

C1 Launches Enterprise-Managed Authorization for MCP

Introducing the C1 Autonomous Worker

Introducing the C1 Autonomous Worker

C1 Integrates with Claude's Compliance API

C1 Integrates with Claude's Compliance API