Who Stops an AI Agent When Conditions Change?

A human reviewer approves a financial adjustment. Before the agent executes it, the customer's account is placed on hold. The agent still has the earlier approval and attempts the transaction.

This is a hypothetical production scenario. It raises an immediate human question: Who can stop the action when the facts that justified approval have changed?

The reviewer did not necessarily make a bad decision at the time. The model may be following its plan. The business state is simply no longer the same.

For the customer, that distinction may determine whether an unauthorized adjustment is made. For the person accountable for the transaction, it determines whether an approval was meaningful at execution time.

An AI agent that passed evaluation still needs independent controls over what it is allowed to do now.

Evaluation and production answer different questions

Pre-production evaluation establishes how a system behaves under chosen test conditions. It can evaluate functional correctness, policy compliance, tool use, resilience and responses to known failure scenarios.

These tests are essential. They cannot guarantee that future production states will match the test environment.

Permissions are revoked, business records change, policies are updated and dependent services fail. A tool's behavior can shift between an agent's planning and execution steps. Long-running workflows are especially exposed to these changes.

Evaluation asks: Can the agent behave acceptably under evaluated conditions?

Runtime assurance asks: May the agent continue this specific action under the conditions that exist right now?

Those questions must be connected, not confused.

The evaluation–execution gap in recent research

EAINE Publications · Original EAINE editorial illustration. Proposed pattern, not an approved or certified framework control.

Figure 1. Approval at evaluation time does not guarantee current permission. When relevant state changes, prior authorization must be revalidated before an action is dispatched.

The October 20, 2026 paper Runtime Control for AI Agents: Closing the Evaluation–Execution Gap in Operational Workflows describes a state-bound control layer that invalidates prior execution allowances when relevant facts, evidence, authority or policy change 1.

The research distinguishes approval validity from present authorization. Its scripted 42-case replay demonstrates the behavior of the specified mechanism under stipulated event sequences. The authors explicitly do not claim general production effectiveness or superiority over every alternative enforcement design.

That distinction is fundamental. The study motivates an engineering pattern for investigation; it does not independently certify enterprise runtime assurance.

A dependable production system may need to establish three different facts:

1. An action was previously approved.
2. The approval still applies to the current state.
3. The specific operation is authorized at the point of execution.

A historical approval record alone does not prove the last two.

Who is accountable when an approval becomes stale?

A human reviewer can authorize an action based on the evidence visible at the time. That approval should have a defined scope and validity. It should not silently become a permanent permission to act after relevant conditions change.

The product owner defines the intended business result. The policy owner defines the conditions that permit it. The platform enforces those conditions when a tool is called. The operator needs enough evidence to explain why an action proceeded or stopped.

These responsibilities cannot be transferred to the model simply because its evaluation score was high. A dependable workflow makes the change in state visible and enforces a fresh decision where needed.

Why observability is not enough

Most enterprise systems already collect logs, metrics, traces and incident alerts. Agentic workflows also produce model interactions, tool calls, intermediate decisions, orchestration state and delegation steps.

These signals help reconstruct what happened. They do not necessarily prevent an unsafe action.

An observability dashboard may reveal that a payment tool was called with an invalid authorization. But if the call has already committed the transaction, monitoring alone cannot undo the consequence.

Observability produces execution evidence. Runtime assurance also enforces whether execution should continue.

Consequential actions need control points capable of allowing, pausing, rejecting or escalating work based on current, independently verified conditions.

Five operating traces as a lens

EAINE's five connected operating traces offer a useful engineering lens for reviewing runtime assurance:

• Intent: What authorized business objective is the agent pursuing? Is the objective still applicable?
• Authority: Is the initiating identity, delegated permission and approval still valid for this exact tool action?
• Behaviour: What execution path has the agent actually followed, including retries and delegated calls?
• Evidence: What current source data, decision records and verification outcomes justify continuation?
• Learning: Which observed failures, interventions and exceptions should become reviewed regression tests?

The traces help connect engineering responsibility across lifecycle and runtime behavior. They do not replace an independent authorization decision or establish that a particular implementation is approved.

A candidate runtime assurance architecture

EAINE Publications · Original EAINE editorial illustration. Proposed pattern, not an approved or certified framework control.

Figure 2. Candidate runtime assurance flow. The decision to allow, escalate or block a tool action belongs to independent controls, not to the agent's own explanation.

EAINE proposes evaluating a Continuous Runtime Assurance Pattern as an implementation candidate within existing engineering and governance boundaries.

A conceptual flow is:

