| Internet-Draft | Agent CLOCKOUT | October 2026 |
| Watts | Expires 15 April 2027 | [Page] |
Agentic systems can continue proposing work after authorization changes, while delegated credentials, queued jobs, and operations already in flight may continue producing effects. This document specifies a proposed operational profile that separates agent proposals from authoritative authorization, effect admission, computation termination, and bounded closure. It defines enforcement assumptions, revocation barriers, descendant handling, status evidence, and fault tests. The profile complements existing authorization and revocation mechanisms. It does not define a new token format, establish closure outside declared coverage, reverse committed effects, or infer an agent's mental state.¶
This note is to be removed before publishing as an RFC.¶
This is an individual contribution intended for discussion. It has not been adopted by an IETF working group. Requirements describe a proposed conformance profile and do not claim an approved Internet Standard or empirical validation. Discussion may be sent to the author at deonte@goodshyt.fun.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 15 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [I-D.watts-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. [RFC7009] 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.¶
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 [RFC2119] [RFC8174] 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.¶
| 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. |
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.¶
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.¶
<CODE BEGINS>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
<CODE ENDS>¶
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.¶
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.¶
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.¶
| 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 [I-D.watts-closure]. 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.¶
<CODE BEGINS> file "clockout-status-example.json"
{
"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"
]
}
<CODE ENDS>¶
A deployment MUST define a controller order for request acceptance, fence installation, admission, commitment, shutdown, and closure. Wall-clock timestamps SHOULD use [RFC3339], 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 [RFC7009]; token exchange can create dependencies that need separate treatment [RFC8693]. OAuth deployments SHOULD apply current security guidance [RFC9700]. This document does not add OAuth claims or change those specifications.¶
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.¶
| 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.¶
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.¶
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.¶
This document has no IANA actions. It does not register a media type, OAuth parameter, token claim, endpoint, or cryptographic algorithm. Names in illustrative JSON objects are local application fields, not globally registered protocol elements.¶
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.¶
Further work is needed on interoperable status encodings, authenticated mediator inventories, cross-domain cancellation, crash recovery, independent witness placement, and testable upper bounds under partitions. This profile does not resolve these questions by declaring an optimizer to be obedient.¶