Advanced8 min read

Tool Abuse and Excessive Agency

Excessive agency (OWASP LLM06) is giving the model more power than the job needs. Tool abuse is what happens when that power is aimed badly — by a user, a plant, or a bug. The fix is a smaller kit plus gates, not a stricter paragraph.

Explain like I'm new to AI

Agents are useful because they act. Every action is a loaded permission. If one process can read mail, send mail, refund, and run shell, then one successful injection has a buffet.

read_mailsend_mailrefundshelldelete_account

One injected sentence can pick the most powerful tool. This is excessive agency (OWASP LLM06).

Agency is a product choice. If the model can do it, injection can try to do it. Shrink the kit.

MCP security is the catalog version of this: poisoned descriptions, over-scope servers. Same moral: the model proposing delete_account is not authorization.

Mental model

A receptionist with the master key vs a receptionist with a button that prints a request for the manager. Agency is how many keys hang on the hook.

How it works

Inventory tools. For each: what's the worst case if it fires with attacker-chosen args?
Split read routes from write routes. Summarize-URL should not include send-mail.
Args: schema, enums, server-side identity (the user id comes from the session, not from the model).
Irreversible: HITL with the exact args shown (human-in-the-loop lesson).
Trace every tool span (agent-traces). Polite text can still have called the bomb.

Rate-limit and cap loops so a confused agent doesn't refund 400 times (unbounded consumption).

Real-world example

"Cancel my order" → model calls delete-user because the tool names were vague. That's abuse without a genius attacker. Good names + schema + confirm would have stopped it. Injection would have used the same hole.

Technical explanation

Authorization in your API, not in the prompt: the token is the user's, scoped. The model never gets a god token "for convenience" (token passthrough in MCP).

Dual-LLM: untrusted reader cannot invoke privileged tools; a policy layer in code maps intents to allow-listed functions.

Don't implement "are you sure?" as another model call. That's still the model.

Common mistakes

Common mistake

One mega-agent with every plugin enabled so demos look magic.

Trusting tool args for user_id.
No HITL on money, mail, or delete.

When to use it

Any tool-using system. Start from the smallest kit that still does the job.

When NOT to use it

Don't add shell "just in case." Don't skip HITL because staging data "isn't real."

Alternatives

Workflow with explicit steps (no open tool pick). Less flexible, much smaller agency.

Quick quiz

Related concepts

Human-in-the-Loop — Human-in-the-loop inserts a person's approval before risky or irreversible agent actions, combining autonomy with safety and accountability.
MCP Security Risks & Best Practices — MCP's real risks are poisoned tool descriptions, confused-deputy OAuth, token passthrough, and untrusted servers — treat catalogs as untrusted.
Agent Permission Boundaries — Least privilege for agents is a stack — caller identity, tiny tool kits, schema-checked args, human approval, sandbox — so a swayed model cannot exceed the job.

NextRAG Poisoning

Last reviewed: 2026-09-04 · Written by ByHeart AI · Reviewed by ByHeart AI