Artificial intelligence agents have moved out of research demos and into production systems that can read our inboxes, run code, move money, and modify infrastructure. That leap — from answering to acting — is exactly where the security conversation has to change. A chatbot that says something wrong is an embarrassment; an agent that is manipulated into exfiltrating data or deleting records is an incident.

This article maps the concrete security problems that appear the moment an LLM is given tools and autonomy, and pairs each one with a practical defense. It is written for engineers and architects who are shipping — or about to ship — agents into real environments.

Why Agents Are a Different Security Problem

Traditional applications follow code we wrote: inputs go through deterministic logic, and the range of possible actions is fixed at compile time. An agent is different. Its behavior is driven by a model that interprets natural-language instructions and chooses which tools to call. The control flow is no longer fully specified by the developer — it emerges at runtime from the model’s reasoning.

That single difference is what makes agent security hard, and what makes the classic “validate the input, escape the output” playbook insufficient. We now have to secure a system that reasons about untrusted content and then takes consequential actions.

The Core Issues

1. Indirect Prompt Injection

Direct prompt injection is when a user tries to override the system. Indirect injection is far more dangerous for agents: the malicious instruction arrives inside data the agent is told to process — a web page it scraped, an email it summarized, a document it read, a result returned by another tool.

Because that content looks like ordinary data, the agent may treat its embedded commands as legitimate instructions. The result can be credential theft, unauthorized actions, or data exfiltration, all launched through content the system was supposed to merely read.

How to address it:
– Treat every externally-sourced string as untrusted data, never as instruction. Separate the agent’s operating instructions from the content it processes.
– Use structured tool contracts so tool outputs are handled as values, not as directives.
– Mark provenance: tag which parts of the agent’s context came from untrusted sources, and instruct the model to ignore instructions found inside them.
– For high-risk tasks, require human confirmation before any action derived from untrusted content.

2. Excessive Tool Privilege

The most common agent vulnerability is simply over-permissioning. Giving an agent a shell, a broad API key, or database write access means a single bad decision — its own or one induced by injection — has blast radius far beyond the task it was meant to do.

How to address it:
– Apply least privilege per agent: grant only the specific tools and scopes the task requires, nothing more.
– Use scoped, short-lived credentials instead of standing admin keys.
– Separate read and write capabilities; prefer read-only tools unless write is explicitly needed.
– Run the agent under a dedicated identity, not a shared human or production account.

3. Unbounded Loops and Resource Exhaustion

Without limits, an agent can get stuck in a failure loop — retrying a broken action, re-calling expensive tools, or spinning indefinitely. This is both an availability and a cost problem: a runaway agent can burn thousands of dollars in API calls in minutes.

How to address it:
– Enforce hard caps: maximum steps, maximum tool calls, and a wall-clock timeout per task.
– Set a budget ceiling on token and tool spend, with automatic cutoff.
– Detect repetition (same action attempted N times) and halt.
– Rate-limit tool calls and external requests.

4. Data Exfiltration and Privacy Leakage

Agents routinely handle sensitive data — customer records, source code, credentials in context. They can leak it through tool calls (e.g., pasting secrets into a public endpoint), in logs, or by summarizing it into an outbound message.

How to address it:
– Classify data and block tools that would send restricted content to low-trust destinations.
– Strip secrets and PII from the context before it reaches long-term memory or logs.
– Never log full tool inputs/outputs by default; redact.
– Constrain outbound network egress to an allowlist of approved endpoints.

5. Poisoned Memory and Poisoned Tools

Two emerging vectors deserve attention:
– Memory poisoning: if an agent’s long-term memory (a vector store, a notes file) can be written by untrusted input, an attacker can embed instructions or false “facts” that steer future behavior.
– Tool supply chain: a third-party tool or plugin the agent calls can itself be compromised, turning a trusted capability into an attack channel.

How to address it:
– Make memory append-only or require validation/approval before memories affect future decisions.
– Pin and verify tool/plugin sources; review them like any other dependency.
– Sandbox each tool so a compromised tool cannot reach unrelated systems.
– Monitor for anomalous tool behavior (unexpected outbound calls, unusual payloads).

6. Lack of Observability

You cannot secure what you cannot see. An agent making dozens of invisible tool calls per task is a black box — and a black box is un-auditable after an incident.

How to address it:
– Log every step of the reason-act-observe loop: the plan, the tool called, the arguments, the result, and the decision.
– Store traces in a tamper-evident, queryable store.
– Build alerts on risky patterns (write to production, send external, privilege escalation).
– Keep a human-readable audit trail sufficient to reconstruct any decision.

A Reference Secure-Agent Architecture

A practical, defensible design puts the agent behind explicit guardrails rather than hoping the model behaves:

1. Sandboxed execution — the agent runs in an isolated environment with no broad access to production.
2. Policy layer — every tool call is checked against an allowlist and a per-agent permission set before execution.
3. Human-in-the-loop gate — irreversible actions (publish, send, delete, pay) pause for explicit approval.
4. Bounded runtime — step, spend, and time limits with automatic cutoff.
5. Egress controls — outbound network restricted to approved destinations, with sensitive-data scanning.
6. Full observability — complete, redacted, queryable traces of every decision and action.

This is the same shape the software-security field has recommended for human operators for decades — least privilege, defense in depth, auditability. Agents just force us to engineer it deliberately rather than assume it.

Conclusion

Agent security is not a feature you bolt on at the end; it is the architecture. The risks above are real and well-understood, and the defenses are equally well-understood — they simply have to be built in from the first line of code. Teams that treat autonomy as a security property, not a demo trick, are the ones who will be able to ship agents we can actually trust with access to our systems.

The direction is clear: as agents take on more human-shaped responsibility, the discipline of software security becomes their discipline too. Build for it on purpose, from the start.