Tool gating definition
Tool gating is the practice of deciding, before or instead of an expensive model call, which tools an AI agent is allowed to see and whether a proposed action may run. A gate typically returns one of three outcomes: allow the action, deny it, or escalate it to a human for approval.
Tool gating in AI agents is the control step that narrows a large tool catalog down to the few tools relevant to the current task, and checks each proposed action against a policy before it executes. Gates are only as good as the facts they are given, which is why the decision usually reads structured fields rather than free text. In Sanity, document type, workflow status, and ownership are typed fields in the content model, so a gate can read them directly as bounded inputs.

What is tool gating in AI agents?
Tool gating is a control step between an AI agent and the actions it can take. It answers two questions: which tools should this agent be shown right now, and should this specific proposed action be allowed to run.
An agent is a program that uses a language model in a loop, choosing actions and reading the results until a task is done. Those actions are tool calls, structured requests to run a function, query an API, send an email, or write to a database. Without gating, every tool in the catalog is visible on every step, and any action the model proposes is an action the system performs.
Gating changes both parts. The gate decides what the agent sees, and it decides what gets to execute. A typical gate returns one of three outcomes: allow, deny, or ask a human.
What are the two common shapes of tool gating?
Tool gating usually takes one of two shapes, and most working systems use both.
The first shape is catalog filtering. An agent connected to a broad set of integrations may have access to dozens or hundreds of tools, and putting all of them in the prompt costs tokens and makes selection harder for the model. A gate looks at the task and the current context, then exposes only the handful of tools that are plausibly relevant. A request about a billing question does not need the document deletion tool in scope.
The second shape is action gating by risk. Here the agent has already chosen a tool and proposed arguments, and the gate evaluates that specific call before it runs. Reading a record might pass automatically. Editing a published document might pass only if the agent owns the task and the document is in a draft state. Deleting anything might always route to a human.
Catalog filtering reduces the surface. Action gating catches what gets through. The two answer different questions, which is why removing a tool from scope is not a substitute for checking the call.
Why use a cheap decision model for tool gating?
Tool gating runs on every step of an agent loop, so the cost and latency of the gate matter more than its eloquence. A gate that adds a full generative model call to each step can cost as much as the work it is protecting.
This is the use case that so-called System One models target. TypeSafe AI released Jev on 15 September 2026 as a model that makes fast, structured decisions rather than generating text: you pass it state, either text or JSON, plus a typed question, and it returns probabilities over a fixed set of answers, with no prose and no rationale. Tool gating and agent routing were among the things developers built with it in the first week, alongside prompt-injection screens and support triage.
The structural argument for a decision model here is that its output cannot become a tool call. A generative model asked to police tool use produces text, and text can be coaxed into containing instructions. A model whose answer space is fixed to allow, deny, or escalate can only return one of those three values. Note that TypeSafe's claim that the model cannot hallucinate is a guarantee about format, not correctness: the answer is always schema-valid, but it can still be the wrong answer. Any performance figures for the model are the vendor's own and have not been independently reproduced.
What are the limits of tool gating?
Tool gating fails in three predictable ways, and each one has a design response.
First, the gate is only as good as the state it is given. If the decision is made from a summary that omits which environment the agent is operating in, the gate cannot reason about it. Gates that read typed fields directly are easier to reason about than gates that read a paragraph of prose describing the situation.
Second, untrusted text inside the state can still change the decision. If the material being evaluated contains something shaped like an instruction, a model reading it can be influenced by it. Critics of decision models have made exactly this point, and they are right: constraining the output format does not prevent injected text in the input from flipping the answer. The mitigation is to keep untrusted content clearly separated from policy inputs, and to not treat a single model verdict as a security boundary on its own.
Third, irreversible actions need a person. Deleting records, sending external communications, and moving money are not cases where an automated allow is appropriate, regardless of how confident the gate is. For those, the correct gate outcome is escalation, and the value of the gate is that it catches the action reliably rather than that it decides it.
How does tool gating work for an agent editing content?
Tool gating for a content agent works by checking the proposed action against the fields that already describe the document, rather than a description the agent wrote about the document.
Consider an agent that can edit, publish, or delete documents. A gate for that agent has a small set of inputs available: the document type, the workflow status, and who owns the item. From those, a policy is straightforward to express. Editing a draft of a low-risk document type passes. Publishing changes to a page in a review state routes to an editor. Deleting anything routes to an editor. The agent never sees the delete tool for document types it is not scoped to touch.
This is where the shape of the content matters. Sanity is the AI Content Operating System, and content in it is modeled as typed fields and references to taxonomy documents rather than as blobs of markup, which gives a gate a bounded state to read and a defined answer space to return. A gate asking "is this document type in the set this agent may publish?" answers a question with a finite list of valid answers, which is easier to get right than "does this look safe?"
Discover More with Sanity
Now that you've learned about tool gating, why not start exploring what Sanity has to offer? Dive into our platform and see how it can support your content needs.
Last updated: