For the last few years, the security conversation around large language models has been about what the model says. Can it be tricked into producing something embarrassing, leaking training data, or bypassing a content filter? Those are real concerns, but they belong to a generation of systems that is already being replaced. The systems shipping now do not just talk — they plan, they call tools, they read from the open internet, and they take actions against real infrastructure with real credentials. That changes the threat model entirely. An agent that can be manipulated is not a reputational problem. It is an attacker with a valid session inside your environment.
An Agent Is Not a Chatbot
The distinction matters more than the marketing suggests. A plain LLM is a text function: input goes in, text comes out, and a human decides what to do with it. An agent wraps that model in a loop. It decomposes a goal into steps, selects tools to accomplish each step, executes them, observes the results, and repeats until it decides it is done. Somewhere in that loop, the model's output stops being a suggestion and starts being a command that something else executes without asking.
That is the entire security story in one sentence. Every property we rely on in traditional application security — that inputs are validated at a trust boundary, that privileged operations require authorization, that untrusted data stays data — gets quietly renegotiated when a probabilistic model sits in the decision path. The agent does not distinguish between the instructions you gave it and instructions it encountered while doing its job. It has no reliable notion of a trust boundary at all, because everything it sees arrives as the same undifferentiated stream of tokens.
Excessive Agency and Tool Abuse
The most common failure we find is not exotic. It is scope. Teams building agents tend to grant tool access generously during development, because a constrained agent is a frustrating agent, and nobody goes back to tighten it before launch. The result is an agent with permissions far beyond what its actual job requires.
- Overbroad tool surface: An agent built to summarize support tickets is handed a general-purpose database client instead of a narrow read-only query for the tickets table.
- Overbroad permissions: The agent authenticates with a service account that can write, delete, and modify schema, because that was the credential already sitting in the environment.
- Overbroad autonomy: The agent can chain tools indefinitely without a checkpoint, so a single manipulated decision cascades into a dozen downstream actions.
Attackers do not need to break the model to exploit this. They need to convince it, once, that a destructive action is a reasonable next step. The tooling does the rest, faithfully, with full authorization.
Indirect Prompt Injection Turns Content Into Actions
Direct prompt injection — a user typing "ignore your instructions" — is the version everyone has heard of, and it is the less interesting one. The serious problem is indirect injection: instructions planted in content the agent ingests as part of its normal work. A web page it browses. A document in a shared drive. A code comment in a repository it reviews. A support ticket submitted by anyone with a form.
The agent fetches that content because you told it to. The content contains text shaped like an instruction. The agent, having no mechanism to distinguish the two, follows it. Now an attacker who has never authenticated to your system and never touched your network is issuing commands to a process holding your credentials. The injection is not the attack — it is the delivery mechanism. The attack is whatever the agent's tools can reach.
Blast Radius Is the Real Question
When we assess an agentic system, the first thing we map is not the prompt. It is the reachable action space: every tool, every credential, every downstream system, and every state change the agent can cause without a human confirming it. An agent with mailbox access can exfiltrate over email. An agent with repository write access can introduce a backdoor into a pull request. An agent with payment or infrastructure permissions can cause damage that no amount of clever prompting will undo.
Multi-step chains are where this gets genuinely difficult to reason about. Each individual action may look benign and pass whatever filter you placed on it. Read a document. Search internal records. Send a message. Composed in sequence, they exfiltrate sensitive data through a channel nobody modeled as a risk, because nobody was looking at the sequence. This is why our AI red teaming service focuses on chained exploitation against the deployed system rather than isolated prompt tests against the model.
Guardrails Help — They Do Not Solve It
Input and output filtering, system prompt hardening, and refusal training all raise the cost of an attack. None of them are a boundary, because they are implemented in the same probabilistic layer being attacked. Real controls live outside the model: least-privilege scoping on every tool, deterministic authorization checks the agent cannot argue its way past, allowlists on outbound destinations, and human confirmation on any action that is irreversible or high-value. Complete logging of every tool call is non-negotiable — an agent without an audit trail is an incident you cannot investigate.
Red Teaming Agents Before They Ship
Testing an agent means testing the system, not the model. That means enumerating the tool surface, planting injection payloads in every channel the agent ingests, attempting privilege escalation through tool chaining, and measuring how far a single compromised decision propagates. Our four-phase methodology applies directly here: reconnaissance of the agent's capabilities, exploitation of the decision loop, escalation through chained tool calls, and reporting that ties each finding to a concrete control.
Where to Start
If your agent holds credentials and acts without confirmation, it is production attack surface and should be tested like it. Get in touch and we will scope an assessment against your deployed system — the tools, the permissions, and the blast radius, not just the prompt.