AI Agent Permissions: Why Guardrails Aren’t Enough

Enterprises spent the past year promoting their AI agents. Now security teams want to know what those promotions unlocked.

A new survey of 1,100 IT and security decision-makers found that 70% of organizations let AI make decisions that needed human sign-off a year ago. Nobody automated the approval step. Teams simply dropped it.

Look closer, and the data reveals an old identity problem with a faster engine attached.

The Promotion Nobody Approved

A chatbot drafts text. A person decides what happens next. An agent decides and then acts. It calls APIs, edits configurations and chains tasks without pausing for review. That loop of reasoning, planning, and acting is what makes agents useful. It also makes them risky.

The incidents have already started. Three in four organizations hit at least one AI-related security issue or warning sign last year. About a quarter of respondents saw each of these:

• Unsanctioned connections: an agent linked itself to a system security never cleared
• Off-limits data: an agent reached information outside its remit
• Rogue execution: an agent triggered an action no person authorized

Appetite for autonomy keeps growing anyway. Roughly three in ten firms would let an agent run a security investigation or change production with no human check. Few of them ask whether the task can tolerate machine-speed mistakes in the first place.

The 35-Point Blind Spot

The sharpest number concerns visibility.

Confidence collapses once the question gets specific. That 35-point drop is where incident response fails. Without a complete trail, investigators can’t tell what an agent touched or how far damage spread.

The 62% figure shows how teams got here. They shipped first and promised safeguards later.

Asking the Agent to Police Itself

The oddest finding concerns controls. Most respondents agree that limiting AI access matters more than predicting every threat. Yet defining an agent’s permitted actions ranked dead last among top controls. Only a quarter picked it.

Teams lean on guardrails instead. These are instructions built into the model itself. They rank near the top, alongside external containment and human oversight.

That creates a contradiction. A guardrail holds only while the agent obeys it. Every incident above shows what happens when it doesn’t. You’re asking the system you worry about to enforce its own limits.

An allow-list works differently. It names the systems, data, and actions an agent may use. Security enforces it from outside the agent. If the model hallucinates, falls for prompt injection, or wanders, the fence still stands.

Raghu Nandakumara, VP of industry strategy at Illumio, blames friction. Scoping a new agent’s permissions takes effort, and no one wants to slow the workflow that made it valuable. So teams plan to tighten access later. In his experience, later rarely comes.

Who Owns the Damage?

Granting authority raises a hard question. Who answers for an agent’s mistakes?

Nandakumara says regulators and courts agree on one point. Deploying an agent doesn’t pass accountability to the vendor. The organization that switched it on owns the outcome.

Inside the company, he splits the duty two ways:

• The business leader who approved the use case owns the results
• The CISO owns the controls: access scope, allowed actions, and how fast someone can stop the agent

Security often inherits business decisions by default. He calls that a mistake, and it happens whenever nobody else takes ownership.

Regulators now force the issue. Financial services lead, with the UK’s senior managers regime and Australia’s APRA expecting a named person to answer for AI outcomes. Most boards still skip these questions before launch. His rule: “If you can’t name who owns an agent, it shouldn’t be in production.”

Strip the Hype, Find a Familiar Risk

Here’s the angle worth keeping. Remove the AI label, and an agent looks like a new identity with broad credentials and no defined role. Security teams already fought this battle with service accounts, shared admin logins, and bloated API keys.

Many companies now treat agents like digital colleagues with real responsibilities. That framing helps adoption. It hurts security when it hides the gap. An employee carries legal accountability, a manager, and a performance record. An agent carries none of that, which is why treating agents like staff creates governance blind spots.

Speed changes the math too. A forgotten service account sits idle. An agent uses its access nonstop, at machine pace, across many systems. Over-permissioning used to be a dormant risk. With agents, it turns active.

Where to Start This Quarter

Nandakumara’s advice targets teams with agents already running, which means most of them. One enforced boundary now beats a perfect policy next year.

1. Skip the full inventory. Don’t let a complete audit stall action.
2. Pick the riskiest agent. Start with the one that touches data you can’t afford to lose.
3. List its real jobs. Write down the three or four tasks it actually performs.
4. Fence it in. Limit it to the actions, systems, and data those jobs need.
5. Name an owner. Assign a business leader before the agent expands its reach.

The Bottom Line

Agent autonomy surged in a single year. Oversight fell behind. The winners won’t be the firms with the cleverest guardrails inside their models. They’ll be the ones that drew hard lines around them and named someone to hold those lines.

Related: Your AI Agent Is Not an Employee — And Treating It Like One Is Dangerous