The tool call is the control point

Where the risk actually lives

Most AI governance spending lands on the conversation: prompt filters, output classifiers, usage dashboards. That made sense when the failure mode was an employee pasting a deal memo into a chat window.

It stops making sense the moment an agent has tools. An agent that reads a file, calls an API, writes to a database and emails a summary has exercised four separate authorities without a single prompt worth inspecting. The consequential act is the call, and the call is the thing most stacks never see.

Three properties of a real checkpoint

If a control is going to survive an agent running unattended, it needs to hold three properties at once.

• It sits in the execution path, so it cannot be routed around by a different prompt.
• It is deterministic, so the same action gets the same answer at 3am as in the design review.
• It writes its decision down before the action happens, not after it succeeds.

Why the model cannot be the judge

The tempting shortcut is to ask a model whether an action seems acceptable. This fails for a structural reason rather than a quality one: a probabilistic component cannot be a trust boundary, because its worst failure is to be confidently wrong.

The workable split is narrower. Ask the model only what kind of action this is — a typed classification, with a calibrated confidence — and let deterministic rules decide what happens to that type. When the classification is missing, stale or low-confidence, the rules decide that too.

Start by watching

Before blocking anything, run the checkpoint in observation and collect what your agents actually attempt: action types, resource sensitivities, purposes. Nearly every team is surprised by something in the first week, and the surprise is what makes the enforcement conversation short.