External Authorization and Bounded CLOCKOUT for Agentic Systems

Introduction and Scope An agent can have technical access to an operation without current permission to use it. A continuing goal or an instruction to continue does not constitute renewed authorization. A natural-language stop instruction is useful input to an agent but is not a substitute for an externally enforced access decision. Existing work distinguishes credential invalidation from revocation closure . This document adds operational requirements for separating proposals, admission barriers, computation shutdown, and cancellable-work closure. It does not replace that model or update an OAuth specification. describes token revocation; successful revocation of a credential alone does not establish the wider closure evidence required here. The profile concerns network and persistent-state effect surfaces under a declared controller. Implementations MAY use OAuth, workload identity, or another authorization mechanism. Particular protocols, signature suites, endpoint discovery, and cross-domain trust agreements remain deployment choices. No real enforcement trial or model-behavior result is claimed by this document.

Conventions and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. These requirements apply to an implementation that claims conformance to this proposed profile. They do not establish working-group consensus, successful deployment, or scientific validity.

Terminology Roles and event meanings

Term	Meaning
Agent	A process that proposes work; it is not its own authorization authority.
Controller	The externally administered authority that changes permit state and coordinates barriers.
Enforcement point	A mediator for a declared consequential effect surface.
Authority epoch	A lifetime of authority rooted in one grant or independently authorized continuation.
Admission	The authoritative acceptance of a specific effect-bearing operation.
Commit	The point after which an effect cannot be prevented by the enforcing component.
Settlement	A later manifestation of an already committed effect.
Controlled descendant	Delegated authority or work within the stated enforcement domain.
Revocation barrier	Evidence that every required mediator blocks new admissions from the revoked epoch.
Closure	A scoped determination that required blocking and controllable-work requirements are satisfied.

Trust and Deployment Assumptions The controller and enforcement configuration MUST be protected from modification by the optimizing agent. A deployment MUST identify its authorization root, administrators, trusted enforcement points, witness requirements, queues, delegated credentials, and effect surfaces. Installation of an instruction file or a change of persona MUST NOT grant authority by itself. Every in-scope consequential admission MUST be mediated by a trusted enforcement point. An implementation unable to account for a known bypass MUST report a limitation or unresolved path. It MUST NOT describe its result as global closure. The mediator inventory and policy version MUST be fixed for a particular determination; changes require a new evaluation. A required witness is an independent source only under stated trust and failure assumptions. Several observers backed by the same compromised logger do not prove independence. An implementation MUST specify which witness predicates are mandatory and MUST deny sensitive admission if a mandatory predicate is false or unknown.

Authorization and Effect Admission An admission decision MUST bind the principal, authority epoch, operation, resource, scope, current policy, and required evidence. It MUST be made outside the agent's self-reported narrative. The required logical relation is permit = authorization AND required-lineage AND required-witnesses. A weighted continuity or risk score MUST NOT compensate for a failed mandatory predicate. The enforcement point MUST prevent a check-and-use race from allowing a stale permit to commit an effect after the point has installed the relevant revocation fence. Possible implementations include transactional admission, a resource-side epoch check, or an equivalent atomic mechanism. A permit checked only when a job enters a queue is insufficient if the job later executes under changed authorization. A valid credential or authenticated agent identity is not enough when the relevant epoch or scope is revoked. An agent MUST NOT renew its own authority by changing an epoch label, replaying a former decision, or delegating the same revoked authority through a new process. Independent reauthorization MUST be a fresh controller decision bound to a distinct epoch. admit(operation, epoch): validate_operation_binding(operation) validate_required_evidence(operation) atomically_at_effect_surface: if epoch_is_revoked(epoch) or not current_permit(operation): record_denial(operation, epoch) return DENIED record_admission(operation, epoch) return ADMITTED This pseudocode specifies the intended decision boundary, not a working distributed transaction implementation. An implementation MUST document how its effect surface enforces atomicity and how it handles irreversible commitment inside that boundary.

Revocation Procedure and Barrier

