Boundary Jurisdiction Architecture for Agentic and Delegated Systems

Introduction Agentic and delegated systems can create, cache, exchange, and exercise authority through multiple services. Revocation of one credential can leave consequential paths through derived credentials, queues, cached decisions, or delegated descendants. The governing principle is that possession of a capability does not imply jurisdiction over the boundary conditions that enable its consequential use. Capability, evidence, authorization, enforcement, and execution are distinct states.

Conventions and Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. Untrusted closure C is the set of principals whose consequential authority derives from an untrusted or adaptively controlled root. Consequential resource Q is a resource or state transition with an external effect. Commitment boundary B_Q is the first state after which an action cannot reliably be revoked by the registered control plane. Revocation cut K is a declared set of independently controlled capability edges disconnecting registered paths from C to commitment boundaries. Closure is a bounded prospective claim relative to a documented inventory.

Capability Graph Model A deployment is modeled as a time-indexed directed graph G_t=(V_t,E_t) with nodes for principals, services, credentials, queues, commitment boundaries, and resources, and edges for enabled capabilities. Each edge SHOULD bind source, destination, operation, scope, issuer, subject, start, expiry, parent grant, revocation identifier, risk class, and provenance. Implementations MUST distinguish structural paths from paths enabled at evaluation time.

Revocation-Dominating Cut A registered cut K is structurally valid only if every registered path from an authority-derived untrusted principal to every registered commitment boundary intersects K. A validator SHOULD compute the descendant closure, remove K, and check that no boundary remains reachable. A closure claim is invalid if the sink set, cut set, or path inventory is absent. Empty inventory MUST NOT be interpreted as proof of complete coverage.

Revocation Closure Semantics Let t_r denote the request time and T_prop the declared upper bound on propagation. A system MUST NOT report prospective closure before enforcement becomes effective at t_r+T_prop, absent independently justified earlier effective time. Prospective closure requires independently controlled cut enforcement, descendant revocation, deferred-effect inventory, fail-closed enforcement, no known bypass outside the registered graph, and measured propagation. Closure is model-relative and does not prove absence of all physical channels.

Authority Diode Evidence MAY flow from untrusted computation to an authorization service. Untrusted computation MUST NOT have arbitrary write access to authorization state. Authority returns only via bounded grants issued by an authorization principal and enforced by an independent gate. A grant SHOULD bind principal, resource, operations, scope, budget, expiry, policy digest, nonce, parent grant, and issuer integrity protection.

Delegation and Descendant Revocation Delegation MUST be representable as a derivation relation. Revoking a parent MUST NOT leave descendants enabled beyond the specified propagation bound unless independently authorized under recorded policy. Inventories SHOULD cover cached bearer credentials, presigned URLs, leases, persistent sessions, queues, retry workers, scheduled jobs, and remote delegates.

Closure Receipt A closure receipt SHOULD include authority epoch, root revocation identifier, graph/profile version, cut-set digest, sink-set digest, completion time, coverage statement, unresolved paths, evidence digest, and status. Permitted statuses are REQUESTED, PROPAGATING, CLOSED, PARTIAL, FAILED, and UNKNOWN. CLOSED MUST NOT be emitted if required paths are unresolved or a verifier is indeterminate.

Failure Semantics Missing topology, stale graph state, monitoring failures, unverifiable policy state, or unmodeled consequential paths MUST NOT silently promote a claim to CLOSED; return PARTIAL, FAILED, or UNKNOWN as appropriate.

Security Considerations Threats include stale replicas, replayed grants, cache divergence, races, queue persistence, compromised enforcement, incomplete cut sets, confused-deputy delegation, and missing topology. A cut controlled by the untrusted authority cannot establish independent enforcement. Cryptographic integrity provides representation and provenance integrity, not graph completeness or policy correctness. Operational closure requires structural validation and measured enforcement.

Privacy Considerations Capability graphs and closure receipts can expose organizational topology and principal relationships. Implementations SHOULD minimize topology disclosure and use opaque identifiers.

IANA Considerations This document requests no IANA actions.

Illustrative Conformance Checks A verifier MUST NOT issue CLOSED for a registered path that remains enabled after the propagation bound. A verifier MUST NOT issue CLOSED when its commitment-boundary inventory is empty or unavailable without separately documented proof that this is the complete expected inventory. A verifier SHOULD test queued work, descendant grants, replayed tokens, stale cache state, and independently administered cut enforcement. These are proposed tests, not assertions that implementations have passed them.