The action layer: designing safe tools for agents

Most agent discussions fixate on the model: which one is smartest, how good the prompt is, whether it hallucinates. But a model on its own can't do anything to your business. It can only produce text. The moment an agent acts—sends an email, refunds a customer, merges a branch, updates a record, spins up infrastructure—it does so through a tool: a function, an API call, an integration you built and handed it.

That tool layer, not the model, is where the real risk lives. A confused or hijacked agent with read-only tools writes a bad paragraph. The same agent with a delete_customer tool and broad credentials writes an incident report. This post is about designing the action layer so that the worst thing a wrong decision can do is small, reversible, and visible.

The model is untrusted; the tools are the control

Here is the mental model shift that makes agent systems safe: treat the model's output as an untrusted request, and the tool as the thing that enforces the rules. You would never let a web client's request directly mutate your database without validation, authorization, and rate limits. An agent's tool call deserves exactly the same suspicion—more, actually, because the agent's decisions can be steered by prompt injection hiding in the data it reads.

This means the safety of an agent is not primarily a prompting problem. You cannot prompt your way to safety, because the prompt is advisory and the attacker may control part of the input. Safety is an interface problem: the tools you expose, the arguments they accept, the actions they can and cannot take, and the guarantees they enforce regardless of what the model "decided." Encode those decisions as explicit, reviewable agent policy rather than leaving them implicit in a system prompt nobody audits.

Six properties of a safe agent tool

When you design a tool for an agent to call, aim for these properties. Not every tool needs all six, but every irreversible or high-privilege tool needs most of them.

1. Least blast radius

Each tool should do the smallest useful thing, scoped to exactly what a workflow needs. A tool called run_sql(query) hands the agent the entire database and every mistake it can express in SQL. A tool called get_open_invoices_for_customer(customer_id) hands it one safe, well-understood capability. The narrower the tool, the smaller the space of things that can go wrong—and the easier it is to reason about, log, and test.

Resist the temptation to expose a generic "escape hatch" tool (a raw shell, an arbitrary HTTP client, an admin API) because it's convenient during development. Convenience for you is unbounded blast radius for a hijacked agent. Prefer many narrow tools over one powerful one, and pair each tool with the scoped, least-privilege identity that can only reach the specific systems that tool needs.

2. Typed, constrained inputs

Free-text arguments are where injection turns into action. If a tool accepts recipient: string, an attacker who controls the agent's context can try to make that string an exfiltration address. If it accepts recipient_id chosen from a known set of internal users, the same attack has nowhere to go.

Design tool inputs as structured, validated, enumerated wherever possible: IDs instead of free text, enums instead of arbitrary strings, bounded numbers instead of open ranges. Validate on the server side of the tool, not in the prompt. Every constraint you add to the input schema is attack surface you remove—and it shrinks the space the agent can wander into by accident, too.

3. Read/write separation and deny-by-default

Split your tools cleanly into retrieval (read the world) and action (change the world), and start every agent with only the retrieval half. Most valuable agent work—triage, matching, drafting, summarizing, routing—is read-mostly. An agent that reads widely but writes narrowly, through a handful of well-guarded action tools, captures the bulk of the value at a fraction of the risk.

Deny-by-default is the posture: a tool that isn't explicitly granted doesn't exist for that agent. This is the same discipline that keeps retrieval permission-aware so agents can't read past their authorization—applied to the write side.

4. Dry-run and preview

For any tool with real-world effects, build a preview mode: the tool computes and returns exactly what it would do without doing it. "This would refund $4,200 across 3 transactions to customer 5567." A preview lets the agent (and, for anything meaningful, a human) confirm intent against effect before the effect happens. It also makes tools dramatically easier to evaluate, because your regression tests can assert on the planned action without mutating anything.

5. Idempotency and undo

