A queued action should not carry permanent authority merely because it was valid when it entered a queue. Authority can change while work is waiting: scope can be revoked, a credential can expire, policy can tighten, or the action itself can become stale.

The safe question is not only “Was this action allowed when it was proposed?” It is “Does this exact action still have valid authority when the executor is about to create the side effect?”

The core rule: queued work needs a fresh authority check

Authorization freshness: the requirement that authority is still valid at the moment an executor relies on it.

Execution boundary: the point where a proposed action becomes a real side effect, such as changing infrastructure, sending money, modifying records, or invoking a privileged external operation.

Revocation: a change that removes or narrows authority that previously existed.

Replay resistance: protection against reusing an authorization for the same action again, or for an adjacent action that was never authorized.

Demonstrated: a statement backed by current implementation or bounded test evidence represented in this draft's fact packet. It does not mean every possible execution path is controlled.

Queue time and execution time are different

Stage What may be true What must not be assumed
Proposal The agent has authority to propose an action That proposal authority lasts forever
Queue admission Policy allows the exact action at that moment That later execution is automatically authorized
Waiting period Nothing has executed yet That revocation or expiry cannot occur
Executor handoff The action is ready to become a side effect That an old ALLOW is sufficient by itself
Execution Current authority is verified for the bound action That stale, replayed, revoked, or mismatched authority may proceed

Worked example: authority is revoked while the action is queued

Consider an agent temporarily allowed to rotate a production credential.

  1. T0 — proposal: the agent proposes rotate_credential(service-A).
  2. T0 — authorization: the exact action is evaluated and ALLOW is recorded while scope is valid.
  3. T0 — queue: the operation enters a worker queue instead of executing immediately.
  4. T1 — revocation: before the worker reaches the job, the agent's production-write scope is revoked.
  5. T2 — executor handoff: the queued operation reaches the executor.
  6. T2 — fresh verification: the executor checks action binding, authorization freshness, revocation state, replay state, and current authority for this exact side effect.
  7. T2 — outcome: because the required authority is no longer current, the executor denies the operation and records the denial.

The security property is not that the queue remembers an earlier ALLOW. It is that the executor refuses to treat stale authority as current authority.

What the executor should verify

  1. Is the authorization bound to the exact action and arguments now being executed?
  2. Is it still within its permitted lifetime?
  3. Has the relevant authority, scope, principal, or capability been revoked?
  4. Has the authorization already been consumed or replayed?
  5. Has the queued payload changed since authorization was issued?
  6. Is the executor an integrated verification point for this side effect?
  7. If a required check cannot be completed, does the path fail closed?
  8. What durable evidence connects proposal, authorization, revocation, verification, and outcome?

For this draft, the relevant control layers are Action Binding, Audit, Evidence, Execution Boundary, Freshness, Replay, Revocation.

Action binding and replay resistance

Revocation checking alone is not enough if an authorization can be detached from the action it was created for. A robust authorization is tied to the governed action so a material argument change produces a different action identity.

Replay resistance addresses a separate problem: even a correctly bound authorization should not be reusable beyond the conditions under which it was granted.

Fail-closed behavior at the execution boundary

A queue worker may encounter unavailable revocation state, an expired permit, a digest mismatch, or a replay conflict. For a governed side effect, uncertainty should not silently become permission. Where required verification cannot be established, the integrated path should deny or hold the action.

That statement is bounded to paths that actually perform executor-side verification. A decision record alone does not prove an alternate or unintegrated execution path was prevented.

Evidence should connect the whole chain

Useful governance evidence connects the original proposal, exact action identity, authorization state, later revocation or expiry, executor verification, and whether the side effect occurred or was denied.

An audit record can provide governance evidence, but a record is not, by itself, proof that a downstream executor enforced the decision.

Independent technical context

  • IBM: IBM describes watsonx.governance as providing AI governance capabilities including policy enforcement, monitoring, traceability, and governance evidence.
  • Fiddler AI: Fiddler describes its AI Control Plane as combining agent observability, inline policy enforcement, and auditable governance.
  • PortEden: PortEden describes AI-agent governance around agent identity, scoped or least-privilege access, and audit trails.

These sources provide independent technical context. They are not endorsements of Sentinel, do not imply partnership, and do not establish identical technical guarantees.

How this maps to Sentinel's bounded model

In a Sentinel-governed and explicitly integrated path, authority can be represented with action-bound, short-lived authorization and checked where the executor is about to perform the governed side effect.

An ALLOW record by itself is not represented as proof of downstream enforcement, and evidence artifacts are not treated as authority for a new side effect.

Sentinel demonstrated evidence

The following statements are included only because the bound fact packet marks them DEMONSTRATED:

  • Sentinel uses fail-closed behavior on governed execution paths.
  • Sentinel binds authorization evidence to a canonical action digest.
  • Sentinel uses Ed25519-signed authorization evidence on governed execution paths.
  • Sentinel checks permit freshness using bounded validity windows.
  • Sentinel rejects replay of previously consumed governed actions.
  • Sentinel checks current authorization state immediately before bounded side effects.
  • On bounded integrations, the executor locally verifies authorization evidence immediately before the side effect.
  • Sentinel maintains tamper-evident append-only audit evidence.
  • Sentinel does not treat read-only replay or evidence artifacts as execution authority.

These statements remain bounded to the implementations and tested paths represented by their evidence. They do not establish universal enforcement across execution paths that have not been explicitly integrated and tested.

Practical next step

For every queue, retry worker, scheduler, adapter, or delayed job that can create a consequential side effect, document both when authority is granted and where current authority is revalidated.

Then test the uncomfortable case deliberately: authorize an action, queue it, revoke the relevant authority, and allow it to reach the executor. The expected result for a properly governed path is a denial or hold before the side effect, together with evidence explaining why.

Research basis

Source provenance, retrieval timestamps, evidence digests, and claim bindings remain in the factual research packet rather than being dumped into reader-facing prose.

Boundary statement

Execution claims apply only to Sentinel-governed and tested paths.

An ALLOW or DENY response alone does not establish downstream enforcement.

Direct or alternate execution paths that bypass the governed boundary are not represented as controlled by Sentinel.