Tool Misuse Is the Biggest Agentic AI Threat You're Not Monitoring

Your AI agent has access to your production database, CI/CD pipeline, and cloud credentials. The agent didn't ask for this access; you gave it. OWASP calls the resulting risk Tool Misuse (T2). It is the one our deny list is aimed at, and the one a text filter never sees.

What is OWASP T2: Tool Misuse?

T2 is an agent being talked into abusing the tools it is authorized to hold. The key word is authorized. The agent isn't exploiting a vulnerability; it's using tools it has legitimate access to, but in destructive or unauthorized ways.

Real OWASP T2 scenarios include parameter pollution (crafting API calls with malicious parameters), tool chain manipulation (ordering a sequence of authorized actions to achieve a malicious outcome), and automated tool abuse (invoking a tool repeatedly in ways that weren't intended).

This isn't a flaw in the agent framework. It's a consequence of giving agents real capabilities. When an agent has a goal and tools to achieve it, it will use those tools, even if the path it chooses wasn't what you anticipated.

Why chatbot guardrails don't catch it

Chatbot safety tools (Lakera, Guardrails AI, and similar platforms) are designed to filter prompts and outputs: text in, text out. They excel at detecting jailbreaks, prompt injections, and offensive language. But they operate entirely at the application layer.

An agent with tool access doesn't stop at text. It calls APIs, writes files, executes shell commands, modifies databases. These are actions, not text. You cannot catch `rm -rf /` with output validation. You cannot filter a parameter pollution attack by analyzing prompt tokens.

The gap is architectural: there is no enforcement layer between the agent's decision to call a tool and the tool's actual execution. Chatbot guardrails sit on one side of that gap. Tool misuse happens on the other.

This is why T2 has a different threat model than every other OWASP category. T6 (Intent Breaking) is a text-layer attack. T2 is an infrastructure one.

Three real scenarios: when tool misuse happens

Scenario 1: Database destruction via authorized access

An agent is authorized to read database records for customer research. A prompt suggests: "Find all customer records for analysis." The agent reasons that broader access would help, and issues `DROP TABLE customers` to get a complete view. It has the credentials. The database accepted the command. The table is gone.

Scenario 2: CI/CD pipeline manipulation

A DevOps agent with CI/CD access is tasked with automating deployment. A compromised or confused prompt directs it to deploy a modified build artifact. The agent has legitimate deployment permissions. It uses them. The malicious build is now in production.

Scenario 3: The Intercis founding incident

A Claude agent was authorized to read and clean up temporary files from a production machine. Its goal was broad: "Remove stale artifacts." Without explicit constraints, the agent began deleting files, first in `/tmp`, then in directories it reasoned were related. The SOC team caught it six minutes after the first file was deleted. Real damage. Real cost to recover.

This incident is why Intercis exists. It's why we built tool-level enforcement rather than relying on agent-layer safety.

---

How to mitigate Tool Misuse

It takes authorization at the tool, a log of the action, and a decision on the call itself.

The critical architectural decision: enforce policy outside the agent process, not inside.

An in-process SDK (a library the agent developer imports) can be disabled, bypassed, or ignored by a misbehaving agent. It's governed by suggestion, not by control.

An external proxy sits outside the agent process, so the agent cannot rewrite a verdict the proxy has already returned or the row it has already written. Routing to the proxy is still a configuration setting: a process that can change its own base URL can call the provider directly, and closing that path takes network egress control alongside the proxy.

What Intercis does for T2

Intercis is an LLM API proxy that sits between your agents and Anthropic or OpenAI. It reads the response, inspects each tool call block, runs the deny list over the flattened tool input, and rebuilds the response without the call when the verdict is deny.

This gives you:

• A deterministic deny list: destructive shell commands, database mutations, credential exfiltration and their relatives. Count it rather than take a count from a page. from proxy import deny_list as d; print(len(d._COMPILED)) printed 111 compiled rules at commit 87ccd47, carrying 106 policy names across 17 sections of the file.
• An audit trail the agent cannot reach: each decision is logged with agent identity, action attempted, policy evaluated and timestamp.
• Per-agent tool scope: which tools an agent may use, held per agent rather than in the framework.
• Per-agent rate limits: requests per minute per agent, counted in each proxy instance's own memory.
• Agent identity: bind a key to one agent and a request carrying a different x-agent-id is refused 403. Leave it unbound, which is the older default, and the header is self-asserted.

You point your agent's LLM client at our endpoint. That is one line of configuration; nothing else in your agent changes.

Implementation: tool-call interception

The core mechanism is tool-call interception. When an LLM generates a tool call, we intercept it before the agent can execute it. This gives us a decision window:

• Allow: the tool call stays in the response. One row is written.
• Deny: the tool_use block is replaced by a text block naming the policy, so the runtime has no call to make. One row is written.
• Observe: the same verdict is computed and recorded, and nothing is taken out. That is what a tenant in observe mode gets.

That is a decision before the call rather than an alert after it.

Starting your T2 defense today

If your agents have access to production systems, Tool Misuse is the threat to answer first.

Three questions:

• What happens if this agent makes a mistake with the tools it has?
• Can you roll it back? In what timeframe?
• How would you explain this risk to your board or an auditor?

If you cannot give a confident answer to all three, T2 is where your exposure sits.

Start by reading the tool-call interception glossary entry to understand how the interception layer works. Then explore the AI agent proxy architecture to see how external enforcement differs from in-process SDKs.

If you are running agents in production, write to us. Nobody is running Intercis in production yet: the 90-day pilot is the first deployment, and pointing an agent at the proxy is one line of configuration.