The application is no longer the control boundary

Traditional control design assumes a fairly stable place: an ERP permission, a lending approval queue, a call-centre script, a claims rule or a manager's sign-off. Agentic work dissolves that stability. One task may be decomposed by a planner, enriched by a retrieval service, calculated by a model, reviewed by a human, sent to a vendor and committed through an API. Every hop can change who acts, what is visible and what can be enforced.

The resulting risk is not simply that a control is missing. It is that a control exists at the origin, appears in documentation and disappears in operation. A procurement agent may be instructed to obtain three quotations, then enter an ERP account whose technical privileges also permit supplier selection and ordering. A customer-service agent may issue a permissible £50 credit many times across channels because the per-case limit travels while the cumulative daily limit does not. A vendor may return a signed attestation even though its retention rule is not connected to the transaction path. These are control-orphaning failures.

The work therefore needs a durable identity of its own. This paper calls it a work token: a unique, traceable representation of a case, request or obligation. The token carries a Control Envelope, a signed declaration of purpose, authority, constraints, separation, evidence, rights and recovery rules. The envelope is not a licence to trust the next component. It is the input to a fresh local decision before any state-changing act.

A Mobile Control Plane around the moving work

A Mobile Control Plane is the operating system for these envelopes. It does not centralise every decision or place a slow approval in every path. It makes the decision architecture explicit and portable. The token issuer establishes lineage. The envelope carries typed obligations. A policy authority publishes approved meaning. A decision mesh evaluates context. An enforcement mesh blocks or permits local acts. An inheritance resolver narrows authority. A segregation graph checks independence. Evidence, boundary, monitoring, incident and assurance services close the loop.

The plane has twelve parts because control continuity is broader than access control. Identity and authorisation matter, but so do purpose, cumulative limits, required evidence, affected-party rights and recovery. NIST's attribute-based access-control guidance supplies a useful foundation by relating subject, object, operation and environmental attributes. Zero-trust guidance adds per-resource decisions and policy enforcement close to resources. Neither alone proves that an appeal remains possible after expiry or that compensation repaired every downstream effect. The mobile plane extends those principles to the life of a business obligation.

A deployment can be modest. A small firm may use a signed JSON envelope, a compact policy service, gateway checks and an append-only evidence store. A bank may distribute policy bundles to hundreds of local enforcement points with version-skew monitoring and automated quarantine. What must not vary is the semantic contract: the receiver knows what each obligation means, can enforce it before action, can prove what occurred and can refuse the token when it cannot comply.

The Control Envelope is a contract, not a comment

Free-text instructions are valuable context but poor control objects. A model can reinterpret them, a vendor can ignore them and a receiving service may have no field against which to enforce them. The envelope must therefore be typed, versioned, integrity-protected and bound to the token. It should carry enough meaning for the next boundary to decide, while disclosing no more sensitive data than that decision requires.

Data minimisation creates an important design tension. A policy decision may need a sensitive attribute, while a trace should not expose it. The envelope can carry a signed claim such as “eligibility condition E17 satisfied under policy 4.2” rather than the underlying diagnosis or salary. The decision point retains protected evidence under a controlled reference. The enforcement receipt records the claim identifier, decision and policy version. Assurance can later test coverage without broadcasting the raw attribute through every system.

Inheritance means intersection, not copying

The central rule is attenuation: a child token can possess no more authority than its parent, the receiving principal and the current local policy jointly allow. Delegation is a new decision, not a transfer of ambient credentials. If a procurement token permits “collect three quotations”, the agent may create child requests to approved suppliers. It cannot turn an ERP service account into authority to select a supplier or place an order, even if the account could technically do both.

Decision is not enforcement

Policy architecture becomes credible when four responsibilities can be examined separately. A policy administration point publishes approved rules. Policy information points supply attributes and context. A policy decision point returns permit, deny, obligations or indeterminate. A policy enforcement point controls the action path. An agent or model may request and explain a decision, but it must not certify its own authority or convert a generated field such as approved=true into executable approval.

Consider a central decision outage. A local service with a fresh, verified policy cache may continue safe reads and reversible low-value work if the envelope expressly permits that mode. It should not create a new financial commitment merely because an earlier decision was cached. The local point records the degraded basis, shortened expiry and operations allowed. When connection returns, reconciliation checks every locally handled token against current policy.

Separate acts and dependencies, not job titles

Portable segregation of duties is a graph. Its nodes are acts such as request, source, interpret, propose, verify, approve, execute, reconcile, dispute, change policy, change model, administer identity and investigate. Its principals include people, agents, services and vendors. Its edges reveal control or dependency. Two agents with different names are not independent when they use the same faulty source, model, prompt owner or administrator.

A receipt chain proves the journey, not merely the origin

A signature on an envelope establishes integrity and asserted provenance. It does not prove the attribute was true, the rule was good, the control was enforced or the outcome was corrected. Each boundary therefore returns a typed receipt. A decision receipt records the evaluated policy and attributes. An enforcement receipt proves the permit or refusal occurred on the action path. A completion receipt records the resulting state. A recovery receipt records compensation and any unresolved effects.

The chain must survive longer than token execution where rights require it. A customer may appeal after a lending or insurance token has expired. Operational credentials and processing authority should expire promptly, while the notice, reasons, material evidence, policy version and appeal route remain in a separately governed rights record. Expiry is not erasure of accountability.

