Runtime control for ai approvals prevents invalid executions in workflows

Runtime Control for AI Agents: Closing the Evaluation--Execution Gap in Operational Workflows

Artificial Intelligence

Summary

Approvals made by AI agents can become outdated if important facts or rules change after they are given, creating a gap between when an approval is evaluated and when it is executed. The authors propose a system that keeps track of the conditions under which approvals were made and checks again before taking action, stopping invalid or expired approvals from executing. They tested this system on a replay of workflow cases, showing it can catch and delay actions based on approvals that no longer hold, which improves safety in automated workflows.

What this means in practice

  • For workflow automation teams: Prevent execution of tasks based on outdated AI approvals by revalidating state and policies at runtime before dispatch.
  • For financial compliance teams: Ensure that transaction approvals remain valid with current policies and evidence before execution to reduce errors and fraud.

Authors

Jayesh Bhadane, Ramachandra Yerramsetti, Rajesh Gupta, Sumit Kumar

Abstract

Language-model agents increasingly participate in operational workflows where approvals, binds, and payments create commitments. An approval valid when issued may no longer authorize execution after relevant facts, evidence, policy, or authority change. We call this the evaluation--execution gap. We specify a state-bound runtime assurance layer that separates probabilistic measurement from deterministic adjudication, binds an execution allowance to the decision-relevant basis of an approval, invalidates that allowance after relevant logged changes, and rechecks admissibility at dispatch. This distinguishes the continued validity of a prior approval from a current-state policy check. We describe eight failure modes, an assurance model, a reference architecture, and prospective interventions with retrospective remediation. In a scripted 42-case replay, the state-bound configuration identifies 15 later-invalidated approvals that a deliberately non-re-evaluating point-in-time comparator does not revisit; it holds 14 affected actions before dispatch and compensates one landed effect. These results illustrate behavior under the stipulated policies and event orders, not superiority over dispatch-time enforcement designs or production effectiveness. Under explicit interception, ingestion, dependency, and serialization assumptions, the model establishes dispatch-time validity within the registered execution surface.