# Your next insider threat doesn’t have a badge. It has an API token > Source: > Published: 2026-07-10 10:00:00+00:00 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. We spent 20 years getting very good at two questions: 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](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) ranks [excessive agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)—an agent operating with broader capability than its task requires—among the top risks for large language model applications. When I threat-model an agent before it ships, four failure modes do most of the damage, and the [governance conversation](https://www.csoonline.com/article/4109123/managing-agentic-ai-risk-lessons-from-the-owasp-top-10.html) most teams are having addresses none of them. 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](https://csrc.nist.gov/pubs/sp/800/207/final) 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: **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. 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: 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?**