Skip to content
Breachfolio
AI · SECURITY

Agentic AI security: what changes when the LLM can act, not just talk.

A chatbot that gives bad advice is a nuisance. An agent that acts on bad advice — sends the email, deletes the file, spends the money — is an incident. Here's what actually changes.

July 8, 20269 min read

A conversational LLM produces text. You ask a question, it answers, and a human decides what to do with that answer — copy it into an email, act on the advice, ignore it entirely. An agentic system is different in one specific, consequential way: it can call tools and APIs, browse the web, read and write files, and chain several of those steps together in pursuit of a goal, without a human reviewing or approving each individual step along the way. Ask a chatbot to "clear out my old invoices" and it will tell you how; ask an agent, and it may just open your accounting tool, find the invoices it judges to be old, and delete them — correctly interpreting your intent most of the time, and occasionally not. We've covered the underlying spectrum — what actually separates a raw LLM, a chatbot, and an agent — in LLM vs chatbot vs agent. This piece is about what changes, from a security standpoint, once a system sits at the "agent" end of that spectrum.

Why this changes the risk model, not just the capability

It's tempting to file "agentic AI security" under the same heading as ordinary LLM security and move on. That undersells what's actually different. With a plain chatbot, the worst-case outcome of a manipulated or hallucinated output is bad text — a human reads it, and in principle has a chance to notice something is off before acting on it. That review step is a real, if imperfect, safety net.

With an agent, the output isn't just text waiting to be evaluated — it can be the action. A manipulated response doesn't need to convince a person to do something harmful; it can trigger the tool call directly, and the tool call has already executed by the time anyone looks at a log. The email is sent. The file is deleted. The purchase is made. There was no intermediate step where a human could have caught it, because the system was designed specifically to remove that step.

This is exactly why prompt injection gets so much more dangerous in agentic contexts. Injection has always been about getting a model to treat untrusted content as an instruction. Against a chatbot, a successful injection produces a weird or manipulated reply — annoying, but inert until a person acts on it. Against an agent with tool access, the same injected instruction has something to execute against. The vulnerability doesn't change; what it's connected to does. A hidden instruction buried in a webpage the agent is summarizing, or in an email it's been asked to triage, used to be a curiosity. Once that agent can also send a reply, move a file, or place an order, the same hidden instruction is a working exploit — and it fires the moment the model reads it, not after someone has had a chance to sanity-check the output.

The new failure modes

A handful of failure patterns show up specifically once systems become agentic, and they're worth naming plainly rather than treating as vague "AI risk."

  • Excessive agency. An agent is granted more permissions or tools than its actual task requires — a research assistant that can also send emails, a document summarizer that can also delete files. When something goes wrong, the blast radius is defined by everything the agent could do, not everything it was supposed to do.
  • Tool misuse and unsafe chaining. Individually safe actions can combine into an unsafe sequence. Reading a document is safe. Sending an email is safe. An agent that reads a document and then, in the same chain of reasoning, emails its contents to an address it inferred from the document's own text — because that's what the content implied it should do — has just exfiltrated data through two actions that would each pass a security review in isolation.
  • Insufficient human oversight. The entire value proposition of an agent is that it acts without a human approving every step. That's also the risk: without a deliberate approval gate somewhere in the loop, there is no point at which a person can stop a consequential action before it happens.
  • Cascading failures across multi-agent systems. When agents are chained together — one agent's output feeding another agent's input — a single compromised, confused, or simply wrong agent can pass bad information downstream to an agent that has no reason to distrust it. The failure doesn't stay contained; it propagates through however many agents are wired to trust each other.

None of these four are exotic. They're variations on failure modes security teams have dealt with for decades in other contexts — over-provisioned service accounts, unreviewed batch jobs, brittle trust chains between microservices. What's different is how quickly an agent can move from "granted too much access" to "used that access," because the entire point of the design is to skip the step where a human would normally have noticed.

This pattern grew common and consequential enough that OWASP has published dedicated guidance specifically for agentic AI systems, separate from its general LLM application guidance — a signal that the security community sees this as a distinct problem category, not a footnote to prompt injection.

MCP and the growing tool-connection surface

Part of what's made agentic systems practical is the emergence of standardized ways for a model to connect to external tools, data sources, and services, rather than every integration being bespoke. That standardization is genuinely useful for builders — it means an agent can plug into a growing ecosystem of tools without a custom-built connector for each one — and it also means every one of those connections is a point where a trust decision gets made, often implicitly: does this tool get read access, write access, both? Does it see the full conversation context or a scoped subset? Does the person wiring the integration together even know which permissions they just granted? As the number of connected tools grows, so does the number of places where one under-scoped connection can quietly become the weakest link in the whole chain. We go deeper on that specific layer, and the risks that come with a growing web of standardized connections, in MCP: the new attack surface.

What mitigations actually help

None of this means agentic systems are impossible to build safely — it means the mitigations have to match the actual failure modes above, not generic "be careful with AI" advice.

  • Least-privilege scoping. Every tool and API an agent can call should be scoped to the minimum access that task genuinely requires — not the maximum that might someday be convenient.
  • A hard approval gate for irreversible or high-consequence actions. Sending, deleting, purchasing, granting access — anything that can't be trivially undone should pause for explicit human sign-off, regardless of how confident the agent's reasoning looks.
  • Sandboxing execution environments. An agent's ability to run code, touch a filesystem, or reach a network should be contained, so a bad decision inside the sandbox doesn't become a bad outcome outside it.
  • Logging every tool call and decision. If an incident happens, "what did the agent read, and what did it decide to do about it" needs to be a question you can actually answer, not one you can only guess at.
  • Treating ingested content as untrusted input. Documents, emails, web pages, API responses — anything the agent reads that a third party could have influenced should be treated as data to reason about, never as instructions to follow.
  • Re-testing safety behavior after every model upgrade. Defenses tuned against one model's failure modes don't automatically carry over to the next version; a new model can pass the same prompts differently in ways that quietly break assumptions your guardrails depended on.
A note on scope. This is written as defensive design guidance for people building or auditing agentic systems — a checklist for reasoning about permission boundaries, approval gates, and failure containment. It is not a guide to compromising a system you don't own or lack authorization to test.

Agentic AI security sits at the intersection of AI safety and classical security engineering — least privilege, defense in depth, auditability — none of which are new ideas. What's new is the speed and autonomy with which agents can act on a bad decision before anyone notices it was bad. The principles that keep agents safe are the same ones that have kept software systems safe for decades; the cost of skipping them is just higher now, because there's less time between a flawed decision and a real-world consequence.