Your Agent Passed Assurance at 9:00. It's 9:05.

The agent has passed its assessment. Finance has separately approved a $9,800 refund.

By execution time, the request is for $12,400. Or the destination has changed. Or the approval has been revoked.

The credentials still work. The tool remains available.

Does your stack re-check the actual request against current authority, or treat the earlier approval as standing permission?

The assessment answers what the agent demonstrated under specified conditions. Finance’s approval applies to a particular business request. Neither establishes that a changed request may proceed, and neither proves what ultimately happened.

In this scenario, it isn’t the five minutes that matter; it’s that the operation awaiting execution no longer matches the approval that supported it.

Agents can move from a plan to a consequential action faster than a person can review an alert. Controls need to operate at that boundary, using the authority and context that apply then.

Detection finds it. What prevents the next one?

In his selected collection of 26 disclosed AI agent incidents, 17 with known timelines, Rajat Taneja reports a 57-day median detection time. These findings describe his collection, not an enterprise-wide detection benchmark. Read Taneja’s analysis.

His analysis also calls for controls outside the model. The practical question is where those controls intervene: what can prevent the next prohibited action while investigation continues?

A team also needs a control capable of withholding the refund before the business system commits it. Finding the problem later and preventing its next occurrence are different responsibilities.

Zero trust at the action boundary

The principles already exist. NIST SP 800-207 describes authentication and authorization as distinct functions, contextual access decisions, ongoing reevaluation and separate policy decision and enforcement functions. Zero trust was never just a credential check. NIST SP 800-207, sections 2–3.

Applying those principles to agents means asking a concrete question: where are they enforced when the agent changes a business system?

Authentication verifies the caller’s identity. Authorization determines whether that caller, acting under the relevant delegation, may perform this operation. For the refund, that includes the amount, destination, approval scope and applicable policy. An agent’s explanation of its intent can inform a decision; it cannot grant authority.

Least privilege limits available operations and resources. Scoped delegation prevents a broad user entitlement from becoming unlimited agent authority. Separation of duties keeps an agent from approving its own exception. Defense in depth combines these controls with secure software, model safeguards, network restrictions and independent observation.

You can spend millions on security and still leave this particular request unchecked. A deployment can authenticate the service, scan its code and log its calls while failing to compare the executed refund with Finance’s approval. The useful question about that investment is whether the controls connect to the business consequence.

For delayed work, a check at planning time may be too early. Authorization needs to remain applicable when the operation commits, with changes and revocations handled by the execution path. A fresh decision also needs to remain bound to the request that actually executes.

The assurance program that connects the controls

Shift left matters: find and fix weaknesses before deployment. Runtime conditions also change. A new tool, a modified workflow, a revoked delegation or a different data source can alter the assumptions behind a successful assessment.

AppSec, evaluations and red teaming each contribute evidence. Their value grows when an assurance program connects that evidence to accountable decisions and operational controls:

• AppSec and DevSecOps harden the implementation, dependencies, secrets and delivery process.
• Evaluations measure specified behavior against versioned criteria and representative tasks.
• Red teaming explores adversarial paths, misuse and ways an agent might cross a boundary while pursuing a legitimate objective.
• Runtime authorization and enforcement apply approved restrictions to the consequential actions the integration controls.
• Monitoring, response and outcome verification establish what occurred, identify gaps and test containment and recovery.

These activities can run throughout the lifecycle. NIST’s AI RMF Playbook likewise describes ongoing risk assessment and post-deployment monitoring. NIST AI RMF Playbook, Manage.

The operational test is simple: when a red team finds a bypass on Tuesday, how does the finding change the controls applied on Wednesday, and who tests and authorizes that change?

Suppose the test finds that an approval can be reused after the refund amount changes. Record the failing case, investigate the cause and test a scoped correction. Replay both the prohibited request and legitimate refunds. Have the responsible owner approve the tested change, verify its rollout and confirm the resulting behavior. Preserve the original failure as evidence.

