Decide at the point of action.
An agent’s intent becomes consequential at a tool, API or physical-system boundary. That is where authority and policy must be evaluated.
- Attributable principal
- Valid authority origin
- Current policy and trust
- Enforceable action decision
Principal · task · operation · target · parameters
An ALLOW decision permits the evaluated request. The executor and observed state are recorded separately.
Execute the evaluated action.
Stop the unauthorized effect.
Pause for an approved path.
Retain only named safer capability.
Runtime decision
Four decision states
ALLOW means the request is inside valid authority and policy. DENY means it cannot proceed. ESCALATE means a person or another approved decision path must resolve it. DEGRADE preserves a safer subset of capability while removing the higher-risk action. These states are conceptual decision outcomes, not claims about a published public API.
Action-time authorization matters because the same authenticated principal may request very different operations. Reading an inventory list is not the same as changing a production firewall rule. The decision should account for the action, object, purpose, authority chain and current context.
- ALLOW: execute inside the approved envelope
- DENY: stop an unauthorized or out-of-policy action
- ESCALATE: seek an explicit approval or review
- DEGRADE: preserve limited safe capability
Scenarios across environments
An enterprise agent may draft a contract summary but require escalation before sending an external commitment. A security agent may quarantine a workload only within an incident scope; a request outside that scope is denied. A financial agent may approve a small pre-authorized reconciliation but not transfer funds to a new counterparty. A critical-infrastructure controller may retain monitoring while control changes are degraded during an unsafe operating state.
Each scenario depends on a trustworthy execution boundary. A policy decision has little value if the tool can be called directly through another unchecked path. Integration design must identify every consequential action point and how an enforcement result affects execution.
Execution boundary
A decision needs evidence
A useful decision includes why the action was permitted or blocked, not just a Boolean result. It should refer to the acting principal, originating grant, delegation path, policy and relevant trust state. Escalation should identify who approved and what exactly was approved.
ProofGrid’s expanded runtime control model aims to connect these facts with the execution result. It does not claim to perform the detection, payment, physical movement or remediation itself.
Separate decision from execution
The decision system and execution system have different responsibilities. A runtime check decides whether a particular principal may request a particular effect under current conditions. The execution system applies domain logic, safety controls and transaction semantics. An ALLOW decision is not proof that the action completed; the downstream system may reject it, time out or return an ambiguous result.
For that reason, the integration needs correlation identifiers and an outcome path. A retry should not cause duplicate payments or repeated disruptive remediation. An approval should be bound to the exact action it covers, not treated as broad future permission for the agent.
Choose the last meaningful control point
The best enforcement point is close enough to the external effect that the action can still be stopped and specific enough to know the target. A prompt-level instruction is not an enforcement point. A gateway that sees only a generic tool name may not have the details needed to distinguish a read from a destructive write.
Organizations should map every path to the protected action, including direct API calls, alternate tools, queued jobs and human-operated consoles. The authority decision need not replace their existing controls; it must be integrated so an agent cannot bypass it by choosing another path. For highly sensitive operations, a safe failure mode may be deny or escalate when the decision service is unavailable.
A control boundary, not a tool list
Policy Enforcement Point (PEP) and Policy Decision Point (PDP) are established architecture concepts. An enforcement point intercepts a protected tool or API operation, while a decision point evaluates the request and returns an outcome. ProofGrid provides these enforcement and decision roles without implying third-party standards certification or publishing its private integration contract.
The request should carry trusted principal and user-on-behalf-of context, task, tool, operation, target, normalized parameters, purpose, authority chain, approval state, policy version, current risk signals and time. A tool allowlist only says that the agent can see or invoke a tool. The same tool may read one record or mutate production, so a consequential call needs action-specific evaluation. OAuth scopes and RBAC remain valuable access controls, but a scope or role may be broader than the delegated task.
Time of check and time of use
A task can be approved at 09:00 and executed at 16:00. Between those moments a parent grant may be revoked, a maintenance window may close, an approval may be withdrawn, risk posture may change, ownership may move or an agent identity may be compromised. Checking only at task creation leaves a time-of-check/time-of-use gap. The relevant facts should be reevaluated at the last meaningful enforceable boundary before the effect.
For delayed jobs, the worker needs a trustworthy reference to the original actor and task, then a fresh decision at execution. Approval should be tied to the exact actor, tool, operation, target and normalized parameters. A short-lived artifact should not authorize a changed request or be accepted twice for a non-repeatable effect. Idempotency and reconciliation remain executor concerns alongside authorization.
Failure behavior and evidence
For a high-consequence write, missing policy, an unverifiable authority origin, an unavailable parent chain or invalid approval should normally fail closed. Lower-risk operations may retain a named degraded mode, such as diagnostics without writes. DEGRADE must be enforceable as a smaller action set, not an advisory message that leaves the original credential usable.
An ALLOW decision is distinct from an execution receipt and an observed outcome. If the executor times out, the observed state may be UNKNOWN. The system should preserve that uncertainty, correlate later observations and prevent a retry from duplicating the effect. ProofGrid verification is designed around that complete chain rather than a success-looking authorization log alone.
Platform / Next Step