C1’s Kevin Paige on zero standing permissions, agent lifecycle governance, and why the blast radius problem cannot wait for the perfect framework.

Interview by Confidence Staveley | AI Cyber Magazine | RSAC 2026, Moscone South

Intro

Identity and access management was built around a simple set of assumptions: people move slowly, identities persist for years, and the hire-transfer-terminate lifecycle gives you natural governance checkpoints. Every one of those assumptions breaks when the identity in question is an AI agent. Kevin Page is Field CISO at C1, an identity governance platform. He has three decades of experience across the US military, Salesforce, MuleSoft, and enterprise security leadership. At RSA 2026, he sat down with AI Cyber Magazine to work through what actually fails when you put an autonomous agent behind an IAM framework designed for people, and what a governance model built for the agentic era would need to look like.

When you say the current identity stack was built for humans, what specifically breaks when you put an autonomous agent behind it?

PAIGE: Everything in those systems was built on-premises, built for slow-moving environments, built around the assumption that a human changes roles maybe once or twice a year. In the agentic world, you have identities that exist for seconds. Thousands of them. And they are constantly spinning up and spinning down, as opposed to hundreds of human identities that persist for years. The systems were never designed for that kind of scale or that kind of velocity. That is the core problem.

Give me a concrete blast radius example. An agent operating inside a current IAM framework goes wrong. What does that actually look like?

PAIGE: This is something I have seen recently. A software developer had production-level access to his systems. He wanted to refactor his code and decided to hand the task to an AI agent, giving it his full permissions so it could move quickly. He stepped away. The agent refactored the code, built new services, created new identities, created new access for those identities, and pushed them to production. Within about four hours, those identities were compromised and data was leaked.

The Four-Hour Blast Radius

1. Developer delegates. Production-level credentials handed to an AI agent so it can refactor code without permission friction.
2. Agent acts. Code refactored. New services built. New identities created. New access provisioned for those identities.
3. Agent ships to production. All of the above pushed live without human review.
4. Compromise. Within four hours, the new identities are compromised and data is leaked.

The lesson: When an agent inherits a human’s full permissions, the blast radius is not incremental. It is the full reach of those credentials, executed at machine speed.

PAIGE: That is the blast radius problem in a single incident. When you give an agent administrative credentials, or when a developer hands over all their permissions so the agent can move fast, you are not just accepting some incremental risk. You are accepting the full scope of everything those credentials can reach. And agents move faster than humans can monitor.

Pull Quote: When you go very fast, you can have very bad accidents.

Privileged Access Management (PAM) was built on the assumption that privileged access is temporary and human-initiated. What is the equivalent control for an agent that needs elevated access to do its job?

PAIGE: We have to get out of the idea that persistent access is necessary at all. I am a strong advocate for least privilege and zero standing permissions. Just-in-time access. If an agent needs admin-level access to perform a specific task, it should get exactly that level of access, for exactly the time period required to do that one thing, and nothing beyond that. Once the window closes, the access is gone.

This is the modern answer to what PAM was designed to solve, but applied to a world where the entity requesting access is not a human and the timeframe is measured in seconds or minutes rather than quarters. The traditional approach of vaulting credentials and rotating them on a schedule does not scale to thousands of agents with ephemeral lifespans. You need workflow engines and self-service capabilities that can derive context from the organization: who is this agent, what role does it serve, what is it trying to do right now, and what is the minimum access required to accomplish that task.

How does your team actually inventory agents in your environment? Not the ones you provision, but all of them.

PAIGE: You have to look everywhere. Our primary approach at Conductor One is using MCP, the Model Context Protocol, as a visibility layer. Most agents need to call MCP servers in order to communicate with applications. So we run a proxy and integration approach across all of our AI agents that lets us see every agent, see what applications it is communicating with, and enforce that it can only talk to the MCP servers we have approved. That gives you an inventory, but it also gives you something more valuable than an inventory: visibility into what people are actually using AI for, what calls they are making, and how they are making them.

We also integrate directly into the enterprise offerings of the major AI providers so that when our employees use those platforms, we have visibility at that level too. Between the MCP proxy layer and the enterprise integrations, you can build a reasonably complete picture. The gap is always the unsanctioned tools, and that is where the MCP proxy catches things that an employee-level integration would miss.

There is a real tension between giving agents enough access to be useful and restricting access enough to be safe. How do you resolve it?

PAIGE: Honestly? We are figuring it out. I think that is the truthful answer and I will not pretend otherwise.

What I can tell you is the direction we are taking. Agents should have identities. Once you can assign an agent an identity, you can manage its entitlements the same way you manage human access at scale. Through that identity, you can govern what the agent is allowed to do, provide just-in-time entitlements for specific tasks, and revoke them when the task is done. The path is: discover the agent, assign it an identity, inventory what it is doing, and then manage its access through that identity on a least-privilege basis. We know what we need to accomplish. The hard part is executing it at scale as the agent ecosystem keeps expanding.

Lifecycle, Accountability, And What Breaks At The Board Level

Most identity governance tools are built around hire, transfer, terminate. What does the agent equivalent of that lifecycle look like, and who owns it?

PAIGE: It depends on the type of agent, and I think that distinction matters a lot.

