Agents, tools and excessive agency

A chat reply that is wrong is a problem. A tool call that is wrong is an incident. Every diagram so far has had an output that triggers actions through agents or tools, and in several of them the model’s output also becomes new instructions fed back into the model ^[1]. This lesson is about that action layer, which decides how much damage a successful injection can do.

The chain: injection plus a tool

Combine the previous two lessons with a capability. A hidden instruction in an email arrives through retrieved data. The model, which cannot tell data from instructions, follows it. The model has a tool that can read mail and one that can send it. The result is the series’ exfiltration example, where the model searches for particular messages, encodes what it finds and sends it to an attacker-controlled address, then summarises the email as usual and says nothing ^[2]. No exploit code was needed; the permissions did the work.

What OWASP calls excessive agency

OWASP’s 2025 list includes LLM06, Excessive Agency. It starts from the observation that an LLM-based system is often granted agency by its developer, “the ability to call functions or interface with other systems via extensions”, and names three root causes ^[3]:

• Excessive functionality: an extension offers operations the application does not need.
• Excessive permissions: an extension has broader access to downstream systems than its task requires.
• Excessive autonomy: high-impact actions happen without verification.

Its prevention advice reads like a least-privilege checklist: minimise extensions and their functionality, avoid open-ended extensions, minimise permissions, run extensions in the user’s own context, require user approval, apply complete mediation, and sanitise inputs and outputs. OWASP adds that logging, monitoring and rate limiting can limit damage but do not remove the vulnerability itself ^[3].

How to test an agent

1. Inventory. List every tool the agent can call, with its permissions, the data it can reach and any approval gate. You cannot assess what you have not listed.
2. Ask the three questions per tool: is the function needed, are the permissions minimal, is a person confirming the high-impact actions?
3. Plant a harmless action marker. In a sandbox, give the agent a tool that writes a fixed line to a log file you own, then use indirect injection (lesson 4) to try to make it call that tool from a document. If it does, a real tool would have been called too.
4. Check the boundaries. Can the agent act in another user’s context? Can it reach systems outside its task? Can a tool’s output become a new instruction?
5. Record the result as a permission finding: the right fix is usually to remove capability, not to add more prompt text.

Defences that scale with the risk

• Remove tools the task does not need. Capability you never grant cannot be abused.
• Narrow permissions so that a hijacked agent can do little.
• Put a person in the loop for sending, deleting, paying and other irreversible actions.
• Make outbound behaviour visible, so an unexpected connection or message stands out.