Introduction
Most checks read content. This one reads intent — it looks at the tools an agent is about to invoke and stops the ones it must never call.
That makes it the check that limits blast radius. An agent can be talked into anything; it cannot call a tool it is not permitted to call.
What it detects
"Tools the agent may never invoke, regardless of context."
The last three words are the design. This is not a judgement about whether a particular call looks reasonable — it is a standing prohibition that holds however persuasive the reasoning was.
How it works
You define rules that describe the tools to block. Each rule is a condition — the tool Contains or Doesn't contain a keyword — and rules combine with Match any or Match all.
Match any — Blocks if any rule matches. The default, and the broad, safe choice.
Match all — Blocks only when every rule matches. Use to carve out a narrow class — a tool that both contains "delete" and contains "prod".
Keyword matching means naming conventions do real work here. A tool estate with consistent names (delete_*, *_prod) is one you can govern with three rules; an inconsistent one needs a rule per tool.
Where to run it
Applied on | Supported |
| Yes — the natural point, before the call is made |
| Not meaningful for this check |
| Not meaningful for this check |
| Not meaningful for this check |
| After the fact — the call has already happened |
Run it on Tool name. Anywhere else and you are recording that something happened rather than preventing it.
The caveat that matters most
This check is only as useful as the connection tier allows.
On Control · Enforced, a blocked tool call does not complete — the prohibition holds. On Observe · Advisory, UnifyApps is not in the request path, so the tool is called and an incident records that it was.
"On an advisory connection this is an alarm, not a lock. Both are useful — but only one of them stops the delete."
Where you need a genuine prohibition and the connection is advisory, the durable control is the tool permissions on the agent's own platform. Use this check for the cross-platform record and for agents you can enforce on.
What to block
Destructive operations — Anything that deletes, purges or truncates. The cost of a false positive here is an agent that cannot do something; the cost of a miss is data.
Production writes from agents that should only read — The most common real finding. A research agent with a write tool it never needed.
Payment and transfer operations — Unless moving money is explicitly the agent's job, and even then, scoped.
Tools that reach a different tenant or environment — Cross-environment access by accident is a recurring theme.
Known limitations
Keyword matching, not semantics — A destructive tool named without a matching keyword is not caught. Audit tool names before relying on a rule set.
Advisory connections cannot prevent — See above. This is the single most important thing to confirm before promising anyone a tool is blocked.
It governs the call, not the consequence — A permitted tool used badly is a different problem, and a different check.