AI Agent Governance Begins Before Execution

The thesis: govern the consequence, not the conversation

Many AI controls concentrate on the model: prompts, output quality, hallucinations, toxicity, traces and drift. Those controls matter, but they address the production of a proposal. They do not, by themselves, establish that the proposal is authorized to execute.

A language model can recommend a payment, account suspension, claim disposition, inventory transfer or security response. The consequence occurs only when another system accepts that proposal and changes state. That transition is the governable point. The model may remain probabilistic while the execution decision is explicit, reviewable and fail-closed.

This leads to a practical separation of responsibilities: the agent proposes; an independent control path determines whether the proposal may proceed; the business system executes; and a verification path establishes what actually happened.

Five definitions that prevent category errors

Established foundations—and the Prudenze position

Several parts of this problem are established security and risk-management concerns. The NIST AI Risk Management Framework calls for AI risks to be governed, mapped, measured and managed throughout the system lifecycle. NIST's Zero Trust Architecture treats authentication and authorization as discrete functions before access to a resource is established. The IETF's RFC 9396 provides a standards-track mechanism for carrying fine-grained authorization details about a resource and requested actions.

State change between a check and a use is also a known software-security class.MITRE CWE-367 describes the time-of-check to time-of-use problem: a resource can change after it is checked and invalidate the result. Evidence freshness for an AI decision is not identical to a filesystem race condition, but the control lesson is relevant: a fact checked earlier cannot be assumed unchanged at the moment of use. OWASP's Excessive Agency guidance likewise recommends tracking user authorization and downstream security scope while applying minimum necessary privileges.

Prudenze's position is the architectural synthesis, not a claim that these sources prescribe the Prudenze runtime. For a consequential AI action, identity, bounded authority, action-specific policy, evidence validity, scoped approval and execution verification should meet at one enforceable boundary before the action becomes a real-world consequence.

A reference architecture for consequential AI action

Prudenze's technical work uses a control chain that keeps these concerns distinct while connecting them in one decision record. The chain is intentionally placed after the agent proposes an action and before the external system creates the effect.

The components have different jobs. Arkon represents identity and delegated authority context. Guardian configuration connects policy, approval and lifecycle requirements to the proposed action. FreshCtx owns evidence-validity checking at the runtime boundary: it does not grant authority or prove an external effect. Guardian owns the final action disposition and approval requirement. Revera compares reported behavior with observable effects under controlled, reproducible conditions. A Governed Decision Object, or GDO, connects the inputs and outcomes without pretending that one component proved what another did not.

Identity is necessary. Authority is the harder problem.

An authenticated agent can still be unauthorized for a particular consequence. Consider a claims assistant that can read a case file and draft an appeal. Valid credentials establish access to the application. They do not necessarily confer the authority to submit the appeal, change the claim state or approve payment.

Action authority must therefore be evaluated against the requested capability. A useful authority statement includes the accountable principal, the party on whose behalf the agent acts, the application, the action, resource scope, structured limits, and an expiry or review boundary. Broad labels such as “claims agent” or “finance bot” are insufficient because they hide the target and consequence.

This is why “the agent is authenticated” and “the action is authorized” are different statements. A workload identity can establish which process presented the request. Authorization must still bind the proposed operation to the resource, amount, purpose and limits allowed by the principal. Fine-grained authorization models such as RFC 9396 make the same distinction concrete by carrying structured action and resource details rather than relying only on a broad scope string.

Authority is also not the final decision. A decision can be logically valid against the evidence it evaluated and still not constitute permission to execute. Policy may prohibit the action, require a named approval role, impose a lower limit, or require evidence that is no longer current. Keeping these layers separate makes both enforcement and review more precise.

The decision should be PERMIT, BLOCK or ESCALATE

A control point needs a small, unambiguous result vocabulary. At the architecture level, three outcomes cover the essential paths:

Prudenze's current Guardian configuration expresses these operationally as ALLOW, DENY and ESCALATE. The naming matters less than the semantics: no ambiguous “warning” state should allow an external system to continue by default.

Escalation deserves special care. A human review must not retroactively make the agent more powerful. The reviewer's authority, the exact action reviewed, any approved changes and the validity window belong in the record. If the action changes materially after approval, it should be evaluated again.

A blanket approval such as “allow the finance agent” is not an adequate escalation result. A scoped authorization should bind the reviewer's decision to the named payment, claim, account change, purchase order or operational instruction. The amount, target, allowed mutation, expiry and any conditions should travel with the authorization into the execution boundary.

A valid decision can expire before the action starts

The interval between reasoning and execution is a distinct risk surface. An agent may reason from an approved vendor record, an available inventory balance or an active account. While the action waits in a queue or approval step, the vendor's bank details may change, inventory may be reserved elsewhere or the account may be revoked.

Revalidating every available fact is neither necessary nor realistic. The decision should declare its decisive dependencies: the evidence whose change could alter whether the action is allowed. Immediately before the protected action begins, the control compares the reasoning-time observation with the current observation.

