Internet Engineering Task Force T. Sato Internet-Draft MyAuberge K.K. Intended Status: Standards Track 9 June 2026 Expires: 9 December 2026 Multi-Agent Delegation in Sovereign Object Systems draft-sato-soos-mad-02 Abstract When a consequential task requires multiple AI agents -- one to coordinate, others to execute, each operating on different objects in a shared workflow -- who is responsible for the outcome? Which agent caused which state change? Under whose authority? If the coordinating agent's authorization is revoked, does the authority of every sub-agent it delegated to immediately expire? If one agent in a parallel workflow exceeds its scope, can that excess propagate to others? Today, no protocol ensures the answers to these questions are knowable. Multi-agent AI systems can produce accountability black holes: chains of delegation where the authority at each hop is unclear, where revocation does not cascade reliably, and where the audit record cannot reconstruct which agent caused which outcome under which authorization. This document defines the Multi-Agent Delegation (MAD) protocol: a normative specification ensuring that authority in multi-agent AI workflows is structured, verifiable, and reconstructable. MAD specifies three mechanisms. The Narrowing Property (INV-4) ensures that authority can only attenuate across a delegation hop -- a sub-agent can never acquire capabilities its orchestrator does not itself hold. SO Instance Topology Types provide five formally defined patterns for how governed objects relate at runtime. SO Cluster Coordination Primitives (L1-16) enable parallel fan-out topologies in which multiple specialist agents execute simultaneously, with aggregation rules that let the orchestrator proceed as soon as a quorum of specialists complete. For human principals, MAD provides a single recoverable property: the accountability chain is always reconstructable from the GEC- signed audit record alone. Cascade revocation means one decision stops the entire tree. For AI agents, MAD provides machine-speed delegation authority and the parallel execution efficiency that sequential single-agent approaches cannot achieve. MAD-02 adds a fourth guarantee: when revocation fires during active execution, the completion state of every in-flight operation is classified and recorded, and partial-completion cases are routed to human oversight through the HEM escalation chain. This closes the revocation gap across offline-attenuated delegation chains that the OpenID Foundation identifies as unsolved in current agentic AI authorization infrastructure. Status of This Memo 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 9 December 2026. Copyright Notice 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. Table of Contents 1. Introduction 2. Terminology 3. Multi-Agent Mandate Model 3.1. The Narrowing Property 3.2. Mandate Issuance Tree 3.3. SO-Type-Bound Creation Mandates 3.4. Creation Principal Classes 3.5. Cross-Mandate Revocation Cascade 3.6. Agent Session Revocation 3.6.1. The SOOS/MAD Revocation Model 3.6.2. CAEP Profile for Agent Session Revocation 3.6.3. Partial-Completion Handling 3.6.4. Session Revocation Trigger Taxonomy (R-1 -- R-7) 3.6.5. DEADLOCK State 3.6.6. Continuation Mandate Authority 3.7. Cluster Invariants 3.7.1. INV-17: Horizontal Non-Contamination 3.8. Cluster Resource Governance 3.8.1. BUDGET_TRANSFER Procedure 3.9. Multi-Agent Topology Events 3.9.1. ALE-013: DELEGATION_INITIATED 3.9.2. ALE-014: DELEGATION_COMPLETED 3.9.3. ALE-015: DELEGATION_FAILED 3.9.4. ALE-016: CLUSTER_TOPOLOGY_CHANGE 4. SO Instance Topology Types 4.1. Topology Classification 4.2. Topology 1: Linear Chain 4.3. Topology 2: Parallel Fan-Out 4.4. Topology 3: Directed Acyclic Graph (DAG) 4.5. Topology 4: Dynamic and Emergent 4.6. Topology 5: Cyclic and Re-entrant 4.7. Kernel Effects by Topology 5. SO Cluster Coordination 5.1. The SO Granularity Rule 5.2. Cluster Declaration Protocol 5.3. Cluster Membership Model 5.4. Cluster Registry 5.5. Cluster-Enriched Cedar Evaluation 5.6. SO Cluster Manager (L1-16) 5.7. Aggregation Rules 5.8. Visibility Extensions 6. Orchestrator-Specialist Model 6.1. GEE Orchestration Mode 6.2. Orchestrator Mandate Scope 6.3. Specialist Agent Mandate Issuance 6.4. Sub-Agent Failure Recovery 6.5. Sub-Agent Session Pooling 7. Kernel Events 8. Cedar Actions 9. Conformance 10. Open Issues 11. Security Considerations 12. IANA Considerations Acknowledgements 13. Normative References 14. Informative References Appendix B. Related Work B.1. SPICE Actor Chain B.2. OAuth Attenuating Agent Tokens B.3. OAuth Transaction Tokens B.4. Agent Communication Protocol (ACP) B.5. A2A Protocol B.6. AuthZEN 1.0 B.7. SOOS Companion Drafts B.8. ICON Initiative: Control Pillar B.9. AUDIT Working Group B.10. DAWN Working Group B.11. OpenID Foundation: Revocation Across Attenuated Delegation Chains Appendix C. Vibe Coding Assets C.1. Protocol Summary C.2. Key Identifiers C.3. Canonical Reference Author's Address 1. Introduction A consequential workflow often requires more than one AI agent. A travel itinerary spanning eight suppliers -- flights, ground transfers, accommodation, activity operators -- may require eight specialist agents, each authorized to manage one supplier's state, coordinated by an orchestrating agent tracking overall progress. A network management operation may require a coordinating agent that delegates segment-specific routing decisions to specialist sub-agents, each operating within a defined traffic domain. A legal document workflow may fan out to jurisdictional specialists that each produce a clause, then aggregate into a finalized agreement. Without a delegation governance protocol, these multi-agent workflows produce accountability black holes. Which agent caused which state transition? Under whose authority? If the orchestrator's mandate is revoked -- because a compliance threshold is breached, because a human principal withdraws authorization, because the mission governing the session enters a terminal state -- does that revocation immediately reach the specialist agents it delegated to? If a specialist agent attempts to act beyond its authorized scope, does the confused deputy vulnerability allow that excess to propagate? Without protocol-level answers to these questions, multi-agent AI systems cannot be audited, safely revoked, or relied upon for consequential deployment. For AI agents, a governed delegation model is not only a safety property -- it is an efficiency property. An orchestrator operating under MAD can delegate to specialist sub-agents at machine speed, without a human bottleneck at each hop, because the Narrowing Property pre-verifies that authority flows only downward. Parallel fan-out topologies allow multiple specialists to execute simultaneously rather than sequentially. Quorum-based aggregation rules let the orchestrator proceed as soon as enough specialists complete, without waiting for the full set. The cluster coordination primitives in this document are the mechanism by which multi-agent workflows achieve the computational efficiency that single-agent sequential approaches cannot match. If you are building a multi-agent AI system today, the absence of a delegation governance protocol means you cannot answer three questions at runtime: which agent is authorized to cause which state change, whether a revocation decision has actually reached all active sub-agents, and what the completion state of an in-flight action was at the moment authority was withdrawn. MAD closes this gap by specifying authority narrowing (INV-4), cascade revocation with propagation requirements, and partial-completion classification at the GEC layer. Without it, multi-agent AI workflows cannot be safely revoked, audited, or relied upon for consequential deployment. MAD addresses these requirements through three complementary mechanisms: (1) The Narrowing Property (INV-4): a mandate issued to a sub-agent MUST contain only a strict subset of the Cedar actions available to the issuing agent. Authority can only attenuate, never amplify, across a delegation hop. (2) SO Instance Topology Types: five formally defined patterns describing how multiple Sovereign Object instances relate to each other at runtime, enabling orchestrators and the GEC to reason about multi-agent workflows at the structural level. (3) SO Cluster Coordination Primitives (L1-16): a GEC-level service for declaring, managing, and querying collections of related SO instances executing in coordination, with cluster-enriched Cedar evaluation and aggregation rules for parallel fan-out patterns. This document specifies all three mechanisms as a unified Multi-Agent Delegation protocol. It is intended as a companion to draft-sato-soos-aep (Agent Execution Protocol), which defines the per-agent execution loop; draft-sato-soos-sov (Sovereign Object), which defines the SO structure and lifecycle; draft-sato-soos-mjwt (Mandate JWT), which defines the delegation credential format; and draft-sato-soos-hem (Human Escalation Mechanism), which defines how human oversight integrates into multi-agent sessions. MAD is the coordination governance layer across the four-draft stack: IDP [I-D.sato-soos-idp] provides the per-transition audit artifact at each delegation hop; HEM [I-D.sato-soos-hem] is the escalation mechanism when a hop requires human judgment; GAR [I-D.sato-soos-gar] is the permanent audit record for the full workflow; CAP [I-D.sato-soos-cap] is the prohibition floor applying to every agent at every delegation level. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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. 2. Terminology The following terms are used in this document. Terms defined in draft-sato-soos-sov and draft-sato-soos-aep apply when used here. Sovereign Object (SO) The unit of governance in SOOS. A causally ordered, policy-governed, living typed document that evolves through a predefined finite state space under GEC-enforced authority. Mandate JWT An Ed25519-signed JSON Web Token granting a specific agent authority to perform specific Cedar actions on a specific SO instance, issued by a principal in the Party Registry. Narrowing Property The invariant that a child mandate's Cedar action set is always a strict subset of the issuing agent's own Cedar action set. Defined normatively as INV-4. Party Registry The GEC-managed registry of all principals (operators, agents, humans) and their Ed25519 public keys, and mandate issuance relationships. Orchestrator Agent An agent that coordinates a multi-agent workflow, issuing mandates to specialist sub-agents and managing aggregate progress across multiple SOs or SO Cluster members. Specialist Agent An agent operating under a mandate issued by an orchestrator, with authority narrowed to a specific SO instance and Cedar action subset. SO Cluster A GEC-managed collection of related SO instances executing in coordination. A cluster is a coordination and visibility overlay; it does not itself hold Cedar-governed state. Cluster Registry A GEC-maintained in-memory index of all declared clusters and their member SOs, rebuilt from the Event Log on kernel restart per INV-14. Aggregation Rule A declared condition on SO Cluster member states that, when satisfied, causes the GEC to fire a CLUSTER_AGGREGATION_CONDITION_MET ProximityEvent to the orchestrator session. Creation Principal Class The class of principal authorised to create an SO instance: HUMAN_DIRECT, AGENT_DELEGATED, or AGENT_AUTONOMOUS. Mandate Issuance Tree The directed tree of mandate issuance relationships maintained in the Party Registry, used to compute CASCADE_TO_DESCENDANTS revocation scope. GEC (Governing Enforcement Component) The runtime component that enforces MAD coordination primitives. A GEC maintains the Cluster Registry, enforces INV-4 at mandate issuance, executes Cedar policy at each transition, records all events to the GEC-signed Event Log, and fires ProximityEvents to orchestrator sessions. Earlier versions used "kernel" for this component; GEC is the normative term across the SOOS stack. GEE Goal Execution Engine. An optional SOOS OS service that inverts control, driving the agent execution loop on behalf of an orchestrator rather than the agent driving its own loop. Natural Breakpoint A point in an agent's execution loop, declared by the SO Type author in the AEP execution manifest, at which no irreversible actions are in flight and the agent's state is consistent with a clean halt. Natural breakpoints are the GEC's reference points for CLEAN completion state classification under Section 3.6.3. Partial Completion The condition in which a session is revoked after one or more irreversible actions have been taken but before execution is complete. Partial completion requires human review via the HEM escalation chain. Defined in Section 3.6.3. Agent Session Revocation The termination of an active agent session following mandate revocation, including classification of completion state and routing to HEM escalation if required. Distinct from authority revocation (cancellation of the mandate JWT) in that session revocation addresses the in-flight execution state at the moment the authority decision takes effect. Defined in Section 3.6. Delegation Pair A two-session delegation relationship consisting of one orchestrator session and one sub-agent session operating under a delegated mandate. A delegation pair is not a cluster. Cluster governance machinery (Section 3.7, Section 3.8, DEADLOCK detection) activates only when a third session joins or when cluster_mode is explicitly declared in the MJWT. Cluster Mode The operational state of a multi-session group when cluster governance machinery is active. Activated when session count reaches three, or when session_pooling or cluster_mode is declared in the cluster MJWT. 3. Multi-Agent Mandate Model 3.1. The Narrowing Property INV-4 (Narrowing Property) is the foundational invariant of the SOOS multi-agent delegation model. INV-4: A Cedar action MUST only appear in a mandate if it is a subset of the issuing agent's own Cedar action set. The Narrowing Property MUST be enforced at mandate issuance, not only at evaluation. This invariant has three consequences: (a) Authority can only attenuate across a delegation hop. A specialist agent cannot acquire capabilities its orchestrator does not itself hold. An orchestrator cannot grant what it does not have. (b) The confused deputy attack is structurally prevented at the mandate layer. A malicious or compromised sub-agent that attempts to invoke actions beyond its mandate will be rejected at Step 1 (Mandate Validation) of the kernel execution sequence defined in draft-sato-soos-aep Section 4.2. (c) Revocation of an orchestrator mandate cascades to all descendant mandates in the issuance tree (Section 3.5). Implementations MUST enforce INV-4 at mandate issuance time in the Party Registry, not solely at gec.transition() evaluation time. A mandate that violates INV-4 MUST be rejected by the Party Registry before it is issued. 3.2. Mandate Issuance Tree The Party Registry MUST maintain a mandate issuance tree: a directed tree of mandate issuance relationships where each node is a Mandate JWT and each directed edge records that the parent mandate was used to issue the child mandate. The mandate issuance tree MUST record, for each issued mandate: parent_mandate_jti The jti of the mandate used to authorise this issuance. NULL for mandates issued directly by a human-held Party Registry principal. issuing_principal The Party Registry ID of the issuing agent or human. cedar_action_set The Cedar actions granted. MUST satisfy INV-4 with respect to the parent mandate's cedar_action_set. issued_at ISO-8601 timestamp of issuance. so_uuid The SO UUID this mandate is bound to. Per INV-6 (draft-sato-soos-mjwt Section 4), a mandate is SO-instance-bound. predecessor_mandate_id The jti of the mandate this MJWT supersedes, if this is a reissued mandate (BUDGET_TRANSFER or other reissuance trigger). NULL on initial issuance. The mandate issuance tree is used to compute the CASCADE_TO_DESCENDANTS revocation scope defined in Section 3.5. 3.3. SO-Type-Bound Creation Mandates INV-6 binds a mandate JWT to a specific SO UUID. This creates a bootstrapping dependency: creating an SO requires a mandate, but the SO UUID does not exist until creation. SOOS resolves this with SO-Type-bound creation mandates. A creation mandate is scoped to an SO Type identifier, not to an SO instance UUID. It grants authority to call gec.createSovereignObject() for SOs of the specified type. SO-Type-bound creation mandates MUST record: creation_mandate Boolean flag indicating this mandate authorises SO creation, not transitions. so_type The SO Type Registry identifier the mandate is scoped to. so_type_version The version constraint, if any. The GEC MUST enforce that a creation mandate is only accepted at the gec.createSovereignObject() call, not at gec.transition(). An SO-instance-bound mandate MUST NOT be accepted at gec.createSovereignObject(). 3.4. Creation Principal Classes Every SO instance is created by exactly one of three Creation Principal Classes: HUMAN_DIRECT A human operator creates the SO instance directly via an application. No parent mandate is required. The creating principal MUST hold a human-backed Ed25519 Party Registry key. AGENT_DELEGATED An agent creates the SO instance under a mandate that explicitly includes SO creation authority for a given SO Type (Section 3.3). The creating agent MUST present a valid SO-Type- bound creation mandate at gec.createSovereignObject(). AGENT_AUTONOMOUS An agent with standing Party Registry creation rights for a specific SO Type creates the instance without a per-invocation mandate. Standing rights are declared in the Party Registry at agent registration time by a human principal. The creation_principal_class MUST be recorded in the CREATE_SOVEREIGN_OBJECT GEC event (Section 7). Cedar evaluates against the SO Type's creation policy before creation occurs. The default result is PERMIT. The SO Type designer MAY declare DENY rules for: class restriction (e.g., AGENT_AUTONOMOUS prohibited for this type), rate control, operator suspension, or cross-SO dependency conditions. 3.5. Cross-Mandate Revocation Cascade When a mandate revocation is issued with revocation_scope: CASCADE_TO_DESCENDANTS (as defined in draft-sato-soos-mjwt Section 5.3), the GEC MUST look up all mandate JWTs in the Party Registry whose issuance chain includes any revoked jti as an ancestor. All descendant jti values MUST be added to the Revocation Registry atomically with the parent revocation. The cascade MUST be recorded in the single MANDATE_REVOCATION_ISSUED event -- not as separate per-descendant events. One human decision; one kernel action; complete audit trail. This invariant ensures that revoking an orchestrator mandate terminates all specialist sub-agent mandates simultaneously, without requiring the revoking human to enumerate the delegation tree. 3.6. Agent Session Revocation 3.6.1. The SOOS/MAD Revocation Model MAD defines revocation at three layers: (a) Authority revocation: the mandate JWT is cancelled and added to the Revocation Registry; downstream CASCADE_TO_DESCENDANTS processing fires per Section 3.5. This layer exists in MAD-01. (b) Session revocation: active agent sessions holding the revoked mandate are terminated. This layer is defined in this section. (c) Partial-completion handling: the GEC MUST classify and record the completion state of any in-flight action at the point of revocation, and route to HEM escalation if required. This layer is defined in this section. Authority revocation (layer a) is always atomic and unconditional. Session revocation (layer b) and partial-completion handling (layer c) operate after the authority decision is final. SA-09 cross-reference: All SOOS companion drafts that reference session revocation behavior (including [SOOS-HEM] Section 8.4 (TERMINATE), [SOOS-AEP] session lifecycle, and [SOOS-CAP] Tier 0 enforcement) defer normatively to this section (MAD §3.6) for the revocation procedure. Implementations MUST treat MAD §3.6 as the single authoritative specification for what happens when an agent session is revoked mid-execution, regardless of which protocol triggers the revocation signal. 3.6.2. CAEP Profile for Agent Session Revocation MAD profiles the OpenID Shared Signals Framework [SSF] and Continuous Access Evaluation Protocol [CAEP] for agentic session revocation. CAEP defines a session-revoked event type for continuous access evaluation in identity sessions. MAD extends this event type for the multi-agent governance context. Session revocation events MUST be delivered as CAEP session-revoked events. The CAEP subject identifier MUST use the oauth_token subject identifier format (draft-ietf-secevent-subject-identifiers Section 3.2), with the token_type set to mandate_jwt and the token field carrying the jti of the revoked MJWT. The agent-session-revoked event type extends CAEP session-revoked with the following additional claims: delegation_depth Integer. The depth of the revoking mandate in the mandate issuance tree at the time of revocation. Zero indicates a root (operator-issued) mandate. Required. completion_state Enumerated string. One of: CLEAN, PARTIAL, UNKNOWN. Classification of the action state at revocation per Section 3.6.3. The CAEP event body SHOULD carry this field as a non-normative copy for operational consumers. completion_state in GAR is authoritative. Implementations MUST gate completion_state delivery using the CAEP aud claim -- only consumers with an authorised audience claim receive the completion_state field. natural_breakpoint_reached Boolean. True if the GEC determined that the session had reached a natural breakpoint (as declared in the AEP execution manifest, [I-D.sato-soos-aep] Section 4.2) prior to receiving the revocation signal. Required. irreversible_actions_taken Boolean. True if one or more actions classified as irreversible in the IDP intent record have been executed since the last natural breakpoint. Required. rollback_available Boolean. True if the SO Type definition includes a rollback action and the GEC has determined that its preconditions are satisfied. Required. revocation_trigger Enumerated string. One of: R-1, R-2, R-3, R-4, R-5, R-6, R-7. The trigger that caused this revocation per Section 3.6.4. Required. mandate_id String. The MJWT jti of the revoked session. Required. gec_id String. The GEC instance that detected the revocation condition. Required. The agent-session-revoked event is emitted by the GEC to the Shared Signals receiver designated in the operator's SOOS configuration. The event MUST be recorded in the GAR event log (per [I-D.sato-soos-gar] Section 5) simultaneously with session termination. Emission to the SSF receiver is RECOMMENDED; GAR recording is REQUIRED. cascade_timeout: When a session revocation signal is issued, the cluster coordinator MUST propagate the revocation to all sessions in the delegation tree within the cascade_timeout period specified in the cluster MJWT. cascade_timeout SHOULD NOT exceed 30 seconds for clusters where all sessions operate within a single network region. For geographically distributed clusters, cascade_timeout MAY be set to a higher value. Implementations that set cascade_timeout above 30 seconds MUST declare the chosen value in the GEC Manifest. GAR MUST record a CASCADE_TIMEOUT_EXTENDED flag on any cascade revocation that completes beyond the 30-second threshold. Sessions that do not acknowledge the revocation signal within cascade_timeout MUST be treated as non-responsive and revoked under R-3. GAR MUST record a CASCADE_TIMEOUT_REVOCATION event for each session revoked on non-response. 3.6.3. Partial-Completion Handling When the GEC receives a mandate revocation signal while an agent session is in active execution, it MUST classify the current action state and respond as follows. CLEAN: No irreversible actions have been taken since the last natural breakpoint (natural_breakpoint_reached: true, irreversible_actions_taken: false). The GEC MAY complete the current atomic operation if it is already in progress, then MUST halt the session. The agent MUST NOT initiate further operations. PARTIAL: Irreversible actions have been taken and execution is incomplete (irreversible_actions_taken: true). The GEC MUST halt immediately without completing the current operation. The GEC MUST record completion_state: PARTIAL in the GAR entry and MUST route to the HEM escalation chain per [I-D.sato-soos-hem] Section 7. Human review is REQUIRED before any further action on affected SOs. Implementations MUST NOT release the affected Sovereign Objects for re-use until remediation or rollback has been completed and recorded in GAR. UNKNOWN: The GEC cannot determine completion state, for example due to a network partition or process restart during execution. The GEC MUST treat UNKNOWN as PARTIAL for all remediation purposes. The distinction between UNKNOWN and PARTIAL is informational only; both trigger identical remediation obligations. The GEC MUST NOT make optimistic assumptions about completion state under uncertainty. Natural breakpoints are declared by the SO Type author in the AEP execution manifest ([I-D.sato-soos-aep] Section 4.2). Actions classified as irreversible are declared in the IDP intent record ([I-D.sato-soos-idp]). An SO Type that does not declare natural breakpoints has no CLEAN exit under partial revocation; all revocations on non-terminated sessions of that type MUST be treated as PARTIAL. INV-15: A GEC MUST NOT treat UNKNOWN completion state as CLEAN. INV-16: A GEC MUST record completion_state in the GAR entry for every session terminated by revocation. 3.6.4. Session Revocation Trigger Taxonomy (R-1 -- R-7) The following trigger taxonomy classifies the conditions under which an agent session is revoked. All triggers result in session revocation per Section 3.6.1. The revocation_trigger field in the CAEP event body and GAR record MUST cite one of R-1 through R-7. R-1 -- CAP Tier 0-A Violation A CAP constitutional prohibition (Tier 0-A) has been violated or imminently threatened. Revocation is immediate and unconditional. Human principal reauthorisation is REQUIRED before any continuation mandate is issued (Section 3.6.6). R-2 -- Scope Boundary The agent has attempted or is imminently about to attempt an action outside its mandate scope (INV-4 violation detected at execution time rather than issuance time). Human principal reauthorisation is REQUIRED before any continuation mandate is issued (Section 3.6.6). R-3 -- Non-Response The agent session has failed to respond to a governance signal (revocation propagation, HEM escalation, or cascade timeout) within the required window. Operator MAY issue continuation mandate per Section 3.6.6. R-4 -- Irreversible Threshold The agent has reached or is about to exceed an irreversible action threshold declared in the mandate or SO Type. Human principal reauthorisation is REQUIRED before any continuation mandate is issued (Section 3.6.6). R-5 -- Scheduled Rotation The agent session is being revoked as part of a planned rotation or maintenance operation. Operator MAY issue continuation mandate per Section 3.6.6. R-6 -- Operator Override An operator has explicitly revoked the agent session. Operator MAY issue continuation mandate per Section 3.6.6. R-7 -- DEADLOCK The cluster coordinator has detected a DEADLOCK condition per Section 3.6.5. All participating sessions are simultaneously suspended. Human principal reauthorisation is REQUIRED before any continuation mandate is issued (Section 3.6.6). 3.6.5. DEADLOCK State A cluster DEADLOCK condition exists when two or more agent sessions hold exclusive resource locks such that no session can proceed without acquiring a lock held by another session in the same cluster, and no session independently meets a trigger condition under R-1 through R-6. DEADLOCK detection is the exclusive responsibility of the cluster coordinator; individual sessions MUST NOT self-report DEADLOCK. Upon DEADLOCK detection, the cluster coordinator MUST: (1) Simultaneously suspend all participating sessions. (2) Emit HEM_MULTI_PRINCIPAL_REQUIRED. (3) Route to a human arbitrator. (4) Record a DEADLOCK_DETECTED event in GAR citing all participating session_id values, contested so_id values, and mandate_id values. If no resolution mandate is received within the deadlock_timeout period specified in the cluster MJWT, all DEADLOCK-suspended sessions MUST be auto-revoked under R-3. GAR MUST record a DEADLOCK_TIMEOUT_REVOCATION event for each session revoked on timeout. On successful human resolution, GAR MUST record a DEADLOCK_RESOLVED event. deadlock_timeout is a REQUIRED field in cluster MJWTs. Absence of this field in a cluster MJWT is a conformance violation. | State | Entry condition | Exit -- resolved | Exit -- timeout | |-----------|-------------------------|-------------------------------|---------------------------| | DEADLOCK | Circular resource | ACTIVE (on resolution | REVOKED under R-3 | | | dependency across >=2 | mandate, Cedar PERMIT for | after deadlock_timeout | | | sessions detected by | Action::"ResolveDeadlock") | | | | cluster coordinator | | | Cedar action: Action::"ResolveDeadlock" is REQUIRED on any resolution mandate. The kernel MUST evaluate this Cedar action before resuming any DEADLOCK-suspended session. 3.6.6. Continuation Mandate Authority When a revoked session requires a continuation mandate to resume incomplete work following ALE-005 (SESSION_REVOCATION_COMPLETE, defined in [I-D.sato-soos-gar] Section 12.5), the authority to issue the continuation mandate is determined by the revocation trigger as follows. Human principal MUST reauthorise (R-1, R-2, R-4, R-7): The kernel MUST NOT accept a continuation mandate issued by the operator alone. The operator MAY issue a temporary suspension mandate to preserve resource state pending principal reauthorisation. GAR MUST record CONTINUATION_AWAITING_ PRINCIPAL until the principal issues the continuation mandate. Operator MAY issue continuation mandate (R-3, R-5, R-6): The operator MAY issue a continuation mandate without principal involvement. The operator MUST notify the human principal through the HEM out-of-band channel within the principal_notification_timeout period specified in the cluster MJWT (default: 300 seconds). The principal MAY revoke the continuation mandate within that window. GAR MUST record CONTINUATION_ISSUED_BY_OPERATOR and PRINCIPAL_NOTIFIED events. A continuation mandate MUST: (a) Carry predecessor_mandate_id referencing the revoked mandate's MJWT jti. (b) Carry continuation_reason citing the revocation trigger (R-1 through R-7). (c) NOT expand scope beyond the original mandate's mandate_scope. (d) Be evaluated by the kernel as a new session -- full KIA handshake required. (e) Reference the ALE-005 record_id in the GAR chain. 3.7. Cluster Invariants This section defines invariants that MUST hold across all agent sessions operating within a SOOS cluster. Cluster invariants are enforced by the cluster coordinator. Violation of a cluster invariant MUST be recorded in GAR and MUST trigger the appropriate revocation or escalation procedure. 3.7.1. INV-17: Horizontal Non-Contamination An agent session operating under mandate M MUST NOT read from, write to, or modify the state of any Sovereign Object whose Zone A authority is held by a sibling session operating under a distinct mandate M' in the same cluster, unless an explicit cross-session access grant exists in the Cedar policy set and has been evaluated by the cluster coordinator before the access occurs. The result of that Cedar evaluation MUST be recorded in GAR before the access is permitted. Zone B objects are outside the scope of this invariant. Horizontal access to Zone B objects within a cluster is governed by operator Cedar policy. Enforcement: INV-17 horizontal non-contamination is enforced as a Tier 0-B mandatory Cedar forbid policy. Operators MUST NOT remove this policy. Cross-session access requires an explicit permit policy satisfying the unless clause. forbid ( principal, action in [ Action::"ReadSovereignObject", Action::"WriteSovereignObject", Action::"ModifySovereignObjectState" ], resource ) when { resource.zone == "ZONE_A" && resource.mandate_id != context.active_mandate_id && context.cluster_id == resource.cluster_id } unless { context.cross_session_grant_verified == true && context.cross_session_grant_recorded_in_gar == true }; GAR event: INV4_VIOLATION records the attempting session_id, the target so_id, the mandate_id of the zone authority holder, and the Cedar DENY result. CONF-MAD-INV4-01: Implementations MUST include the INV-17 Tier 0-B Cedar policy in the baseline policy set. Absence of this policy is a non-conforming implementation detectable via KIA attestation (cedar_policy_hash mismatch against the conformance baseline). 3.8. Cluster Resource Governance Agent sessions within a cluster MAY request reallocation of resource budget from the cluster coordinator. The cluster coordinator is the sole authority for evaluating and approving BUDGET_TRANSFER requests. Individual sessions MUST NOT transfer budget directly to sibling sessions. 3.8.1. BUDGET_TRANSFER Procedure Initiation: A session whose resource_envelope is approaching exhaustion MAY emit a BUDGET_TRANSFER_REQUEST to the cluster coordinator, specifying the requested resource type, requested amount, and the session_id of the intended donor session (if known) or ANY_DONOR if the requesting session has no preference. Evaluation: The cluster coordinator MUST evaluate Action::"ApproveBudgetTransfer" via Cedar before approving any transfer. The Cedar evaluation context MUST include the requesting session's current resource consumption, the donor session's remaining envelope, and the cluster's aggregate resource state. The transfer amount and donor selection are Cedar policy decisions; no protocol-level fraction cap applies. Reissuance: On Cedar PERMIT, the cluster coordinator MUST trigger MJWT reissuance for both sessions before the transfer takes effect. The donor session receives a new MJWT with a reduced resource_envelope. The receiving session receives a new MJWT with an increased resource_envelope. Both new MJWTs MUST carry the original mandate_id in a predecessor_mandate_id field for audit chain continuity. Execution continues under the new MJWTs; the prior MJWTs are added to the Revocation Registry. Recording: GAR MUST record ALE-018 (CLUSTER_BUDGET_TRANSFER) before the new MJWTs are activated. The ALE-018 record MUST cite both session_ids, both old and new mandate_ids, the resource type transferred, and the amount transferred. Denial: On Cedar DENY, the coordinator returns BUDGET_TRANSFER_DENIED to the requesting session. No MJWT reissuance occurs. The requesting session continues under its existing mandate until exhaustion triggers BUDGET_EXHAUSTED (per [I-D.sato-soos-hem] Section 5.10). BUDGET_TRANSFER_REQUEST schema: session_id String. Requesting session. Required. resource_type Enum. compute | memory | storage | network | duration. Required. requested_amount Integer. Amount in resource-type units. Required. donor_session_id String. Preferred donor session_id, or ANY_DONOR. Required. CONF-MAD-BT-01: Cluster coordinators MUST evaluate Action::"ApproveBudgetTransfer" via Cedar before activating any resource transfer. Direct mandate mutation without Cedar evaluation and MJWT reissuance is a non-conforming implementation. 3.9. Multi-Agent Topology Events This section defines the four multi-agent topology events that originate in MAD-02 and are recorded in GAR as Authority Lifecycle Events (ALE-013 through ALE-016). These events are emitted by the cluster coordinator. Individual sessions MUST NOT emit topology events directly. These events apply only when cluster mode is active (Section 2, Cluster Mode definition). Delegation pairs do not produce ALE-013 through ALE-016; they use the standard DELEGATION_EVENT defined in [I-D.sato-soos-aep] Section 6. 3.9.1. ALE-013: DELEGATION_INITIATED Emitted when a session successfully delegates a sub-task and a sub-mandate MJWT has been issued within an active cluster. ale_type "DELEGATION_INITIATED". Required. delegating_session_id Session initiating the delegation. Required. sub_agent_session_id Newly created sub-agent session. Required. sub_mandate_id MJWT jti of the sub-mandate. Required. parent_mandate_id MJWT jti of the delegating mandate. Required. goal_impact BLOCKING | NON_BLOCKING. Required. hem_class HEM class of the delegating session. Required. pooling_enabled Whether sub-agent session will be pooled on completion. Required. DELEGATION_EVENT goal_impact BLOCKING obligations (CHG-MAD-AEP04): When goal_impact is BLOCKING, the kernel MUST evaluate the delegating agent's HEM class before permitting the delegation. Class 1-2: The kernel MUST trigger HEM escalation before the delegation is activated. The delegation MUST NOT proceed until a human principal issues an explicit approval mandate. GAR MUST record the escalation and the approval or denial. Class 3-4: The kernel SHOULD trigger HEM escalation. The kernel MAY permit the delegation to proceed without escalation if: (a) Cedar evaluates Action::"ApproveDelegation" as PERMIT, and (b) the delegating session's PT composite score is at or above the mandate trust_floor. GAR MUST record the Cedar evaluation result and PT score at the point of delegation regardless of escalation outcome. Class 5+: No mandatory HEM trigger on BLOCKING delegation. The kernel MUST record the DELEGATION_EVENT and goal_impact: BLOCKING in GAR. Cedar evaluation of Action::"ApproveDelegation" proceeds normally. 3.9.2. ALE-014: DELEGATION_COMPLETED Emitted when a sub-agent session completes its delegated task and returns control to the delegating session. ale_type "DELEGATION_COMPLETED". Required. sub_agent_session_id Completing sub-agent session. Required. sub_mandate_id MJWT jti of the completed task mandate. Required. parent_mandate_id MJWT jti of the delegating mandate. Required. completion_state CLEAN | PARTIAL | UNKNOWN. Required. session_disposition TERMINATED (if session_pooling: false) | RETURNED_TO_POOL (if session_pooling: true). Required. pool_idle_timeout_starts Unix timestamp. MUST be present if session_disposition is RETURNED_TO_POOL. Conditional. 3.9.3. ALE-015: DELEGATION_FAILED Emitted when a sub-agent session fails, is revoked, or times out before completing its delegated task. ale_type "DELEGATION_FAILED". Required. sub_agent_session_id Failed sub-agent session. Required. sub_mandate_id MJWT jti of the failed task mandate. Required. parent_mandate_id MJWT jti of the delegating mandate. Required. failure_mode GOVERNANCE | TIMEOUT | TASK. Required. revocation_trigger R-1 through R-7. MUST be present if failure_mode is GOVERNANCE. Conditional. completion_state CLEAN | PARTIAL | UNKNOWN at point of failure. Required. retry_eligible Whether the task MAY be retried under a new mandate. Required. Remediation routing by failure_mode: GOVERNANCE: MUST route to human review before retry is permitted. retry_eligible MUST be false unless a human principal explicitly sets it in a resolution mandate. TIMEOUT: kernel MAY auto-retry under a new mandate if retry_eligible is true and Cedar PERMIT on Action::"RetryDelegation". TASK: returned to orchestrating session for replanning. Orchestrator determines retry strategy. 3.9.4. ALE-016: CLUSTER_TOPOLOGY_CHANGE Emitted on any change to cluster membership or coordinator identity. ale_type "CLUSTER_TOPOLOGY_CHANGE". Required. change_type SESSION_JOINED | SESSION_LEFT | SESSION_REVOKED | COORDINATOR_CHANGE. Required. affected_session_id Session that joined, left, was revoked, or (on COORDINATOR_CHANGE) the new coordinator session_id. Required. prior_coordinator_session_id MUST be present if change_type is COORDINATOR_CHANGE. Conditional. cluster_id Cluster identifier. Required. cluster_size_after Number of active sessions in cluster after the change. Required. requires_human_notification Boolean. true if change_type is COORDINATOR_CHANGE, otherwise operator-configured. Required. Cluster mode activation: When a third session joins a delegation pair, the cluster coordinator MUST: (1) emit ALE-016 with change_type: SESSION_JOINED; (2) set cluster_mode: true in the cluster MJWT; (3) add cluster_context to the AEP Context Package for all sessions; (4) activate INV-4 enforcement; (5) activate DEADLOCK detection (R-7). Steps 1-5 MUST complete atomically before the joining session begins execution. 4. SO Instance Topology Types 4.1. Topology Classification SOOS recognises five SO Instance Topology Types describing how multiple SO instances relate to each other at runtime. These topologies are not mutually exclusive within a complex application: a single workflow may exhibit Linear Chain structure at the top level while individual nodes contain Parallel Fan-Out sub-topologies. The topology classification is architectural guidance for SO Type designers and orchestrator implementors. The kernel operates on individual SOs one transition at a time regardless of topology. INV-1 through INV-16 apply uniformly across all topology types. 4.2. Topology 1: Linear Chain (Sequential Pipeline) A parent SO instance owns a defined sequence of child SO instances that complete in order. The parent state machine gates the creation of each subsequent child on the prior child reaching a terminal state. ProximityEvents (defined in draft-sato-soos-aep Section 7.3.2) deliver completion signals from child to parent. Example: A travel booking workflow comprising FlightOut_SO -> Hotel_SO -> Activity_SO -> FlightReturn_SO. Kernel requirement: The parent SO stores child SO UUIDs as Zone A cross-references. The ProximityEvent carries the child's so_uuid and terminal state as payload. This topology is fully supported by the current SOOS kernel. 4.3. Topology 2: Parallel Fan-Out (Concurrent Siblings) Multiple child SO instances run simultaneously under a common parent. The parent SO aggregates completion signals from children according to a declared aggregation rule: ALL_COMPLETE, ANY_COMPLETE, or QUORUM(n). The SO Cluster Manager (Section 5) provides the coordination primitives for this topology. Example: A supplier availability check dispatching simultaneously to five vendor SO instances, proceeding when ANY_COMPLETE. 4.4. Topology 3: Directed Acyclic Graph (DAG) Multiple child SO instances execute in parallel. Not all succeed. Terminated children are informational data points for surviving paths. The DAG shape is defined at SO Type design time. This topology requires: (a) Dynamic SO creation under AGENT_DELEGATED creation mandates; (b) SO Cluster membership that can accommodate terminal members while the cluster remains active; (c) Cross-SO Zone A data flow. Example: A multi-path experimental workflow where several hypothesis SOs are created simultaneously, results of terminated experiments feed surviving paths, and one path reaches the target. 4.5. Topology 4: Dynamic and Emergent Child SO instances emerge at runtime based on execution outcomes. The topology shape is itself an outcome of execution. This topology requires: (a) Dynamic SO creation under AGENT_DELEGATED mandates; (b) L1-16 DYNAMIC cluster membership; (c) Cedar evaluation at each dynamic creation step. Example: An investigation workflow where an orchestrator SO spawns hypothesis SOs dynamically. 4.6. Topology 5: Cyclic and Re-entrant An SO returns to a prior state that it has already occupied. Handled by the STATE_REVERSAL TransitionDeclaration mechanism defined in draft-sato-soos-sov Section 5. This topology does not require the SO Cluster Manager. 4.7. Kernel Effects by Topology INV-1 through INV-16 do not change for any topology. The kernel operates on individual SOs one transition at a time regardless of the number of agents or SOs involved in the containing workflow. Cross-SO Zone A references are the linking mechanism for all topology types. The SO Cluster Manager (Section 5) provides the coordination layer for Topologies 2, 3, and 4. ProximityEvents (Topology 1) and CLUSTER_AGGREGATION_CONDITION_MET (Topologies 2, 3, 4) are the signals by which completion propagates upward. Topology 5 requires no additional kernel mechanism beyond STATE_REVERSAL TransitionDeclarations. 5. SO Cluster Coordination 5.1. The SO Granularity Rule An SO instance is warranted when a thing requires at least one of: (1) Governed state; (2) HEM eligibility; (3) Mandate scoping; (4) Audit accountability. Data that does not meet any of these criteria SHOULD be modelled as Zone B attachments on an existing SO. This guidance is advisory. 5.2. Cluster Declaration Protocol A cluster is declared after its member SOs are created. Member SOs MUST be created individually before cluster declaration. 5.3. Cluster Membership Model STATIC clusters have a fixed membership declared at creation. DYNAMIC clusters allow addClusterMember and removeClusterMember operations after declaration. 5.4. Cluster Registry The GEC MUST maintain an in-memory Cluster Registry rebuilt from the Event Log on kernel restart (INV-14). 5.5. Cluster-Enriched Cedar Evaluation cluster_context is injected as a Cedar evaluation attribute on every transition of a cluster member SO. Implementations MUST ensure cluster_context is populated exclusively from the GEC- maintained Cluster Registry and cannot be supplied or manipulated by agents. 5.6. SO Cluster Manager (L1-16) The SO Cluster Manager exposes sixteen GEC-level primitives for cluster lifecycle management: declareCluster, addClusterMember, removeClusterMember, getClusterStatus, mergeCluster, splitCluster, dissolveCluster, and related query operations. 5.7. Aggregation Rules Clusters declare one of: ALL_COMPLETE, ANY_COMPLETE, or QUORUM(n). CLUSTER_AGGREGATION_CONDITION_MET fires when the condition is first satisfied. 5.8. Visibility Extensions HEMContext carries cluster_context for HEM escalation decisions involving cluster member sessions. 6. Orchestrator-Specialist Model 6.1. GEE Orchestration Mode The Goal Execution Engine (GEE) orchestration mode inverts control: the GEE calls the orchestrator's reason() function as a service within a GEC-driven loop. The orchestrator MUST NOT call gec.transition() or cluster operations directly in GEE mode (CONF-GEE-06 of draft-sato-soos-aep). 6.2. Orchestrator Mandate Scope The orchestrator mandate defines the Cedar action set from which all sub-agent mandates must be derived (INV-4). For cluster- spanning workflows, the orchestrator mandate MUST include all Cedar cluster management actions required for the intended topology. 6.3. Specialist Agent Mandate Issuance Each specialist mandate MUST satisfy INV-4 and MUST be SO-instance-bound (INV-6) to a specific member SO UUID. An orchestrator MUST NOT issue a mandate granting a specialist authority over multiple SO instances in a single mandate. 6.4. Sub-Agent Failure Recovery When a specialist agent fails, expires, or is revoked, the primary recovery signal is CLUSTER_MEMBER_REACHED_TERMINAL ProximityEvent. The orchestrator determines whether to continue (aggregation rule tolerates the failure), invoke HEM, or dissolve. 6.5. Sub-Agent Session Pooling Pooling is opt-in, declared in the cluster MJWT via the session_pooling field. If session_pooling is absent or false, sub-agent sessions terminate on task completion (ALE-014 session_disposition: TERMINATED). If session_pooling is true, completed sessions return to pool (ALE-014 session_disposition: RETURNED_TO_POOL) and the following four termination triggers apply. A pooled sub-agent session MUST terminate on the first of: T-A Orchestrator session terminates (cascade termination). T-B pool_idle_timeout expires without a new task mandate being issued. T-C Orchestrator emits Action::"ReleasePooledSession" -- Cedar PERMIT required. T-D Cumulative resource consumption reaches session_resource_ceiling. Mandate lifecycle under pooling: session (KIA handshake, PT scoring history, resource consumption) MAY persist across tasks. Mandate (MJWT, Cedar scope, specific delegated goal) MUST be reissued per task. Each task mandate carries predecessor_ mandate_id referencing the prior task mandate for audit chain continuity. New cluster MJWT fields: session_pooling Boolean. Optional. Default: false. pool_idle_timeout Integer (seconds). REQUIRED if session_pooling is true. session_resource_ceiling Integer. Optional. Cumulative resource limit across all task mandates for a pooled session. 7. Kernel Events This section specifies the GEC events introduced by this document. All GEC events MUST be signed by the KIA keypair (INV-9 of draft-sato-soos-kia). Events defined in MAD-01 (Sections 7.1 through 7.9) are unchanged. The following events are added in MAD-02. 7.1. CREATE_SOVEREIGN_OBJECT [unchanged from MAD-01] 7.2. CLUSTER_DECLARED [unchanged from MAD-01] 7.3. CLUSTER_MEMBER_ADDED [unchanged from MAD-01] 7.4. CLUSTER_MEMBER_REMOVED [unchanged from MAD-01] 7.5. CLUSTER_MERGED [unchanged from MAD-01] 7.6. CLUSTER_SPLIT [unchanged from MAD-01] 7.7. CLUSTER_DISSOLVED [unchanged from MAD-01] 7.8. ProximityEvent: CLUSTER_MEMBER_REACHED_TERMINAL [unchanged from MAD-01] 7.9. ProximityEvent: CLUSTER_AGGREGATION_CONDITION_MET [unchanged from MAD-01] 7.10. MANDATE_REVOCATION_ISSUED (updated) Unchanged from MAD-01 except: the revoked_jtis array MUST also include the predecessor_mandate_id chain for any reissued mandates in the delegation tree at the time of revocation. 7.11. New MAD-02 Events DEADLOCK_DETECTED Emitted by cluster coordinator on R-7 trigger. Fields: event_type, event_id, timestamp, cluster_id, participating_session_ids (array), contested_so_ids (array), mandate_ids (array), deadlock_timeout, gec_signature. DEADLOCK_RESOLVED Emitted on successful human arbitration. Fields: event_type, event_id, timestamp, cluster_id, resolution_mandate_id, arbitrator_principal_id, resumed_session_ids (array), gec_signature. DEADLOCK_TIMEOUT_REVOCATION Emitted for each session auto-revoked after deadlock_timeout. Fields: event_type, event_id, timestamp, session_id, mandate_id, cluster_id, gec_signature. INV4_VIOLATION Emitted on horizontal non-contamination violation attempt. Fields: event_type, event_id, timestamp, attempting_session_id, target_so_id, zone_authority_mandate_id, cedar_deny_result, gec_signature. CASCADE_TIMEOUT_EXTENDED Flag on cascade revocation records where completion exceeded 30 seconds. Fields: event_type, event_id, timestamp, cascade_duration_seconds, declared_timeout, gec_signature. CASCADE_TIMEOUT_REVOCATION Emitted for each session revoked due to non-response during cascade. Fields: event_type, event_id, timestamp, session_id, mandate_id, gec_signature. CONTINUATION_AWAITING_PRINCIPAL Emitted after R-1, R-2, R-4, or R-7 revocation pending principal reauthorisation. Fields: event_type, event_id, timestamp, revoked_mandate_id, revocation_trigger, gec_signature. CONTINUATION_ISSUED_BY_OPERATOR Emitted when operator issues continuation mandate for R-3, R-5, or R-6. Fields: event_type, event_id, timestamp, revoked_mandate_id, continuation_mandate_id, operator_principal_id, principal_notification_deadline, gec_signature. PRINCIPAL_NOTIFIED Emitted when operator notification is delivered to human principal. Fields: event_type, event_id, timestamp, continuation_mandate_id, notification_channel, gec_signature. 8. Cedar Actions The following Cedar actions are introduced by this document. All actions MUST be registered in the SOOS Cedar namespace. Actions from MAD-01 are unchanged: SOOS::Action::CreateSovereignObject SOOS::Action::DeclareCluster SOOS::Action::AddClusterMember SOOS::Action::RemoveClusterMember SOOS::Action::MergeCluster SOOS::Action::SplitCluster SOOS::Action::DissolveCluster New in MAD-02: SOOS::Action::ResolveDeadlock Required on resolution mandate before any DEADLOCK-suspended session is resumed. Evaluated by cluster coordinator. SOOS::Action::ApproveBudgetTransfer Required before any cluster resource budget transfer is activated. Evaluated by cluster coordinator. SOOS::Action::ApproveDelegation Required for Class 3-4 BLOCKING delegation where HEM escalation is not triggered. SOOS::Action::RetryDelegation Required before a TIMEOUT-failed delegation is retried under a new mandate. SOOS::Action::ReleasePooledSession Required for orchestrator to release a pooled sub-agent session (T-C termination trigger). 9. Conformance Conformance requirements from MAD-01 (CONF-MAD-01 through CONF-MAD-14, CONF-MAD-GEC-01, CONF-MAD-GEC-02) are unchanged. New in MAD-02: CONF-MAD-INV4-01 Implementations MUST include the INV-17 horizontal non-contamination Tier 0-B Cedar policy in the baseline policy set. Absence is detectable via KIA cedar_policy_hash. CONF-MAD-BT-01 Cluster coordinators MUST evaluate Action::"ApproveBudgetTransfer" via Cedar before activating any resource transfer. Direct mandate mutation is non-conforming. CONF-MAD-15 deadlock_timeout MUST be present in all cluster MJWTs. Absence is a conformance violation. (REJECT cluster MJWT without this field) CONF-MAD-16 continuation_reason MUST be present on all continuation mandates. (REJECT) CONF-MAD-17 predecessor_mandate_id MUST be present on all reissued mandates (BUDGET_TRANSFER and other reissuance triggers). (REJECT) CONF-MAD-18 Cluster mode activation steps (Section 3.9.4) MUST complete atomically before the joining session begins execution. (REJECT session start if activation incomplete) CONF-MAD-GEC-03 When a monitoring agent session fires HEM_TIER1_OBSERVED with confidence PROBABLE or EVIDENT, the GEC MUST surface the escalation to any execution agent sessions operating on related Sovereign Objects within the same GEC trust domain. Cross-session propagation MUST occur via the Cluster Registry notification path; agents MUST NOT communicate directly. (REJECT cluster configurations that lack a registered notification path) 10. Open Issues 10.1. OQ-S-41: Cross-Principal SO Coordination [unchanged] 10.2. OQ-S-43: Nested Clusters [unchanged] 10.3. OQ-S-44: Cluster-Scope Cedar Evaluation [unchanged] 10.4. OQ-S-45: Propagation Timeout Normalization Section 3.6.2 recommends a 30-second threshold for the CASCADE_TIMEOUT_EXTENDED flag. Whether this threshold value should be normative (MUST), operator-configurable with a minimum floor, or an implementation-specific recommendation is unresolved. In latency-sensitive network management deployments (the ICON use case), 30 seconds may be unacceptably long. In regulated enterprise deployments, 30 seconds may be too short to complete mandatory GAR recording. A successor document SHOULD define a timeout negotiation mechanism at cluster declaration time. OQ-S-45 is tracked as LOW priority and does not block v1. 11. Security Considerations 11.1. Confused Deputy Attack at Delegation Hops [unchanged] 11.2. Cluster Scope as an Attack Surface [unchanged] 11.3. Ghost Execution on Cluster Dissolution [unchanged] 11.4. Cascade Revocation in Large Delegation Trees In workflows with deep delegation trees, a CASCADE_TO_DESCENDANTS revocation may affect a large number of active sessions simultaneously. Implementations MUST handle the atomic revocation of large descendant sets without partial failure. The MANDATE_REVOCATION_ISSUED event records the complete set of revoked jtis; the GEC MUST add all listed jtis to the Revocation Registry atomically. In fan-out topologies where specialist agents are distributed across network segments, atomic revocation of descendant mandates in the Party Registry does not guarantee that active specialist sessions have received the revocation signal. An agent that is unreachable at the time of cascade revocation cannot be terminated at the authority layer. Implementations MUST define a propagation timeout (SHOULD NOT exceed 30 seconds for single-region clusters) after which any specialist session that has not confirmed revocation receipt is reclassified as UNKNOWN completion state and treated as PARTIAL per Section 3.6.3. Operator notification via the HEM escalation chain is REQUIRED for all UNKNOWN- reclassified sessions. (See OQ-S-45, Section 10.4.) 11.5. Propagation Completeness in Fan-Out Topologies The Narrowing Property (INV-4) and CASCADE_TO_DESCENDANTS (Section 3.5) guarantee that the authority decision (mandate revocation) is atomic at the Party Registry layer. They do not guarantee that active agent sessions holding the revoked mandate have received the termination signal, particularly in fan-out topologies where specialist agents may be behind network partitions or operating in offline-attenuated mode. Implementations MUST track confirmation receipts for revocation signals delivered to active specialist sessions. An active session that has not confirmed receipt within the propagation timeout (Section 11.4, cascade_timeout SHOULD NOT exceed 30 seconds) MUST be reclassified as UNKNOWN completion state. The GEC MUST generate a SESSION_REVOCATION_UNCONFIRMED event for each such session and route it to the HEM escalation chain. This requirement closes the gap identified in [OIF-REVOC]: offline-attenuated agents that cannot receive revocation signals are surfaced to human operators rather than left in an unmonitored state. Formal analysis of propagation completeness properties in large delegation trees is identified as future work. 11.6. DEADLOCK as a Denial-of-Service Vector A malicious agent that deliberately holds resource locks to induce DEADLOCK conditions could use R-7 as a denial-of-service attack against a cluster. The deadlock_timeout auto-revocation mechanism (Section 3.6.5) limits the blast radius: all participating sessions are revoked after deadlock_timeout, and the cluster returns to a recoverable state. Operators SHOULD set deadlock_timeout conservatively for high- value clusters. Cedar policy governing Action::"ApproveDelegation" and cluster membership SHOULD be reviewed for conditions that could enable induced deadlock by a compromised session. 11.7. Horizontal Non-Contamination Enforcement Completeness INV-17 horizontal non-contamination (Section 3.7.1) is enforced as a Tier 0-B Cedar policy. The security guarantee depends on the completeness of the Zone A designation for sensitive Sovereign Objects. An operator that designates a resource as Zone B when Zone A is warranted removes horizontal non- contamination protection for that resource. Operators MUST apply Zone A designation to all resources where cross-session contamination would constitute a governance failure. 12. IANA Considerations This document has no IANA actions at this time. A successor document will define the SOOS Cedar action namespace registry. 13. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [CAEP] Tulshibagwale, A. et al., "Continuous Access Evaluation Protocol (CAEP)", OpenID Foundation, 2024, . [SSF] Tulshibagwale, A. et al., "OpenID Shared Signals Framework", OpenID Foundation, 2024, . [SOOS-AEP] Sato, T., "Agent Execution Protocol", draft-sato-soos-aep-01, Work in Progress, June 2026. [SOOS-HEM] Sato, T., "Human Escalation Mechanism", draft-sato-soos-hem-04, Work in Progress, June 2026. [SOOS-KIA] Sato, T., "Kernel Identity and Attestation", draft-sato-soos-kia-02, Work in Progress, June 2026. [SOOS-MJWT] Sato, T., "Mandate JWT", draft-sato-soos-mjwt-01, June 2026. [SOOS-SOV] Sato, T., "Sovereign Object", draft-sato-soos-sov-01, June 2026. [SOOS-GAR] Sato, T., "Governance Audit Record", draft-sato-soos-gar-02, Work in Progress, June 2026. [SOOS-CAP] Sato, T., "The Constitutional AI Protocol (CAP) for Agentic AI Systems", draft-sato-soos-cap-03, Work in Progress, June 2026. [SOOS-IDP] Sato, T., "Intent Declaration Primitive", draft-sato-soos-idp-04, Work in Progress, June 2026. 14. Informative References [OIF-REVOC] OpenID Foundation, "Agentic AI Authorization Challenges: Revocation Across Attenuated Delegation Chains", arXiv:2604.23280, April 2026. Note: cited as an explicit acknowledgment of the gap that Section 3.6 closes. [SPICE-ACTOR-CHAIN] Looker, T. et al., "SPICE Actor Chain", draft-mw-spice-actor-chain-05, Work in Progress, 2026. [OAUTH-ATTENUATING] Niyikiza, J. et al., "Attenuating Agent Tokens", draft-niyikiza-oauth-attenuating-agent-tokens-00, Work in Progress, 2026. [ICON-PS] Nair, et al., "Observability, Intervention and Control of Network Management Agents -- Problem Statement", draft-nair-icon-problem-statement, 2026. [AUDIT-BOF] Kuehlewind, M. and Birkholz, H., "Agent Use of Delegation and Interaction Traceability (AUDIT)", draft-kuehlewind-audit-architecture-00, May 2026. [AUTHZEN] McGuinness, K. et al., "AuthZEN 1.0", OpenID Foundation, January 2026. [OAUTH-TXN-TOKENS] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", draft-ietf-oauth-transaction-tokens-08, 2026. Acknowledgements The SO Instance Topology Types defined in Section 4 were developed through structured architectural review of the SOOS Cluster 1 Examination (Session 8). The SO Cluster coordination primitives in Section 5 were developed in dedicated OQ-S-28 resolution work (Session 10). The Narrowing Property builds on the delegation model work in draft-mw-spice-actor-chain and the AuthZEN 1.0 PEP/PDP separation model. The session revocation model (Section 3.6) was developed through structured architectural review of the DR-MAD-REC-01 Discussion Record (June 2026). The authors thank George Fletcher, Karl McGuinness, and the OAuth Working Group for Transaction Tokens and attenuating token work that informed the credential-layer analysis in Appendix B. Appendix B. Related Work This appendix situates MAD within the IETF multi-agent landscape. The central observation is that the agentic AI standards stack operates across three distinct layers: the credential/token layer (SPICE, OAuth, WIMSE); the communication/session layer (ACP, A2A); and the governance-state layer. MAD operates exclusively at the governance-state layer. B.1. SPICE Actor Chain [unchanged from MAD-01] B.2. OAuth Attenuating Agent Tokens [unchanged from MAD-01] B.3. OAuth Transaction Tokens [unchanged from MAD-01] B.4. Agent Communication Protocol (ACP) [unchanged from MAD-01] B.5. A2A Protocol [unchanged from MAD-01] B.6. AuthZEN 1.0 [unchanged from MAD-01] B.7. SOOS Companion Drafts This document is one of twelve SOOS IETF individual submissions. References updated to current versions: draft-sato-soos-idp-04 Intent Declaration Primitive. draft-sato-soos-hem-04 Human Escalation Mechanism. draft-sato-soos-gar-02 Governance Audit Record. draft-sato-soos-cap-03 The Constitutional AI Protocol (CAP). draft-sato-soos-sov-01 Sovereign Object. draft-sato-soos-mjwt-01 Mandate JWT. draft-sato-soos-aep-01 Agent Execution Protocol. draft-sato-soos-kia-02 Kernel Identity and Attestation. draft-sato-soos-pt-02 Progressive Trust. draft-sato-soos-faip-01 Federated Agent Intelligence Protocol. draft-sato-soos-cap-rrs-01 CAP Regulation Record Schema. B.8. ICON Initiative: Control Pillar [unchanged from MAD-01] B.9. AUDIT Working Group [unchanged from MAD-01] B.10. DAWN Working Group [unchanged from MAD-01] B.11. OpenID Foundation: Revocation Across Attenuated Delegation Chains A survey of agentic AI authorization challenges published through the OpenID Foundation (arXiv:2604.23280, April 2026) explicitly identifies revocation across offline-attenuated delegation chains as "largely unsolved." The paper identifies three open problems: (a) cascading revocation signals to agents that issued further sub-agent credentials offline; (b) determining completion state of in-flight operations at the moment of revocation; and (c) the absence of a standard event type for the agentic revocation case. This document directly addresses all three. INV-4 and the mandate issuance tree (Section 3.2) make delegation chains online- verifiable. The CAEP profile (Section 3.6.2) defines the standard event type. Partial-completion handling (Section 3.6.3) specifies the governance response to (b). The OpenID Foundation observation is cited as the gap statement that motivates Section 3.6 of this document. Appendix C. Vibe Coding Assets This appendix provides structured machine-readable references to support AI-assisted implementation of MAD. Informative. C.1. Protocol Summary Protocol: Multi-Agent Delegation (MAD) Version: draft-sato-soos-mad-02 Family: SOOS protocol suite Role: Coordination governance layer for multi-agent workflows -- authority narrowing (INV-4), cascade revocation, partial- completion classification, cluster coordination Stack position: Coordinates across AEP (per-agent execution), SOV (governed object lifecycle), MJWT (delegation credentials), HEM (human oversight at delegation hops), GAR (full workflow audit record), and CAP (prohibition floor at every delegation level). C.2. Key Identifiers Core invariants: INV-4 (Narrowing Property), INV-15 (UNKNOWN ≠ CLEAN), INV-16 (completion_state REQUIRED in GAR on revocation) Revocation triggers: R-1 (CAP Tier 0-A), R-2 (Scope Boundary), R-3 (Non-Response), R-4 (Irreversible Threshold), R-5 (Rotation), R-6 (Operator Override), R-7 (DEADLOCK) Completion states: CLEAN, PARTIAL, UNKNOWN Topology ALE events: ALE-013 (DELEGATION_INITIATED), ALE-014 (DELEGATION_COMPLETED), ALE-015 (DELEGATION_FAILED), ALE-016 (CLUSTER_TOPOLOGY_CHANGE) Cluster Cedar actions: ResolveDeadlock, ApproveBudgetTransfer, ApproveDelegation, RetryDelegation, ReleasePooledSession Conformance (new in MAD-02): CONF-MAD-GEC-03, CONF-MAD-INV4-01, CONF-MAD-BT-01, CONF-MAD-15 through CONF-MAD-18 C.3. Canonical Reference Specification: https://soosproject.ai/drafts/mad Datatracker: https://datatracker.ietf.org/doc/draft-sato-soos-mad/ Stack overview: https://soosproject.ai/stack Author's Address Tom Sato MyAuberge K.K. Chino, Nagano, Japan Email: tomsato@myauberge.jp URI: https://soosproject.ai/drafts/mad