Treat Agent Tool Access Like IAM, Not Like a Feature Flag

When a team adds a tool to an agent, the easiest path is almost always to wrap the most convenient existing client: the full email SDK, the full database connection, the full cloud API key. The tool description tells the model what it's *supposed* to use the tool for, and the system prompt reinforces it with a sentence like "only send receipts, never marketing emails." That sentence is not a security boundary. It's a request, and requests can be misread, argued around by injected content in a document the agent is summarizing, or simply gotten wrong by a model doing its best with an ambiguous instruction.

The actual security boundary is whatever the credential behind the tool can technically do. If the "send a receipt" tool is backed by an API key that can also send to arbitrary addresses, delete templates, or read the full customer list, that is the tool's real permission — regardless of what the docstring says. This is the same lesson infrastructure teams learned years ago with IAM: a service account scoped to "can invoke this one Lambda" is safer than one scoped to "AdministratorAccess" with a comment saying "only use for Lambda." Agent tools deserve the same discipline, and most teams haven't gotten there yet because the tool was built to solve a demo, not to survive contact with a model that will eventually be steered — by a bad prompt, a confused chain of reasoning, or someone else's malicious input — into calling it in a way nobody planned for.

Scope the credential before you scope the prompt

Start every new tool by asking what the narrowest possible backing permission looks like, before writing a word of the tool description. If the agent needs to look up an order status, the credential behind that tool should be able to read orders and nothing else — not read-write access to the orders table, not access to other tables that happen to share a connection pool. If the agent needs to post a Slack message, mint a bot token scoped to one channel rather than reusing a workspace-wide token that happens to be lying around. This is more setup work per tool, which is exactly why it gets skipped under deadline pressure — but it's also the only control that still holds if the model's behavior surprises you, which it eventually will.

Design for the plausible-but-wrong call

The failure mode to design against isn't the model trying to misbehave — it's the model making a confident, well-formatted call with the wrong parameters. A refund tool called with the wrong order ID. A file-delete tool called on a path that looks like the one described but isn't. Treat every tool call as if it came from a competent but occasionally careless junior engineer with the credential's exact permissions, and ask what the blast radius is when they get one field wrong. If the honest answer is "significant," the fix isn't a stronger prompt — it's narrowing the permission, adding a confirmation step for the specific high-cost operations, or splitting one broad tool into several narrow ones where only the low-risk ones run without a gate.

None of this requires exotic infrastructure. It requires treating the permission grant behind a tool as a design decision with the same weight as the tool's interface, and revisiting it every time a tool's scope quietly grows because it was convenient to reuse an existing client. The agent's intent is not the control. The credential is.