Consider a common scenario. A platform engineer builds an agent to sort support tickets. The agent reads the ticket queue, looks up customer accounts in the production database and posts summaries in Slack. The engineer connects the agent with an API token from the engineer's own account, because the token already works and the agent can't complete an MFA prompt. The security team approves access once, at setup.
A year later, the engineer has moved to another team. The agent still runs under the engineer's identity with its day-one permissions, and nobody has reviewed its scope. Then a ticket arrives with an instruction buried in the text. The agent follows the instruction, queries a table it was never meant to touch and posts the results back into the ticket. Every log entry points to the engineer, who hasn't worked on the project in months.
Nobody in that scenario was careless. The agent arrived faster than the controls built to govern it could respond. By the time anyone noticed a problem, the agent had been in production for a year, reading tickets, querying customer records and acting under a person's identity.
Agents add to an identity problem that was already growing. Industry estimates of how far non-human identities (NHIs) outnumber people nearly doubled in one year, from 46:1, to 82:1, according to the Delinea 2026 Identity Security Report. In the same report, 46% of organizations admit their identity governance around AI systems is deficient. The question for security leaders isn't whether agents need new controls. The question is which existing controls still hold, and where agents break them.
The core principles of access security apply to agents the same way they apply to people: least privilege, defined scope, monitoring and approval before access is granted.
An agent with a narrow, documented scope, a named owner and logged actions is a manageable risk, the same as a contractor
Vaulting, least privilege, session recording and approval gates all still work.
What doesn’t hold is what those controls take for granted. Most controls were built around a human pace: a person requests access, someone approves it and a review checks access months later.
An agent is asking for access constantly, so the approval ends up happening once at setup, and then nobody checks it again until the next review. By then the agent has been running for months and has taken thousands of actions no one has reviewed. The support-ticket agent ran for a full year that way.
The controls also count on whatever you provisioned behaving the same way tomorrow as it did today. That assumption holds for service accounts, but not for agents. The same agent with the same permissions will do different things depending on what it reads and who it’s talking to, so the action you approved on Monday might mean something different by Friday. The support-ticket agent behaved as designed for a year, until one ticket changed what the agent did.
Identity and access management (IAM) and multi-factor authentication (MFA) were built around a person: someone logs in, a prompt shows up on their phone, the person decides whether to approve the login. The model depends on a person reading the prompt and making that decision.
Agents behave differently from both people and services accounts, which puts them in their own identity class. An agent can’t complete an MFA prompt, and the developer building the agent usually has a session or an API token that already works, so the agent runs on that token. From then on, every system the agent touches and every action it takes gets recorded under the developer’s identity, with nothing to show that an agent was involved.
| Human | Service account | Agent | |
| MFA | Yes | N/A | Can't complete |
| Review cycle | Quarterly | Annual | Rarely reviewed |
| Behavior | Consistent | Consistent | Changes based on input |
| Attribution | Clear | Clear | Often inherited from developer |
The gap surfaces when someone needs answers. An auditor asks who approved the agent’s access to this application, and often nobody can say, because the access was approved for a person and the agent just inherited it. An incident responder finds a command that ran under an employee’s account and can't tell whether the employee or an agent ran the command. In the support-ticket scenario, the responder finds a query against the customer database under the engineer's account, a year after the engineer left the project.
In the 2026 Identity Security Report, 80% of organizations said they can't always understand why an NHI took a privileged action. That number is for service accounts and agents combined.
How do you keep up?
Tie each agent to the person who launched it.
Grant only the access the task needs.
Maintain attribution. Every logged action should show both the agent that took it and the person it acted for.
When an agent is set up, it needs OAuth or API scopes to do its job. Usually those scopes get granted broadly, because nobody knows yet exactly what the agent will need, and granting more access up from is easier than coming back for more. Nobody treats the agent as an account that needs review, so it never enters a review cycle. A year later, the agent still holds its day-one permissions. A person with that much access would have been through several access reviews by then.
Standing privilege is risky for any identity, and the risk is higher for agents. An agent acts on what it reads, so a stray instruction in a ticket or an email can trigger it to use any access it already has. The agent is working as designed. It has no reliable way to tell an instruction it should follow from one it shouldn’t. One instruction hidden in a ticket was enough for the support-ticket agent to query a table it was never meant to touch.
Agents move at machine speed. The gap between something going wrong and the damage being done is usually shorter than anyone’s ability to notice.
Many organizations still depend on standing access. In the 2026 Identity Security Report, 59% said they lack a viable alternative to standing access for NHIs and AI agents. Organizations were more than twice as likely to rely on long-lived credentials (35%) as on just-in-time (JIT) access (17%).
How do you keep up?
Remove standing access where the risk is highest.
Grant just-in-time access per task, scoped to what the task needs.
End access automatically when the task is done.
Keep credentials out of the agent’s hands where possible.
Enforce continuous authorization. Place a policy gateway between the agent and the systems an agent reaches, so the gateway evaluates each request against a policy in real time.
Where possible, the credential should stay out of the agent's hands entirely, so the agent has nothing to hold or leak.
Access has to be granted automatically, at the moment the agent needs it, because a process that needs a person to step in each time won't keep pace with an agent. JIT access controls when the agent gets in. Under a continuous authorization model, the gateway then evaluates each request the agent makes against policy and denies the requests outside the scope of the task.
Most organizations can't see all the agents running in their environment. In the 2026 Identity Security Report, more than half of organizations said they regularly find unsanctioned AI tools or agents in their environment, and only 28% said they can detect that activity in real time.
Agents slip past discovery in two ways. Some agents are gone before anything looks for them, because an agent can spin up, act and disappear in minutes, while most organizations take hours or days to detect unsanctioned AI, according to the 2026 Identity Security Report. Other agents run for months and still never appear, because nothing about them was registered. They have no installer, no license record and no product name for a discovery tool to find.
Confidence runs ahead of that reality. In the same report, 82% of organizations said they are confident they can discover NHIs with access to production systems, but only 30% said they validate NHI and agent activity in real time.
A complete inventory would not solve the problem either. Agents appear and disappear daily, so an inventory is out of date the moment it is finished. An inventory also shows which agents exist, not what each agent can reach right now.
Multi-agent systems make the picture harder to trace. Each additional agent adds access paths and handoffs, and when something breaks, tracing the failure back to the agent or step that caused it takes longer with each layer. Long-lived API tokens passed between agents and servers add risk at each hop, whether the connection runs over Model Context Protocol (MCP) or another protocol.
How do you keep up?
Start with the systems that can do the most damage: production database, customer records, deployment pipeline.
Put a policy gateway in front of those systems.
Let gating reveal which agents are trying to reach them.
Keep discovery running in parallel, expanding control as it finds more.
A lot of the conversation about rogue agents comes down to the emergency shutoff. People want to know who owns it, whether a kill switch at 2 a.m. is already too late and what happens when an agent is holding live credentials at the moment something goes wrong. In most cases, 2 a.m. is too late, because an agent moving at machine speed has usually finished the damage before anyone reaches the switch. In the support-ticket scenario, a kill switch would've stopped the agent only after the results were already posted in the ticket.
Security teams end up asking those questions when the controls upstream didn’t keep up. An agent with no standing credentials, a clear record of whose authority it acted under, and a full log of its actions rarely creates a 2 a.m. emergency.
A common objection is that this slows AI down. In the 2026 Identity Security Report, 90% of organizations said they’re under pressure to loosen access controls to support AI automation. Loosening controls isn't the only path to speed. When controls are already in place, each new agent goes through a process that already exists, instead of starting a new security debate.
The fundamentals can. Least privilege, scoped access and approval still apply to agents. What has to change is when security teams enforce those controls. Under those controls, the support-ticket agent would run under its own identity, linked to the engineer who launched the agent. The agent would receive read access to the ticket queue for each task, and a policy gateway would deny the request for a table outside that task.
Attribution has to follow each agent back to the person who launched it. Access has to be granted per task, not once at setup. Enforcement has to sit in front of the systems that matter, whether or not discovery has found the agent making the request. Controls enforced at the moment of the request can keep pace with an agent. Controls enforced only at setup leave security teams responding after the damage is done.
Learn why AI agents need their own identity class and how to govern agent access at runtime. Download Securing Agentic AI.