A report closes none of those steps by itself. Nor does a broad deny rule prove that the business can operate safely.

Continuous assurance needs several cadences. Apply policy before each governed consequential action. Trigger deeper reassessment when relevant assumptions or dependencies change. Schedule adversarial exercises and recovery tests. Route consequential exceptions to authorized people while the affected action remains held.

Running a full red-team campaign before every tool call would be impractical. Equally, a finite test suite cannot establish safety for every future condition. The program must define its coverage, acceptance criteria, owners and reassessment triggers.

Central policy ownership and distributed enforcement

A central policy controller gives teams a common place to manage rules, versions, scope and accountability. Distributed enforcement puts those decisions close to the tools and systems that create effects: an API gateway, tool proxy or control inside the business application.

Central ownership does not require one physical server or a remote round trip for every operation. Decision services can be replicated, and supported designs can evaluate approved policy locally. What matters is knowing which policy applies and whether the enforcement point can still rely on its context.

That requires authenticated policy distribution, version acknowledgements, trusted caller context and explicit handling of expiry and revocation. A signature establishes origin and integrity; it does not establish that a policy is still current. Require each enforcement point to acknowledge the active version and refresh its policy state within an approved freshness window; revocation or an expired window must stop high-consequence actions.

Outage behavior belongs in the policy design. A high-consequence refund may have to stop when current authority cannot be established. Lower-risk operations may continue under an explicitly approved, bounded offline policy. Teams must define those limits and test what happens when connectivity returns.

The enforcement inventory matters just as much. If the agent can reach the same system through an ungoverned credential or alternate API, a successful deny at one gateway does not establish containment. Restrict bypass routes and test the paths that remain.

At machine speed, latency includes context retrieval, decision, enforcement and the business operation. Stop effectiveness includes propagation and work already in flight. Measure those paths directly; a fast policy-engine benchmark alone cannot establish them.

Verify the effect and the recovery

A deny record proves a decision was recorded. Evidence from the execution path and target is needed to establish the effect. Similarly, a human approval does not prove dispatch, and dispatch does not prove successful completion.

For the refund workflow, a useful acceptance test establishes that:

• The changed request cannot reuse the earlier approval.
• The prohibited effect remains blocked on each tested route, including delayed or retried operations.
• A valid request succeeds after fresh authorization through the supported workflow.
• Removing a temporary restriction preserves changes that remain authorized and leaves the required protections working.

Tie the evidence to the tested agent configuration, request, policy version, approval, enforcement point and observation window. Use target confirmation where available. Missing confirmation stays unverified until reconciled; silence in a dashboard is insufficient.

This also changes how teams judge recovery. A system that blocks every refund has contained activity, but has not demonstrated useful recovery. Test the legitimate business outcome alongside the prohibited one.

GovernorAI’s role and its boundaries

At GovernorAI, we are connecting continuous assurance, governance, enforcement and evidence around the work an agent performs.

For a governed action, GovernorAI allows it, denies it, or holds it for an authorized person, recording the policy version and the evidence of what happened next. The assurance workflow connects assessment evidence and authorized review decisions to the control and outcome records. Versioned subjects, test packs and acceptance criteria show what was tested. Explore GovernorAI Assurance.

The enforcement point determines the intervention: an inline gateway stops the request before dispatch, while a control inside the business application can stop the write before commit. An event feed arriving afterward supports detection and response. Review GovernorAI’s enforcement coverage.

Unrouted calls, unsupported operations and unobserved downstream effects remain outside the demonstrated boundary. Approval and release are separate: an approved response does not automatically resume a held call.

For governance to adapt responsibly, a finding must lead to a tested, authorized change. An agent cannot enlarge its own authority because it encountered a restriction. GovernorAI supports continuous control monitoring and compliance evidence; it does not certify compliance.

The test is whether your organization can explain why the next action is permitted, show where that decision is enforced and verify what happened afterward.

Your agents act at machine speed. Does your governance?