What Actually Makes an Agent Dangerous

Side effects are the real dividing line

What makes an agent dangerous is not how intelligent it is. It is how many side effects it can produce, and how little supervision stands between it and those side effects.

A very capable model with read-only access to public data is a research assistant. A mediocre model with write access to your infrastructure is an incident.

This matters because the industry conversation focuses almost entirely on model capability — benchmarks, reasoning ability, context length. Those determine whether the agent is useful. They barely determine whether it is safe.

Your security review should spend its time on the tool list, not the model card.

The question nobody asks

One question separates teams ready to deploy an agent from teams who are not:

What happens when it is wrong at three in the morning?

Not compromised. Just wrong. It misread the conference date. It booked the wrong city. It interpreted "budget: $2,000" as a target rather than a ceiling.

Who notices? How long does it take? What is the state of the world by then? Can it be undone? Who pays?

Notice: this question involves no attacker at all.

If a system cannot survive being wrong, it certainly cannot survive being attacked. And the controls that contain honest mistakes — spend caps, allowlists, reversibility, alerting — are the same controls that contain attacks.

Multi-agent systems

When agents talk to other agents, two new problems appear.

Trust between strangers. Your agent must decide whether to believe another agent it has never interacted with, operated by someone it cannot identify.

Compromise cascades. If agent A trusts agent B's output and B is compromised, A is now processing attacker-controlled input from a source it considers trustworthy. In a network, this propagates faster than a human can observe it.

Multi-agent systems are not just several agents. They introduce trust relationships between components you do not control — a category change, not a quantity change.

Working through four systems

System A. An agent that summarises your unread email each morning. Read-only inbox, no other tools.

Autonomy moderate, tool access read-only, no write authority. Dominant risk: data exposure, not action. Secure the data path.

System B. An agent that triages support tickets and can issue refunds up to $50 without approval.

Low autonomy per decision, high volume. Economic capability is capped per transaction and uncapped in aggregate. Dominant risk: the missing cumulative limit — a real and common design error.

System C. An agent with no tools at all, but persistent memory shared across all users of a workspace.

Zero action risk. Dominant risk: cross-tenant leakage through memory. No amount of tool sandboxing helps; the problem is entirely in the data layer.

System D. An agent that reads public web pages and posts summaries to an internal Slack channel.

Looks harmless. But it ingests untrusted content and writes to a channel humans trust. It is a content-injection pipeline into your organisation's attention.

Common misconceptions

"An agent is anything that uses an LLM." The model is a component. What makes something an agent is the loop and the side effects.

"More autonomous means more advanced." Autonomy is a design choice with a cost. Many well-engineered systems deliberately keep autonomy low and tool access high, because a human approval step is cheaper than the controls that would otherwise be required.

"If we use a safer model, the agent is safer." A better-aligned model refuses obviously harmful instructions. It does nothing about an over-scoped API key, an unbounded spend limit, or a tool that leaks credentials.

"Multi-agent systems are just several agents." They introduce trust relationships between components you do not control.

"Our agent only reads data, so it is low risk." Reading is how untrusted content enters. If the agent reads attacker-influenced content and then does anything with the result — including writing somewhere a human reads — you have a path.

Knowledge check

1. What distinguishes single-turn inference from a tool-using agent? 2. Name the five axes of agency. 3. Why do the axes multiply rather than add? 4. Which is more dangerous: a highly capable model with read-only access to public documents, or a weak model with write access to production? Justify in terms of side effects. 5. Why is persistence a security concern and not only a privacy concern? 6. What is the significance of the moment an agent's output starts being read by a machine rather than a human?

Key takeaways

• Side effects, not intelligence, determine danger. Review the tool list before the model card.
• A system that cannot survive being wrong cannot survive being attacked — and the controls are largely the same.
• Multi-agent systems introduce trust relationships you do not control.