AI agent governance has to happen before the tool executes

Most AI governance programs are good at reconstructing what a model produced. They capture prompts, outputs, traces, tool calls, latency and policy violations.

That is useful. It is not enough once an agent can move money, change access, update a customer record, deploy code or trigger a physical process.

The decisive question is no longer only, “What did the model say?”

It is: “Should this specific action be allowed to create a consequence now?”

The action boundary is the control point

A dependable control path sits after the agent proposes an action and before the external system changes state.

At Prudenze, we separate six questions that are often collapsed into one:

1. Who is acting? The authenticated human, workload, service or agent.
2. What authority was delegated? The exact action, resource scope, limits, expiry and accountable principal.
3. What does policy require? Prohibitions, thresholds, lifecycle conditions and approval requirements for this action.
4. Is the decisive evidence still current? The facts that justified the action may have changed while the agent was reasoning or waiting.
5. What actually executed? A tool response is not always authoritative evidence of the external effect.
6. Can the full decision be reconstructed? Authority, policy, evidence, disposition, approval, execution and verification need one durable relationship.

Authentication answers the first question. It does not answer the other five.

A concrete example

Suppose an operations agent proposes an urgent supplier payment.

A monitoring product can show the prompt, model and payment tool call. A governance control has to establish more:

• Is the action normalized with a named payer, beneficiary, amount, currency and invoice?
• Does the agent's delegation cover this supplier, account, action type and amount?
• Does current policy permit automatic release, block it, or require a specific approval role?
• Are the invoice, supplier status and beneficiary details still the same facts used when the proposal was formed?
• If a human approves, did that person authorize this payment instance within their own scope?
• After execution, do the bank receipt and ledger state match the action that was permitted?

If the beneficiary details changed after the proposal, confidence is irrelevant. The decision basis is stale. The original action should not continue.

PERMIT, BLOCK or ESCALATE

The result at the boundary needs to be small and unambiguous:

• PERMIT: authority, policy and current-evidence requirements are satisfied.
• BLOCK: a prohibition, missing authority, stale dependency or failed requirement prevents execution.
• ESCALATE: a defined human decision or additional evidence is required before the action can continue.

An escalation is not a broad transfer of authority. It should bind the reviewer, the exact action, the permitted changes and the validity window. If the action changes materially after approval, it should be evaluated again.

Freshness is narrower than truth

A correct decision can expire between reasoning and execution.

The agent may have read an active account, an approved vendor record or available inventory. While the action waits in a queue, that state can change.

The practical answer is not to reload the entire context before every tool call. The decision should declare the evidence that was material to it, then revalidate those dependencies immediately before execution.

That produces three useful states:

• CURRENT: the declared evidence still matches.
• STALE_REASONING: a material dependency changed.
• UNVERIFIABLE: the required evidence cannot be checked reliably.

Freshness does not prove that the original source was authoritative or that the model reasoned correctly. It proves something narrower: whether the declared evidence stayed current across the time-of-check to time-of-use gap.

Monitoring is not enforcement

Observability helps teams investigate behavior. Execution governance constrains behavior before it becomes an external effect.

You need both, but they answer different questions:

• Monitoring: What did the agent attempt, and why?
• Governance: May this action execute under current authority, policy and evidence?
• Verification: What effect did the external system actually produce?

That separation is the core of the Prudenze governance model. The full architecture, decision-record model and enterprise implementation priorities are here:

https://prudenze.com/insights/ai-agent-governance-before-execution

I work on Prudenze. The article is based on the control boundaries we use across authority, policy evaluation, evidence freshness and execution verification—not on customer claims or invented benchmarks.