Agentic AI Security: AI Agents Already Have the Keys - Which Doors Can They Open?

Agentic AI security has become one of those problems most organizations discover too late. They did not decide to adopt AI agents - they just looked up one day and the agents were already there.

A developer installed an AI coding assistant three months ago. It runs with his credentials. It can read every file he can read. An operations team automated their reporting with an AI tool. Nobody scoped its access down from the defaults. A vendor bundled an AI assistant into a SaaS platform you renewed last quarter. It has been active since the day the contract was signed.

This is not a security failure. It is how adoption works. The question is not how to reverse it - that ship has sailed. The question is what those agents can actually reach, and whether anyone knows.

Why the obvious fix does not work

When security teams first encounter a new technology, the instinct is to put controls around it. Inspect what goes in. Monitor what comes out. For predictable systems, this works.

AI agents are not predictable systems.

The input space of a large language model is effectively unlimited - any combination of words, context, and instruction. The same is true of the output. There is no finite ruleset that captures every harmful input or every harmful output. Security researchers have demonstrated that well over 80% of attacks against model-level defenses succeed. The model cannot reliably protect itself.

This is not a flaw that will be patched. It is a structural property of how these systems work. Controlling inputs and outputs is the wrong frame entirely.

The identity problem nobody solved yet

For decades, identity and access management has been built around two types of entity.

The first is the human - a person with a role, a department, a manager. The second is the workload - a script or service that does one defined thing in a predictable way.

AI agents fit neither category.

They work at machine speed - running overnight, spawning sub-agents, executing thousands of actions without a human in the loop. But they reason like humans - interpreting ambiguous instructions, making judgment calls, adapting when something unexpected happens. A workload never does that.

The result is a gap in governance that most organizations have not closed yet. When a developer sets up an AI agent on his machine, it typically inherits his credentials. It can reach everything he can reach. The blast radius of a problem - whether a compromise or simply the agent misinterpreting its task - is the full surface area of his identity.

Scale this up. A 500-person company that pushes AI adoption across every team can find itself running 1,500 agents within months. Three per employee on average. Many of those agents were provisioned with broad access because broad access was convenient. Nobody asked whether a deal preparation agent actually needs the ability to delete CRM records. It does not. But nobody scoped it down either.

The gap between what an agent is for and what it can do

Every agent has an intent - the reason it was created, the task it was given. A customer success agent has a narrow purpose. An IT help desk agent has a different one. A security audit agent has another.

The problem is that intent and permission are almost never aligned.

Agents get broad access because it is easier to provision that way. The intent stays narrow. The permissions stay wide. Everything between the two is exposure that nobody is managing.

Ido Shlomo, co-founder and CTO of Token Security - a top-ten finalist at RSA Innovation Sandbox 2026 - puts it directly: organizations fail at connecting their AI strategy to their identity access management. The tools exist on both sides. The bridge between them does not.

Closing that gap starts with being able to answer four questions: which agent used which credentials, on which system, accessing which data, and on whose behalf. Without that visibility, you cannot govern what you cannot see.

What to actually do

The starting point is not a policy. It is a discovery exercise.

Before you can govern agents, you need to know what is running. That means a central inventory - not just the agents your organization approved, but the ones on developer machines, the ones operational teams spun up quietly, the ones bundled into tools you already use.

From there, the approach follows the same logic as human identity lifecycle management:

Provisioning based on intent. What does this agent actually need to do its job? Start there. Not from what is technically available, not from admin defaults. Scope access to the task.

Ongoing monitoring. Agents drift from their original purpose. Access granted at setup rarely shrinks as the task evolves. Regular review of what agents are actually doing - versus what they were built to do - catches problems before they become incidents.

Spotting what is out of bounds. Some agents will always be operating beyond their intended scope. The ability to identify them quickly is the operational equivalent of anomaly detection for human identities.

Retiring stale agents. An agent built for a project that ended six months ago, still running with valid credentials and no owner, is an open attack surface. Decommissioning needs to be as deliberate as provisioning.

The underlying principle is one security practitioners already know from Zero Trust. Access should not be granted based on convenience. It should be scoped to the minimum required, verified continuously, and revoked when it is no longer needed. The same logic applies to agents.

The organizations that manage this well will not be the ones that tried hardest to slow adoption down. They will be the ones that accepted agents as a permanent part of their environment and built the governance layer early - starting with visibility, enforcing least privilege based on intent, and treating agent identity with the same rigor they apply to human identity.

The keys are already distributed. The question is whether you know which doors each one opens.

Agent identity is one dimension of the challenge. For AI workspace visibility, shadow tooling, and organizational-level governance, see AI Governance in Practice.