Agents retry. They loop. They occasionally call the same tool twice because a response was slow. Design action tools to be idempotent—calling mark_invoice_paid(id) twice has the same effect as calling it once—using client-supplied idempotency keys so a retry can never double-charge, double-send, or double-provision.

And wherever the domain allows it, prefer reversible actions: soft-deletes over hard-deletes, drafts over sends, staged changes over live ones, quarantines over purges. The goal is that recovering from a wrong agent action is a one-step undo, not an incident. Where a real incident is still possible, have the runbook ready in advance so response is fast and rehearsed.

6. A hard gate on the irreversible

Some actions can't be made reversible or small: moving money, deleting data, changing permissions, deploying to production, emailing a customer base. For these, the tool itself should require an approval that is not the model's judgment—a human confirmation, a second system's sign-off, or a policy check the model cannot talk its way past.

This is the load-bearing principle of the whole practice: keep humans on the risk boundary. The agent proposes; the gate disposes. The worst case for a hijacked, confused, or simply mistaken agent should be a rejected proposal, never a wire transfer. Decide where these gates sit deliberately, and pressure-test the placement against a risk and cost model so you're gating the actions whose downside actually warrants the friction—and not everything else.

Return structured results, and make every call auditable

Tools are also how the agent sees the world, so their outputs shape its next decision. Return structured, minimal results: the fields the agent needs, nothing more. Don't pipe raw untrusted documents straight into the agent's context if you can return extracted, typed fields instead—every blob you hand back is a fresh chance for injected instructions to ride along.

And instrument the tool layer as your source of truth for what actually happened. Every tool call—arguments, decision, result, and whether it was previewed, gated, or executed—should leave a tamper-evident trace, feeding the same observability and audit trail you'd want for any consequential system. Because tools are a narrow, well-defined chokepoint, this is easy to do well: you're logging a bounded set of function calls, not trying to reconstruct intent from free-form model output. Route those traces into a review dashboard so the people accountable for the workflow can spot-check what the agent did and feed the misses back into your tests.

A checklist for shipping a new agent tool

Before you expose a tool to an agent, walk it through these questions:

1. What is the worst thing this tool can do if called with adversarial arguments in the worst order at the worst time? If you can't answer, you're not ready to ship it.
2. Is it as narrow as it can be? Could you split one broad tool into several specific ones?
3. Are the inputs typed and validated server-side, with IDs and enums instead of free text wherever possible?
4. Is it read or write? If write, does the agent actually need it yet, or can you ship read-only first?
5. Can it preview? Can it be made idempotent? Can its effect be undone?
6. Does anything irreversible sit behind a human or policy gate the model can't bypass?
7. Does every call emit a complete, tamper-evident trace?

This is the same shape as a good security review for any dev tool or agent—applied at the granularity of the individual capability, which is where the failures actually happen.

Why this becomes the norm

For a while, teams will keep bolting agents onto whatever APIs they already had, discover that a generic tool plus broad credentials is a bad idea, and learn the lesson the expensive way. Then the practice will settle, the way input validation and least-privilege settled for web apps: the action layer becomes the place you invest in, and the model becomes a component you can swap.

That is agent-driven development growing up. The winning teams won't be the ones with the cleverest prompts. They'll be the ones who built a tool layer where autonomy is genuinely safe—narrow capabilities, validated inputs, reversible-by-default actions, hard gates on the irreversible, and a complete audit trail—so they can hand agents more and more real work without holding their breath. In a few years, "the agent can only act through reviewed, scoped, auditable tools" will be as unremarkable as "the web server validates its inputs." The teams that get there first get to move fast because the floor is safe.

Where we can help

If you're deciding which capabilities to expose to your agents and how to gate the dangerous ones, that's exactly the work we do. Tell us about your workflows or read the consulting offer—we start by mapping the actions, shrinking the blast radius, and putting humans on the boundary that matters.

Related tools: Agent Policy Builder • Risk & Cost Simulator • Incident Runbook Generator