Recovery is similarly outcome-based. If a duplicate payment is reversed in the ledger but the customer was not notified and a regulatory report remains wrong, the obligation is not closed. A recovery plan enumerates every affected state, party and disclosure. The lineage closes only when each is repaired, expressly waived by an authorised owner or recorded as an accepted residual exposure.

The Control Continuity Proof

Before a token crosses a material boundary, fourteen gates answer whether control will survive. Seven are hard gates: purpose, authority, segregation, enforceability, mandatory evidence, affected-party rights and recoverability. A failure in any of them cannot be traded against efficiency. The remaining gates address identity, integrity, data obligations, freshness, limits, revocation and monitoring. They can permit a bounded degraded mode only where the envelope defines one.

The Control Drift and Orphan Test

A Control Boundary Contract makes the proof operational. It names the supported envelope version, obligation vocabulary, decision interface, enforcement location, receipt schema, maximum policy and attribute age, revocation objective, degraded mode, evidence retention, rights hand-off and failure response. A boundary adapter may translate formats, but it may not silently weaken meaning. Any lossy translation is a reauthorisation event.

The operations panel should show active tokens by risk, descendants per parent, envelope age, policy-version distribution, decisions without enforcement, commits without decisions, missing mandatory receipts, cumulative limit utilisation, revocation latency, quarantined tokens, rights records due for response and recovery items still open. A monthly average is insufficient. The operator must be able to isolate a live lineage before harm propagates.

Two thought experiments about where control really lives

Applied example: covenant review without authority leakage

A lender issues a token permitting document extraction and covenant calculation. The extraction service receives only required pages, a retention limit and a child envelope that prohibits recommendation or approval. A deterministic calculator receives the extracted values and original citations. A risk agent may propose a classification, but the envelope says its output is advisory. A human credit officer receives the source, calculation, disagreement flags and policy version. Only the officer's independent commitment can produce a child token authorising the loan system to record the approved classification.

If the model writes approved=true, the loan system ignores it because the field is not a valid approval commitment. If extraction confidence is low, the evidence gate quarantines the token. If the human edits a figure, the earlier calculation receipt no longer matches and must be rerun. The outcome is not “a human was in the loop”; it is an exact chain of bounded acts in which no participant inherits an authority it did not possess.

Applied example: supplier incident and active revocation

A supplier emergency changes the approved destination list. The policy authority publishes a signed revocation covering both new work and active descendants. Decision points stop new delegations. The continuity monitor locates tokens already at vendor and ordering stages. Enforcement points cancel those not yet committed, while reconciliation identifies completed orders. Recovery may involve cancellation, alternate sourcing, finance adjustment and notifications. Each descendant acknowledges its status.

A system that merely blocks new tokens has not completed revocation. Nor has a cancellation API succeeded if a downstream shipment remains active. The incident docket records the affected lineage, policy change, acknowledgements, completed acts, compensation and unresolved exposure. This turns revocation from a credential event into an outcome-control event.

Eighteen boundary cases that expose weak control mobility

Mobile Control Envelope Designer

Use the designer to test a transition, not to automate a real decision. Each preset changes the boundary conditions. The result uses exactly five operational outcomes: enforce locally, carry a narrower envelope, require independent approval, quarantine, or stop and redesign.

The strongest rival: a distributed control operating system can fail magnificently

This argument defeats a maximalist design. It does not defeat control mobility. The response is proportionality and sharp failure boundaries. Use typed envelopes for material workflows, not every keystroke. Keep deterministic limits and enforcement close to the action. Reduce unnecessary transitions. Separate sensitive evidence from portable claims. Roll out signed policy versions progressively. Test bypasses and semantic equivalence. Give operators a kill path and a narrow degraded mode. Preserve the option to refuse work.

Centralisation is not an automatic alternative. A single decision service can create latency, concentration and outage risk, while still failing to enforce a remote vendor's behaviour. Pure localisation is not sufficient either, because cumulative limits, revocation and case lineage span components. The appropriate architecture combines centrally governed meaning and global lineage with distributed decisions and enforcement under verifiable contracts.

The assurance docket and the operating cadence

For each material workflow, maintain a Workflow Control Assurance Docket: the current token and envelope schemas; purpose and authority catalogue; policy ownership; boundary contracts; segregation graph; decision and enforcement topology; mandatory receipt manifest; degraded-mode rules; rights record; revocation and recovery tests; known semantic translations; risk acceptance; and sampled continuity proofs. The docket should reconstruct a representative token without relying on the people who built the workflow.

Before release, test valid delegation, attempted widening, replay, expired policy, stale attribute, missing evidence, bypassed enforcement, duplicate retry, shared-dependency review, active revocation, delayed appeal and partial compensation. During operation, reconcile decision, enforcement and commit records; sample cross-boundary semantics; measure receipt delay and version skew; inspect quarantine ageing; and exercise kill and recovery paths. After change, rerun the proof for every boundary whose meaning, version, dependency or capability changed.

The leadership question is therefore concrete: for a consequential token chosen at random, can the organisation show who authorised every act, why the authority did not widen, where each control was enforced, what evidence was produced, how conflicting duties stayed separate, whether rights remain available and how all effects would be recovered? If the answer depends on a policy document at the origin or a confident narrative from the agent, the control did not move with the work.