The developer example I mentioned earlier is a good illustration of the complexity. He spun up one agent. That agent spun up two more: one for deploying to development, one for deploying to production. So you have a chain of agent creation happening in real time, each with its own access requirements and its own lifespan. Your governance model has to handle all of that: persistent company-level agents with formal lifecycle management, ephemeral personal agents that exist for an afternoon, and sub-agents that exist for minutes. It has to be modular, it has to be adaptable, and it has to understand agent identity at every level. A control plane approach is the only architecture that can hold all of that together.

Three Types Of Agents, Three Lifecycles

1. Company-level agents. Provisioned by a business unit for finance, sales, or operations. Relatively persistent. Need formal lifecycle management with named owners and full governance.
2. Personal agents. Spun up by individual employees to assist with their own work. Lifespan measured in hours or days. Need lightweight identity assignment and entitlement scoping.
3. Ephemeral sub-agents. Created by personal agents to complete subtasks. Lifespan measured in minutes. Need automated provisioning and deprovisioning with no human-in-the-loop step.

An agent authenticates correctly, operates within its defined permissions, and still causes harm. How do you handle that case?

PAIGE: How would we handle it for a human? There has to be a level of trust you extend to any actor in your environment, human or agent. If you are going to delegate a task, you accept some residual risk that the task gets executed in a way you did not anticipate. That is not fundamentally different from the risk you accept when you give a human employee access to a system.

What you can do is scope the risk carefully, build in audit trails so you can see exactly what the agent did and why, put humans in the review loop for anything above a defined consequence threshold, and make sure the agent is surfacing its actions to you clearly enough that anomalies are detectable. The goal is not zero risk from an agent that is operating within bounds. The goal is making sure that if something goes wrong, you find out immediately, you can trace it precisely, and you can contain it before it compounds.

What does the board understand about agent identity risk, and what do they consistently get wrong?

PAIGE: There are two views, and they tend to split along the risk appetite of the organization. The first view is productivity and cost: agents can help the company move faster, they can reduce headcount, they can replace some of the SaaS tooling the company is currently paying for. Boards holding this view are pushing hard for adoption and are not asking enough questions about what can go wrong.

The second view, more common in financial services, insurance, and heavily regulated industries, is that agentic AI represents a potential company-ending event. Something that could cause a catastrophic security failure or operational collapse if it goes wrong at scale. Those boards are asking the right questions but sometimes creating so much friction around adoption that the risk migrates to shadow deployments where there is even less governance.

Pull Quote: The boards I worry about most are not the cautious ones. They are the productivity-focused ones that have not yet connected the speed of deployment to the scale of potential blast radius.

PAIGE: The two things are directly proportional. The faster you deploy agents with insufficient governance, the larger the failure you are setting up.

A CISO who has not yet started addressing agent identity in their environment. What is the first step? Not the first vendor call, the first operational step.

PAIGE: Discovery. That is it. Before you can govern anything, you have to know what is running. Inventory every place you have agents operating, understand what they are doing and why, and bring that context together. You are going to find things you did not know were there. Most organizations do.

And when you start finding them, resist the reflex to say no. A modern CISO’s job is to help the company make money and increase revenue. That means understanding what the business is trying to accomplish with these agents and then figuring out how to build guardrails around it, not shut it down.

Paige’s Monday Morning Prescription

1. Discover. Inventory every place agents are operating in your environment. You will find things you did not know were there.
2. Identify. Assign each agent a managed identity. Without identity, you cannot govern.
3. Govern. Manage entitlements on a least-privilege, just-in-time basis through that identity.
4. Reframe. A modern CISO’s job is to help the company make money. Less refusal, more problem-solving.

Compliance, Frameworks, And The Two-Year Outlook

Which existing compliance frameworks have anything useful to say about non-human identities, and which are simply silent on the problem?

PAIGE: NIST has released guidance that is worth reading. There are open source control frameworks specifically focused on AI that provide useful structure. The honest limitation of most of them is timing: many were written three or four years ago, before the current generation of large language models existed at their current capability level. They were designed around a threat model that did not anticipate what agents can actually do today, for good or for harm.

What I think needs to happen is that the major AI providers, Anthropic, OpenAI, Google DeepMind and others, need to become active leaders in securing what they are building. They cannot do that in isolation. They need to create genuine forums with the practitioners who are living this problem in production environments, because the frameworks written without that operational input will keep being behind the curve. I am seeing movement in that direction, which is encouraging. But the pace of AI capability development is going to keep outrunning the pace of governance framework development unless there is sustained, serious investment in that collaboration.

What does the identity stack that can actually handle agents look like in two years?

PAIGE: A unified control plane. One that manages humans, non-human identities, and agentic identities in a single governance architecture, because they are all related and they all interact. You cannot have meaningful lifecycle governance if you are managing those three categories in separate systems that do not share context.

That unified control plane needs to handle the full lifecycle: provisioning an agent identity, scoping its entitlements on a just-in-time basis, monitoring its behavior continuously, detecting drift when it starts acting outside expected parameters, and deprovisioning it cleanly when its task is complete. It needs to do all of that at the velocity of agentic systems, which means it cannot be a human-driven workflow at every step. Parts of it will have to be automated.