Your next insider threat doesn’t have a badge. It has an API token

The threat that I now spend most of my time designing against doesn’t look like a breach at all. At least not at first.

Imagine a team deploys an agent that does exactly what it’s permitted to do: it reads a customer record, summarizes it, then sends the summary to an outside address. Every step in the sequence is authorized. But it turns out that the breach is the sequence itself.

The problem is that each security check only looks at one step at a time. Is this read okay? Yes. Is this summary okay? Yes. Is this email okay? Yes. Each step passes. But nobody is watching the combination of all three steps together. The security tools designed for human-driven workflows assumed a person would be doing this manually, one thing at a time. However, the AI agent bundles it all into a single automated sequence, and that bundling slips through gaps between the checks.

I build authorization for agentic systems, and the gap between “every action was allowed” and “the outcome was a breach” is what I keep coming back to.

An agent is not a user or a file. It is an insider authorized with an API token instead of a badge to act on your behalf. We learned decades ago that perimeters don’t secure against insiders. But in the design reviews I’ve sat in this year, the security conversation still centers on prompt injection and output filtering. That’s one layer below where the exposure has moved.

Two decades of asking the wrong two questions

We spent 20 years getting very good at two questions:

• Who is allowed in?
• What data is allowed out?

Identity and access management answered the first question. Data loss prevention the second. Both assume a world of users and files—a human you authenticate at the door and a document you inspect on the way out. But production AI agents make both questions obsolete.

An agent is an actor. It reads context, chains tool calls, invokes connectors and changes systems of record, then hands work to other agents as it goes. The danger isn’t that it does one clearly forbidden thing; it’s that it does a series of small, permitted things that add up to something harmful. And because each individual action looks fine, the standard security tools don’t flag anything. It’s the same reason an employee with legitimate access is harder to catch than an outside hacker.

This is a known failure mode in IT security, sometimes called the confused deputy problem: a program with legitimate authority gets manipulated into misusing it on someone else’s behalf. Now, AI agents have given it initiative. An agent is a confused deputy that doesn’t just hold authority but plans with it. The OWASP community ranks excessive agency—an agent operating with broader capability than its task requires—among the top risks for large language model applications.

The four ways agent authority goes wrong

When I threat-model an agent before it ships, four failure modes do most of the damage, and the governance conversation most teams are having addresses none of them.

1. Tool-chain abuse. Each tool call is safe on its own, but the chain composes into something no one authorized. The pattern is mundane: an agent permitted to read records, call a summarizer and send mail turns those three benign capabilities into a clean exfiltration path. Content filtering inspects each step and waves all of them through, because no single step is prohibited.

2. Delegation-chain exploitation. An agent hands a subtask to another agent, and the child ends up with authority it was never meant to have. The mechanism is simple: the parent passes the child a copy of its own credentials, so the child can now do everything the parent can. Most orchestration frameworks pass parent context down by default because they assume the child is trusted. That’s a framework default, not a security decision.

3. Approval evasion. A human-in-the-loop gate is supposed to catch the consequential action, but the agent reaches the same outcome by a path the rule didn’t anticipate. This isn’t agents being clever; it’s policies written for human workflows. A gate that checks “summarizing customer records” is blind to an agent reaching the same data by another tool path. In other words, it guards the actions humans take, not the outcome it was meant to protect.

4. The first three are how the breach happens. The fourth is why it becomes a crisis: audit opacity. Even after you discover something went wrong, you can’t piece together the full picture: what exactly the agent did, who authorized it to do those things or whether it went beyond what it was supposed to do. The logs simply show that reads and sends happened. Only in the post-incident review do teams discover their logs were written for debugging, not for proof.

Move the decision to runtime

When these failure modes surface, the instinct is to add another detection layer, such as a better filter or a smarter classifier watching the output. That instinct is wrong. You can’t inspect your way out of a problem of authority. The answer is a runtime policy engine that governs what an agent is allowed to do at the moment it acts.

The concept isn’t new; it’s zero trust, applied inward. We spent years pushing zero trust outward to the perimeter for people and devices. Every request is authenticated and authorized in context, decided centrally rather than assumed at the edge. Agents move the object of that decision inward, from who are you at the door to what will you do in the next call.

A runtime policy engine makes that concrete. It evaluates which tool is being called, which data is being touched and what the downstream effect will be.

Three properties make it real:

1. Decide before the action fires. Evaluate the agent’s intended action against policy and live context at call time, not afterward in a log review. A policy that isn’t evaluated at the moment of action isn’t a control.

2. Make delegated authority shrink. Authority should only narrow as it passes from agent to agent, never widen. That way, a compromised agent can’t exceed the narrowest link in its chain, and stopping a parent leaves no orphaned authority downstream. Capability can still be re-requested; a child can ask its parent to escalate, but that escalation is evaluated and logged at call time, not baked into a token handed over once.

3. Build audit as evidence, not logs. Evidence means a record that ties each action to the policy that authorized it—principal, tool called, inputs, the rule evaluated, the decision and a timestamp—in append-only or signed storage so it can’t be quietly rewritten. It lets a regulator or a board reconstruct who acted, on whose authority and whether that authority was exceeded, instead of relying on a forensic reconstruction weeks later. Most deployments skip this because it’s infrastructure work, not policy work.

One implementation caveat: Evaluating every action at runtime adds latency and demands live policy context. Some friction is unavoidable, so the question is where you add it. Focus on the actions where a mistake is hardest to reverse: Anything touching customer data, financial systems or infrastructure.

The three questions I ask before every deployment

When a team brings me an agent bound for a real system of record, I’ve stopped asking which model it uses. I ask three things instead:

1. Can every action resolve to a human source of authority, captured at runtime?

2. Does the agent’s authority shrink as it delegates, or can a subagent do more than its parent?

3. If this agent did something wrong tomorrow, could we prove what it did? (Not describe it. Prove it.)

The autonomy that makes AI agents so valuable also makes legacy controls insufficient. You can’t add autonomous agents to your existing processes and expect last year’s controls to cover them. When an agentic breach happens, the question the board asks won’t be, “What leaked?” It will be, “What was your agent allowed to do, and can you prove it?”

Get ahead of it before the board has to ask.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?