Freshness does not prove that the original source was truthful, that the model's reasoning was correct or that the action is authorized. It proves a narrower and operationally valuable fact: whether the declared evidence stayed current across the time-of-check to time-of-use gap.

Concrete example: an AI-proposed supplier payment

Suppose an operations agent proposes an urgent payment to a supplier. A monitoring platform can capture the prompt, model, tool call and latency. A governance control must answer a different sequence of questions before the payment instruction reaches the bank:

1. Is the proposed action normalized as a payment with a named payer, beneficiary, amount, currency, invoice and intended settlement date?
2. Is the agent acting for the correct principal, and does its delegation cover this supplier, account, action type and amount?
3. Do current policy rules allow automatic release, prohibit it or require a named approval role because a threshold or exception applies?
4. Are the invoice, supplier status and beneficiary details still the same facts used when the agent formed its proposal?
5. If a human approves, did that person authorize this payment instance within their own scope, rather than grant the agent a broader standing permission?
6. After execution, do the bank receipt and resulting ledger state match the permitted beneficiary, amount, account and transaction identity?

If beneficiary details changed after the proposal, the correct outcome is not “the model was confident” or “the agent was logged in.” The original decision basis is stale. The action should be blocked or recomputed against the new state.

Nothing in this sequence requires the reasoning at T1 to have been poor. It may have been exactly right against the evidence available at T0. The control failure would be treating that earlier reasoning as a standing execution permit after its decisive evidence changed. Pre-action revalidation prevents a once-valid decision from silently authorizing a different current reality.

The same pattern applies beyond payments. A claim can become ineligible before approval, an account can enter a restricted state before modification, inventory can be reserved before a purchase order is issued, or a safety condition can change before an operational instruction reaches a machine or field team.

The decision record is a control surface, not an audit afterthought

A useful record must connect the action lifecycle without collapsing distinct claims into one opaque log entry. At minimum, it should identify:

• The actor, principal and delegation context
• The normalized action, target and material parameters
• The policy version and evaluated rule outcomes
• The decisive evidence references and freshness result
• The disposition and any scoped human authorization
• The execution receipt and observed resulting state
• The verification outcome, timestamps and provenance
• Any mismatch, uncertainty or required remediation

This is the purpose of a Governed Decision Object: to create a durable relationship among authority, policy, evidence, disposition, execution and verification. It should not imply cryptographic attestation where none exists, and it should preserve whether a value came from a live system, a contract representation or a deterministic test fixture.

Monitoring an agent is not controlling execution

Observability reconstructs what the agent and its tools did. It is essential for debugging, incident response and performance analysis. But a trace is normally downstream evidence. It cannot guarantee that a prohibited action produced zero effects unless the execution path itself enforces the decision.

The two systems should correlate their identifiers, but they should not be confused. The OpenTelemetry observability model describes traces as records of a request's path through a distributed system. Those traces can enrich a decision record; they do not grant business authority. Likewise, a workload identity can establish which process is running; it does not prove that the process may release a payment or revoke production access.

What enterprises should implement first

1. Inventory consequential actions. Start with operations that can move money, change access, alter regulated records, affect customers or modify production state.
2. Create a mandatory action boundary. Route each protected action through one enforcement point immediately before the external effect. Unconnected paths remain ungoverned.
3. Separate identity from authority. Map each action to a principal, delegation, resource scope, limits and expiry.
4. Make policy outcomes executable. Define clear permit, block and escalation semantics, including precedence when rules conflict and fail-closed behavior when required inputs are unavailable.
5. Declare freshness dependencies. Identify the small set of facts that must be revalidated at action time.
6. Verify effects independently. Capture an execution receipt and observe the authoritative resulting state, including mismatches and uncertain outcomes.

Begin with one high-consequence action and prove the entire path. A broad governance inventory without an enforced execution boundary can create the appearance of control while leaving the consequential path unchanged.

Connect governance requirements to the action

Organize tenant-scoped authority, policy, approval, evidence-validity and verification requirements around the same consequential action. Guardian configuration records the applicable policy and lifecycle requirements, so teams can review the action, required approval and expected disposition together.

Enforcing those requirements needs connected identity, policy, evidence, runtime enforcement and observation backends. Bind the recorded requirements to the execution boundary, then link the decision to the observed outcome. Where signed or cryptographically attested records are required, connect a system that provides that assurance.

Keep the evidence for each control connected: delegated authority, applicable policy, action-time evidence and independently observed results. This gives teams a traceable basis for deciding whether an action may proceed and investigating any difference between the authorized action and its outcome.

The practical standard

An enterprise should be able to answer one question for every consequential AI action: why was this exact actor allowed to produce this exact effect, on this target, under this authority and policy, using evidence that was still current—and what proves the resulting state?

If the answer exists only in a prompt, trace or post-event audit log, the execution boundary is still uncontrolled. AI agent governance becomes operational when the control system can stop the action before the consequence, route legitimate exceptions to scoped human authority and verify the result afterward.