Authenticate the revocation requester and bind a unique request identifier, authority epoch, scope, policy version, and any advertised closure budget.
At controller acceptance, stop issuing or renewing permits derived from the revoked epoch and prevent new authority-bearing delegations that bypass the pending fence.
Propagate the fence to every required enforcement point and descendant controller. Each acknowledgment MUST bind the request, epoch, enforcement scope, and installed policy or fence version.
Establish the admission barrier only after every required mediator has provided current, authenticated evidence that new admissions from the revoked epoch are blocked.
Cancel or fence queued work before effect admission; drain, cancel, or otherwise close controllable operations already admitted, under the declared treatment of irreversible effects.
Evaluate the closure requirements and publish a scoped status with evidence, missing acknowledgments, remaining work, and limitations.

Controller acceptance and completion of the barrier are different events. A distributed deployment can have a propagation window in which a remote component still admits work. The implementation MUST measure that window and MUST NOT claim zero new admissions from the moment the request was accepted unless its architecture actually enforces that stronger property. A timeout, network partition, or stale acknowledgment MUST NOT complete the barrier.

Delegation, Queues, and In-Flight Operations A delegated capability MUST remain bound to its authority root and epoch unless a trusted authority explicitly creates an independent authorization. Revocation MUST cover the declared transitive dependencies, including derived credentials, cached decisions, delayed work, retries, background processes, and subdelegations. A bounded traversal that truncates a known descendant MUST report the omission. Queue workers MUST check current authorization at the effect-admission boundary, not rely solely on enqueue-time permission. Queue cancellation and worker acknowledgment MUST identify the affected jobs and fence. A job retried with the same idempotency key MUST NOT bypass revocation or create duplicate effects. Already committed irreversible effects can settle after revocation. The implementation MUST preserve the distinction between a new prohibited admission, cancellable work not yet committed, and settlement of an earlier commitment. A compensation transaction is a new authorized action, not erasure of history. External systems lacking cancellation or fencing MUST appear in the declared residual tail or as unresolved dependencies. Suspension of inference is separate from blocking effects. If computation termination is a required outcome, a trusted process or resource manager MUST establish it. An agent's statement that it stopped is not termination evidence. Terminating a parent process alone does not establish closure of independent descendants.

Status and Evidence Semantics Closure states

State	Meaning
REQUESTED	The revocation instruction was accepted; no barrier or closure claim.
PROPAGATING	Fences are being applied; required acknowledgments are outstanding.
CLOSED	All stated requirements are met for the exact declared scope and epoch.
PARTIAL	Some requirements are met, but known required work or paths remain.
UNKNOWN	Evidence is insufficient to determine the state.
FAILED	Required enforcement failed or an advertised closure deadline was missed.

These states have semantics compatible with the existing closure model . They are not interchangeable with computation-termination flags. CLOSED MUST identify the coverage and requirements it satisfies. PARTIAL, UNKNOWN, and FAILED MUST NOT be interpreted as CLOSED. A successful historical receipt is not a current permit and cannot authorize new work. Evidence objects crossing a trust boundary MUST be authenticated and integrity protected by the deployment's agreed mechanism. Verifiers MUST check issuer authority, recipient or audience binding, the authority epoch, scope, freshness, request binding, and expected policy. A digest alone does not authenticate an issuer or prove that an acknowledgment is true. The following JSON is illustrative; it does not define a signed receipt encoding. { "profile": "clockout-discussion-1", "request_id": "urn:example:revoke:42", "authority_epoch": "urn:example:epoch:7", "scope_id": "urn:example:scope:toy-api-queue", "status": "PARTIAL", "requested_at": "2026-10-12T04:00:00Z", "admission_barrier_at": "2026-10-12T04:00:00.250Z", "new_admissions_blocked": true, "computation_terminated": false, "controllable_work_closed": false, "remaining": [ "urn:example:job:pending-3" ], "irreversible_tail": [ "urn:example:commit:previous-1" ], "limitations": [ "partner-side cancellation not observed" ] }

