Runtime control

A decision made at task launch cannot govern a later effect if authority, policy, resource state or approval has changed. Runtime control checks immediately before execution.

Start with the distinction

From recognition to a bounded effect.

Where the permission check meets the action that can change an external system. The references below each own a different question, from the source of permission to the decision at the action boundary. Use them as a map for an architecture review, then test the model against a real task and its downstream execution path.

Start with a decision

What must still be true at commit time?

A decision made at task start can go stale. The execution boundary needs the current grant, policy, resource and approval state, plus a digest of the final request. If a required fact is unavailable, the failure behavior must be explicit.

Choose the interlockInventory direct APIs, tools and queues before placing the check.Control stale decisionsBind cache entries to versions, targets and revocation epochs.Reconcile the effectDo not turn a timeout into a success or a denial.

Architecture review: Run the same request through the wrapper, a direct client and a delayed queue. Change the target or revoke the grant between check and use. No path should commit with the earlier decision.

01 / Enforce

Enforce

Begin with the principal, purpose and operation before discussing tools.

Policy enforcement point for agentsPut the blocking check on every path to an external effect.Policy decision point for AI agentsSpecify what a decision service must know before an agent action can cross an execution boundary.Find bypass paths around an agent policy enforcement pointMap every route to a protected effect so a wrapper decision cannot be escaped through another tool or credential.Select the enforcement boundary for agent actionsChoose a point that can see the exact action and reliably stop it before external effect.ALLOW, DENY, ESCALATE and DEGRADE decision contractsSpecify what each runtime authorization outcome means to an agent and executor.Action-level authorizationDifferent operations on the same tool require different decisions.Parameter-level authorizationInspect the arguments that determine an action’s real-world consequence.Approval expiry and binding for agent actionsBind a human approval to one actor, operation, target and parameter set with a usable lifetime.

02 / Handle change

Handle change

Follow the grant and policy into the protected execution path.

Context-aware authorization for agentsReevaluate an otherwise valid grant when operating conditions change.Decision caching for agent actionsCache only when the evaluated facts and revocation model permit it.Time-of-check to time-of-use risk in agent authorizationBound the interval in which a previously allowed agent action can change meaning before the executor applies it.Fail-closed behavior for agent actionsChoose safe authorization failure behavior without turning a temporary outage into unlimited permission.Degraded authority modes for autonomous systemsSpecify which lower-risk actions may continue when a decision dependency is unavailable.Revocation propagation across agent runtimesDefine how withdrawal of a parent grant reaches caches, queues and executors before another protected effect.Authorization decision consistency across regionsMake grant and policy freshness explicit when agent actions run in multiple regions.Policy version pinning for agent decisionsBind each decision to the rules evaluated without freezing a long-running agent to obsolete policy.Latency budget for action-time authorizationAccount for policy and freshness checks without replacing them with unbounded cached permission.Emergency override authority for agentsConstrain exceptional permissions to a real incident, accountable initiator and short-lived effect.Idempotent agent actions after retriesPrevent a repeated authorized request from causing repeated real-world effects.Authority revocation for agentsWithdraw a grant and stop both direct and delegated future actions.

03 / Verify

Verify

Review failure, revocation and the evidence left after execution.

Decision receipts for agent authorizationRecord why one agent action was permitted or denied without confusing permission with execution.Execution receipts for autonomous actionsRecord what the executor accepted and attempted after an authorization decision.Observed outcome verificationCheck the resulting system state rather than trusting a tool success message.Revocation race conditions for agentsIdentify the interval when a revoked grant may still reach execution.

Connect the architecture

Identity, permission, decision, outcome.

A runtime decision has to be close enough to execution that the evaluated target, arguments and grant state still hold. The enforcement point should be on every relevant execution path, with a defined response to a missing decision service. After ALLOW, an execution receipt and independent observation can show whether the effect happened. The distinction becomes important for retries, revoked parents, changing incident ownership and long-running tasks that resume after an earlier approval.

Platform authority ↗Developer authority model ↗Compliance and audit context ↗ProofGrid Research ↗

Explore the control plane

Make one authority chain reviewable before scaling it.

Request a Conversation