Authorized Intent → Agent Plan → Current-State Validation → Independent Policy Decision → Bounded Tool Execution → Outcome Verification → Correlated Evidence → Engineering Feedback

For consequential workflows, validation must occur again when state relevant to the action changes or before dispatch across an execution boundary.

The controller might examine:

• Initiating user and workload identity.
• Current delegated authority and policy version.
• Transaction or task scope.
• Applicability of supporting context and memory.
• Business state changes since approval.
• Tool permissions, side effects and transaction limits.
• Workflow budget and retry conditions.
• Required human review and approval binding.

The model can propose an action; the execution boundary decides whether the action may proceed. The model should not be able to waive mandatory checks simply by producing a persuasive explanation.

Risk-based assurance without skipping mandatory controls

Every action does not require the same verification expense. Risk and reversibility should determine additional assurance depth.

These are implementation examples, not formal EAINE maturity or risk tiers.

Risk-based sampling of discretionary checks must not bypass mandatory identity, authorization, privacy or safety controls. A high benchmark score does not authorize a high-consequence action.

Five runtime failure scenarios to test

1. Approval invalidated after review

An action was approved but its relevant business state changed before dispatch.

Expected control: invalidate or revalidate the approval before executing the operation.

2. Revoked permissions

The agent or initiating user loses access during a long-running workflow.

Expected control: ensure future protected tool calls respect the revocation, including after retries or restarts.

3. Excessive or duplicated execution

The agent repeatedly invokes a tool or retries after a partial response.

Expected control: enforce budgets, idempotency and safe recovery to prevent duplicate side effects.

4. Stale evidence

A retrieved document or persistent memory no longer applies.

Expected control: invalidate the affected decision and refresh authorized context before consequential continuation.

5. Missing or mismatched human approval

A protected operation is attempted without an approval tied to the actual transaction, authority and current scope.

Expected control: block execution until a valid approval is recorded.

Tests should include adverse event ordering, partial tool failures and attempts to bypass policy via prompt injection or tool output manipulation.

A practical runtime assurance checklist

Passing a checklist is not itself proof of safety. Deployment-specific adversarial testing, access validation, operational rehearsal and incident response are still needed.

How to measure assurance effectiveness

Candidate metrics include:

• Attempts blocked by a defined policy boundary.
• Stale authorization detected before execution.
• Coverage of mandatory checks for consequential operations.
• False intervention and missed-detection rates against labeled scenarios.
• Time to detect and contain invalid execution.
• Proportion of material action traces with sufficient evidence.
• Harmful effects that remain uncompensated after intervention.

The measurements should be read together. A controller that blocks every action cannot serve its business purpose; a controller that never blocks an action may be ineffective.

Detection without containment, and containment without reliable evidence, each leave major assurance gaps.

Verification budgets and the limits of adjacent research

Two additional October 2026 papers illustrate useful research questions.

FOCUS: Active Critic Learning for Long-Horizon Language Model Agents studies selective sampling to improve value estimation during agent reinforcement learning 2.

Audit Where Hacks Pay studies budgeted strong-verifier audits against reward hacking in a reinforcement learning setting 3.

These papers address learning and training-time verification, not a production runtime assurance system. Their results can motivate investigation into selective non-mandatory verification, but they must not be treated as proof that an enterprise enforcement architecture works.

Connect production evidence back to engineering

Evaluation and runtime assurance should exchange evidence across the engineering lifecycle.

A production intervention should identify the actual failed assumption or boundary, produce a reproducible test scenario where possible, trigger a reviewed correction, and inform the next evaluation and release decision.

This connection gives practical meaning to EAINE's intent, authority, behaviour, evidence and learning traces.

The proposed runtime assurance pattern is an editorial candidate for evaluation, not an added canonical SDLC stage, architecture plane or control family.

The leadership decision

The useful question for an engineering leadership review is no longer only “Did the agent pass its tests?” It is also: Who can stop it, on what evidence, and how quickly does a change in authority become enforceable?

The person who approved a transaction should not have to rely on the agent remembering that an approval expired. The operations team should not learn about an invalid execution only from an incident report. And customers should not bear the consequences of a control that existed on paper but was absent at the tool boundary.

A dependable enterprise AI system can recognize when continued execution is no longer justified, stop within independently enforced boundaries and leave evidence explaining why.

That is the difference between an evaluated agent and an accountable production capability.

EAINE research note: This proposed Continuous Runtime Assurance Pattern requires implementation-specific threat modeling, policy review, deterministic control tests and production validation. It is not an approved addition to the EAINE Framework.