How do you protect an AI agent's tools from misuse?

Treat every tool as a privileged interface, not a convenience. Give each one an owner, a narrow contract stating exactly what it does, strict validation of every input, a check against the calling agent's bounds on every use, and a record of each call. Register tools centrally so nobody can add, alter or swap one without change control.

Why are tools where misuse happens?

The model only produces text. Tools turn that text into effects: a record changed, a message sent, money moved. Our explainer on how an AI agent uses tools covers the mechanics. Every route from a manipulated or mistaken model to real harm passes through a tool.

That is also why an agent is more than a chatbot with tools. The tools, and the controls around them, define what the agent is.

Misuse comes from three directions: the agent calls a tool for the wrong purpose, with the wrong inputs, or the tool itself is altered so that it does something other than what its description says.

What are the steps, and who acts?

1. Platform team: registers every tool. One catalogue, with a named owner per tool, its description, inputs, outputs, the systems it reaches and its version. Evidence: the catalogue.
2. Tool owner: writes a narrow contract. "Update the delivery address on an open order for the authenticated customer" is a contract. "Update order" is not. Evidence: the contract text, reviewed.
3. Tool owner: validates inputs. Types, ranges, formats and relationships: an order number must belong to the customer in the conversation; an amount must be positive and below the tool's own ceiling. Evidence: validation rules and rejected-call logs.
4. Platform: checks each call against the calling agent's bounds. The same tool may be allowed for one agent and refused for another. Evidence: filed verdicts naming the agent and tool.
5. Security: protects tool definitions. Descriptions and code change only through change control, because an altered description can steer the model and altered code can change the effect. Evidence: version history and approvals.
6. Platform team: separates conflicting tools. No single agent should hold both the tool that prepares an action and the tool that approves it. Evidence: the tool-to-agent matrix.
7. Tool owner: reviews usage monthly. Unusual callers, volumes or input patterns. Evidence: the review note.

What makes a tool safe or risky?

Why does separation of duties apply to tools?

Because a tool is where a duty gets done. If one agent holds the tool to create a supplier and the tool to pay one, the separation that protects you from payment fraud is gone, however well behaved the agent is. We argue in separation of duties still applies when the worker is software that tool assignment is where that principle is won or lost.

A worked example

Take a retailer's customer agent with a tool called "issue store credit". The tool takes a customer number and an amount.

In a review, the tool owner notices calls where the customer number in the tool call differs from the customer in the conversation. A customer had been asking the agent to "also credit my partner's account". The agent's bounds allowed store credit up to 20, and the tool happily applied it to any account. The owner changes the contract: the tool now accepts only the authenticated customer's number, validated against the session, and has a built-in ceiling of 20 regardless of agent limits. The next attempt is rejected at validation and recorded.

Which controls make the answer hold?

• A registered, owned catalogue of tools.
• Narrow contracts and strict validation.
• A check on every call against the caller's bounds.
• Tool definitions changed only through change control.
• Conflicting tools never held by one agent.

The topic guide, agent governance is a bound, not a model, explains why the check on each call sits outside the model.