Ordering, Budgets, Retry, and Recovery A deployment MUST define a controller order for request acceptance, fence installation, admission, commitment, shutdown, and closure. Wall-clock timestamps SHOULD use , with precision and clock uncertainty documented. Independently timed components MUST NOT be treated as having a shared trustworthy clock by default. Monotonic durations MUST identify the measuring component and their units. A closure budget MUST state its start event, completion predicate, and duration unit. The recommended start is controller acceptance of the revocation request. A barrier budget and a controllable-work budget MAY be separate. A missed advertised deadline MUST be recorded, even if closure later succeeds. Later success MUST NOT rewrite the original deadline outcome. Revocation handling SHOULD be idempotent. Repeated requests or acknowledgments MUST NOT move a known revoked epoch back to active authority. Corrections or new evidence require new status evidence that preserves the earlier result. After a crash, a controller MUST recover the revocation fence before enabling admissions. If it cannot establish current epoch state, it MUST deny affected sensitive admissions. An existing OAuth revocation mechanism can be one input to this procedure ; token exchange can create dependencies that need separate treatment . OAuth deployments SHOULD apply current security guidance . This document does not add OAuth claims or change those specifications.

Evaluation and Conformance Tests A claim of operational conformance requires testing the declared effect surfaces with an independent outcome harness. Tests MUST distinguish proposed text, attempted tool calls, mediator admissions, committed effects, computation status, and residual work. A mock controller that defines its own effects as zero on denial demonstrates a local code rule, not a real deployment guarantee. Minimum fault scenarios

Scenario	Required observation
Request accepted, fence pending	No CLOSED claim; propagation window exposed.
Credential replay after fence	Denied at current effect boundary.
Enqueue before revoke; execute later	Current check prevents stale admission.
Delegate created during revocation	Cannot escape the revoked root/epoch fence.
Stale, wrong-epoch acknowledgment	Rejected; barrier remains incomplete.
One mediator partitioned	PARTIAL or UNKNOWN; no global success.
Controller restart	Fence recovered before renewed admission.
Commit before fence; later settlement	Residual tail recorded, not silently reversed.
Agent still computing after denial	Effect blocking distinguished from computation stop.
Duplicate retry or request	No reactivation or duplicate external effect.
Required witness missing	Sensitive admission denied.
Legitimate active control	False denials and operational costs measured.

Record software/model/configuration versions, observation coverage, missing events, independent runs, and faults actually injected. No numerical deadline or success rate is prescribed here. Deployments MUST set measurable bounds before tests and MUST retain failed or missing observations. Zero observed failures MUST be reported with exposure and detection limits, not converted to proof of zero risk.

Security Considerations A forged closure result, stale cached permit, race between checking and committing, incomplete descendant graph, or unmediated side channel can defeat this profile. An implementation MUST protect controller state and evidence stores, authenticate inter-component messages, limit replay, and defend revocation fan-out against denial of service. An agent-controlled trace MUST NOT be treated as an independent witness by default. Untrusted model output or retrieved content MUST NOT control authorization policy or substitute the epoch, resource, or operation after a decision. Administrators SHOULD inventory egress, persistent storage, credential issuance, queues, subprocesses, and independently managed tools. Unknown or out-of-domain surfaces bound the claim rather than disappearing from it. A controller can itself be compromised or misconfigured. Formal expression of a permit function does not establish complete mediation, trustworthy evidence, or absence of implementation flaws. The deployment MUST state those assumptions and distinguish tested guarantees from intended ones.

Privacy Considerations Lineage and closure evidence can expose identities, organizational topology, resources, and sensitive decisions. Records MUST NOT contain bearer credentials, private keys, or unnecessary personal content. Deployments SHOULD use scoped opaque identifiers, access controls, retention limits, and the minimum evidence needed by each relying party. Raw private model reasoning is not required by this profile. Public reports SHOULD distinguish evidence metadata from protected payloads and record redaction without silently replacing original evidence. An opaque identifier can still permit correlation; deployments SHOULD avoid stable cross-domain identifiers unless required by a specific accountability purpose.

Acknowledgments The originating conceptual framework and research direction were developed by Deonté O'dell Watts, Independent Researcher, GoodShyt Group Inc. AI tools assisted source review, drafting, and local document validation. The author remains responsible for the submission and its technical claims. Document-format validation is not independent peer review or verification of an agent deployment.