Internet Engineering Task Force T. Sato Internet-Draft MyAuberge K.K. Intended Status: Informational 24 May 2026 Expires: 24 November 2026 Multi-Agent Delegation in Sovereign Object Systems draft-sato-soos-mad-00 Abstract This document specifies the Multi-Agent Delegation (MAD) protocol for the Sovereign Object OS (SOOS) governance architecture. It defines how authority is structured, propagated, and enforced when multiple AI agents coordinate in a SOOS-governed execution environment. The specification covers the Narrowing Property invariant for mandate delegation chains, SO Instance Topology types for multi-agent workflow patterns, SO Cluster coordination primitives for parallel and dynamic agent topologies, and the Orchestrator-Specialist interaction model. MAD is the multi-agent coordination complement to the governance primitives defined in draft-sato-soos-aep, draft-sato-soos-sov, and draft-sato-soos-mjwt. 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 24 November 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 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 7. Kernel Events 8. Cedar Actions 9. Conformance 10. Open Issues 11. Security Considerations 12. IANA Considerations 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 15. Acknowledgements Author's Address 1. Introduction OAuth 2.0 and its extensions were designed for single-hop, human-initiated delegation: a human authorises a client to act on a resource server on their behalf. Agentic AI systems require a fundamentally different delegation model: multi-hop, machine-speed, context-aware delegation chains where authority flows from an authorising human principal through an orchestrator agent to one or more specialist sub-agents, each operating on one or more Sovereign Objects, with authority strictly attenuated at every hop. The confused deputy attack is exploitable at each delegation boundary. A sub-agent that inherits parent authority without narrowing can act beyond the scope its principal intended. When multiple agents coordinate asynchronously across a workflow, the accountability chain -- which agent, under which mandate, caused which state transition -- must be reconstructable from the audit record alone. SOOS 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 kernel to reason about multi-agent workflows at the structural level. (3) SO Cluster Coordination Primitives (L1-16): a kernel-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. 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 kernel-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 kernel-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 kernel-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 kernel-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 kernel 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. 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. 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 kernel.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. 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 kernel.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 kernel MUST enforce that a creation mandate is only accepted at the kernel.createSovereignObject() call, not at kernel.transition(). An SO-instance-bound mandate MUST NOT be accepted at kernel.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 kernel.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 kernel 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 kernel 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. 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-14 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. The parent BookingObject_SO enters a "legs pending" parallel state; each leg SO's terminal state fires a ProximityEvent to the parent. 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. The parent state machine uses these references to gate its own transitions. 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. The orchestrator declares a cluster after creating the member SOs; the kernel evaluates the aggregation rule at each PARALLEL_FAN_OUT member transition and fires CLUSTER_AGGREGATION_CONDITION_MET when the condition is satisfied. 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 (dead ends) 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: surviving children reference the Zone A data produced by terminated siblings. The kernel does not enforce the DAG structure. The orchestrator is responsible for declaring cluster membership and managing cross-SO references in Zone A. 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, not a pre-defined structure. This is the most general case, of which Topology 3 (DAG) is a constrained special case. This topology requires: (a) Dynamic SO creation under AGENT_DELEGATED mandates at each step where the orchestrator determines a sub-task warrants governance. (b) L1-16 DYNAMIC cluster membership (addClusterMember, removeClusterMember). (c) Cedar evaluation at each dynamic creation step. Example: An investigation workflow where an orchestrator SO spawns hypothesis SOs dynamically; each hypothesis spawns experiment SOs on positive results; experiments spawn retry SOs on partial failure. The topology is determined by data, not design. 4.6. Topology 5: Cyclic and Re-entrant An SO returns to a prior state that it has already occupied. This is not a new child SO -- it is the same instance re-entering a state in its own state machine. This topology is handled by the STATE_REVERSAL TransitionDeclaration mechanism defined in draft-sato-soos-sov Section 5. The SO Type designer declares which transitions are STATE_REVERSALs and which settled obligations they disturb. The authority to execute a STATE_REVERSAL is determined by the settled_obligations_disturbed field. Example: A quality review process where a batch SO can cycle between PROCESSING and QUALITY_REVIEW states multiple times before reaching APPROVED or REJECTED. This topology does not require the SO Cluster Manager. It is resolved entirely by the state machine and TransitionDeclaration mechanism. 4.7. Kernel Effects by Topology INV-1 through INV-14 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. What changes by topology is the orchestration layer above the kernel: o Cross-SO Zone A references are the linking mechanism for all topology types. A parent SO stores child SO UUIDs in Zone A; this is how the topological relationship is represented in the governed record. o The SO Cluster Manager (Section 5) provides the coordination layer for Topologies 2, 3, and 4. o ProximityEvents (Topology 1) and CLUSTER_AGGREGATION_CONDITION_MET (Topologies 2, 3, 4) are the signals by which completion propagates upward in the topology. o Topology 5 requires no additional kernel mechanism beyond STATE_REVERSAL TransitionDeclarations. 5. SO Cluster Coordination 5.1. The SO Granularity Rule Before specifying cluster primitives, this section provides normative guidance on when a discrete SO instance is warranted, to prevent the performance and governance costs of over-granular SO creation in multi-agent workflows. An SO instance is warranted when a thing requires at least one of: (1) Governed state: the thing has discrete lifecycle phases requiring Cedar-enforced authority to transition. (2) HEM eligibility: a human must be able to halt and decide at this unit's boundary. (3) Mandate scoping: different agents or humans require different authority over this thing independently. (4) Audit accountability: an independent governance history of this specific unit is required. Data that does not meet any of these criteria SHOULD be modelled as Zone B attachments on an existing SO, not as a separate SO instance. This guidance is advisory, not normative. The SO Type designer determines the appropriate granularity for their domain. 5.2. Cluster Declaration Protocol A cluster is declared after its member SOs are created. The cluster is a coordination and visibility overlay on existing SO instances; it does not itself hold Cedar-governed state. Timing: Member SOs MUST be created individually before cluster declaration. The kernel does not support batch SO creation. Authority: All three Creation Principal Classes (Section 3.4) may declare clusters. Cluster declaration is Cedar-evaluated against the DeclareCluster Cedar action (Section 8). SO state impact: Cluster declaration does not alter the state of any member SO. The cluster is coordination overlay only. Merge and split: Merging two clusters into one, and splitting one cluster into two, are first-class operations. Both require Cedar evaluation against MergeCluster and SplitCluster (Section 8). When clusters are merged, the orchestrator mandate governing the resulting cluster MUST satisfy INV-4 with respect to all mandates held by agents operating on any member SO. Orchestrator declaration on merge or split: The orchestrator MUST explicitly declare the new cluster structure after a merge or split. The kernel does not infer cluster structure from agent behaviour. Mandate scope on merge: INV-4 (Narrowing Property) is enforced at individual SO transition time, not at merge declaration time. New kernel events: CLUSTER_DECLARED, CLUSTER_MERGED, CLUSTER_SPLIT (Section 7). Conformance rules: CONF-MAD-01: A cluster MUST NOT be declared with zero members. CONF-MAD-02: A CLUSTER_MERGED event MUST record both source cluster IDs and the resulting cluster ID. CONF-MAD-03: A CLUSTER_SPLIT event MUST record the source cluster ID and both resulting cluster IDs. 5.3. Cluster Membership Model Each cluster is declared with a membership model at creation time. The membership model is immutable after declaration. STATIC membership: Members are declared at cluster creation and cannot change. addClusterMember and removeClusterMember are not permitted on STATIC clusters. DYNAMIC membership: Members may be added and removed via addClusterMember and removeClusterMember. These operations are Cedar-evaluated (Section 8). Terminal state handling: When a cluster member SO reaches a terminal state, the kernel fires a CLUSTER_MEMBER_REACHED_TERMINAL ProximityEvent to all active sessions on the cluster. The orchestrator MUST explicitly declare member removal via removeClusterMember. The kernel does not automatically remove terminal members. This preserves INV-5 (every transition has exactly one Event Log entry) and makes terminal-state handling self-correcting under orchestrator failure. Completed member retention: Terminal members are retained in the Cluster Registry with TERMINAL status until CLUSTER_DISSOLVED. This allows the orchestrator to query the full cluster history at any point in the workflow. New kernel events: CLUSTER_MEMBER_ADDED, CLUSTER_MEMBER_REMOVED (Section 7). New ProximityEvent: CLUSTER_MEMBER_REACHED_TERMINAL (Section 7). Conformance rules: CONF-MAD-04: addClusterMember MUST be rejected on STATIC clusters. CONF-MAD-05: removeClusterMember MUST be rejected for members in non-TERMINAL states on STATIC clusters. CONF-MAD-06: CLUSTER_MEMBER_REACHED_TERMINAL MUST be delivered to all active sessions before any subsequent SENSE delivery on the affected cluster. CONF-MAD-07: The orchestrator MUST explicitly call removeClusterMember before dissolveCluster if any members remain in non-TERMINAL states. 5.4. Cluster Registry The kernel MUST maintain a Cluster Registry: an in-memory index of all declared clusters, their members, current member states, and aggregation status. INV-14 (Cluster Registry Reconstruction): The Cluster Registry MUST be rebuilt from the Event Log on kernel restart. It is a performance projection of the Event Log, not a second source of truth. The pattern is identical to the Revocation Registry defined in draft-sato-soos-mjwt Section 5.2. The Cluster Registry MUST maintain, for each cluster: cluster_id UUID v4, kernel-assigned at declaration. membership_model STATIC or DYNAMIC. members[] For each member SO: so_uuid, current_so_state (projection updated on every member STATE_TRANSITION), lifecycle_phase, membership_status (ACTIVE or TERMINAL). aggregation_rule Declared aggregation condition, if any. aggregation_fired Boolean; TRUE after the aggregation condition has been satisfied once. orchestrator_session The session_id of the orchestrator agent. Performance contract: o getClusterStatus(): O(1), target <1ms. o Cluster Registry update on member SO transition: O(1). o INV-14 Event Log replay: O(e) where e is the number of cluster- related events. Accepted, same class as Revocation Registry. CONF-MAD-08: The Cluster Registry MUST be rebuilt from the Event Log on kernel restart before processing any cluster queries. 5.5. Cluster-Enriched Cedar Evaluation The kernel MUST NOT evaluate Cedar at the cluster scope. Cedar evaluates at the individual SO transition scope only. This preserves the kernel contract (draft-sato-soos-aep Section 4.1): every transition is atomic, Cedar-evaluated, and Event-Log- committed at the individual SO level. However, individual SO transitions on cluster members SHOULD carry cluster context to enable cluster-aware Cedar policies. The kernel MUST inject a cluster_context attribute into the Cedar evaluation context for every transition on a cluster member SO. The cluster_context attribute is populated from the Cluster Registry (O(1) lookup) and carries: cluster_id The cluster this SO belongs to. cluster_size Total member count. terminal_count Count of members in TERMINAL state. aggregation_status PENDING or CONDITION_MET. is_last_active Boolean; TRUE if this is the last non- terminal member. This enables Cedar policies such as: "PERMIT this action only if aggregation_status is CONDITION_MET" or "REQUIRE HEM if is_last_active is TRUE and action is ROLLBACK". CONF-MAD-09: cluster_context MUST be populated from the Cluster Registry before Cedar evaluation on any cluster member transition. 5.6. SO Cluster Manager (L1-16) L1-16 is a normative SOOS OS service. Implementations conforming to this document MUST provide the SO Cluster Manager with the following six functions: declareCluster(member_so_uuids[], membership_model, aggregation_rule, orchestrator_session_id) Declares a new cluster. Cedar evaluation: DeclareCluster. Returns: cluster_id (UUID v4, kernel-assigned). Fires: CLUSTER_DECLARED kernel event. getClusterStatus(cluster_id) Pure read. Returns the Cluster Registry entry for the cluster. No Cedar evaluation. O(1), no Event Log scan. Returns: cluster_id, membership_model, members[], aggregation_status, aggregation_fired. addClusterMember(cluster_id, so_uuid) Adds a member to a DYNAMIC cluster. Cedar: AddClusterMember. Fires: CLUSTER_MEMBER_ADDED kernel event. removeClusterMember(cluster_id, so_uuid) Removes a member from a cluster. Cedar: RemoveClusterMember. MUST be rejected if so_uuid is in non-TERMINAL state on a STATIC cluster (CONF-MAD-05). Fires: CLUSTER_MEMBER_REMOVED kernel event. mergeCluster(cluster_id_a, cluster_id_b) Merges two clusters into one. Cedar: MergeCluster. Fires: CLUSTER_MERGED kernel event. Both source clusters are dissolved; a new cluster_id is assigned. splitCluster(cluster_id, member_set_a[], member_set_b[]) Splits one cluster into two. Cedar: SplitCluster. Fires: CLUSTER_SPLIT kernel event. The source cluster is dissolved; two new cluster_ids are assigned. dissolveCluster(cluster_id) Dissolves the cluster. Cedar: DissolveCluster. MUST be rejected if any members are in non-TERMINAL state (CONF-MAD-10). Fires: CLUSTER_DISSOLVED kernel event. CONF-MAD-10: dissolveCluster MUST be REJECTED if any cluster member SO is in non-TERMINAL state. 5.7. Aggregation Rules The orchestrator MAY declare an aggregation rule at cluster creation time. The aggregation rule defines a condition on cluster member states that, when satisfied, triggers the CLUSTER_AGGREGATION_CONDITION_MET ProximityEvent. Supported aggregation conditions: ALL_COMPLETE All member SOs have reached terminal states. ANY_COMPLETE At least one member SO has reached a terminal state. QUORUM(n) At least n member SOs have reached terminal states, where n is declared at creation time and MUST be between 1 and the total member count. The kernel evaluates the aggregation rule at every PARALLEL_FAN_OUT member SO transition using the Cluster Registry projection (no Event Log scan required). When the aggregation condition is first satisfied and aggregation_fired is FALSE: (a) The kernel fires CLUSTER_AGGREGATION_CONDITION_MET as a ProximityEvent to the orchestrator session. (b) The kernel sets aggregation_fired to TRUE in the Cluster Registry. The condition fires exactly once. Session availability: If no active orchestrator session exists when the condition is satisfied, the ProximityEvent is queued and delivered at the start of the next orchestrator session. This follows the existing ProximityEvent delivery model. Conformance rules: CONF-MAD-11: Aggregation rule evaluation MUST use the Cluster Registry projection, not an Event Log scan. CONF-MAD-12: CLUSTER_AGGREGATION_CONDITION_MET MUST be delivered exactly once per cluster lifetime. Subsequent member transitions after aggregation_fired is TRUE MUST NOT re-fire the event. CONF-MAD-13: QUORUM(n) where n exceeds the member count MUST be rejected at cluster declaration time. 5.8. Visibility Extensions Multi-agent visibility is a first-class concern. This section specifies extensions to three existing OS service surfaces that enable cluster-aware visibility. 5.8.1. Agent Visibility: L1-01 (Live Permission Map) L1-01 is extended to support cluster-scope permission queries. The new function getClusterPermittedActions(cluster_id) returns, for each member SO, the set of Cedar-permitted actions under the calling agent's current mandate. This enables an orchestrator to determine the available action space across all cluster members in a single call, using the Cluster Registry projection for member enumeration and individual Cedar evaluation per member. Performance contract: O(1) per member via Cluster Registry; Cedar evaluation is O(m) where m is the member count. 5.8.2. Agent Visibility: L1-09 (Transition Graph) L1-09 is extended to support cluster-scope path planning. The new function getClusterTransitionGraph(cluster_id) returns a cluster-scope path plan with a precondition field orchestrator_path_precondition: AGGREGATION_CONDITION_MET. This allows the orchestrator to declare its intended path conditional on aggregate completion, enabling plan validation before any individual member transition is executed. 5.8.3. Human Visibility: HEMContext The HEMContext schema defined in draft-sato-soos-hem Section 7.8.3 is extended with a cluster_context field. When a HEM is invoked on a cluster member SO, the HEMContext delivered to the deciding human principal MUST include: cluster_id The cluster this SO belongs to. cluster_summary Member list with current states. aggregation_status PENDING or CONDITION_MET. is_triggering_so TRUE for the member SO that triggered HEM. This enables the human reviewer to understand the multi-agent workflow state at the time of escalation, not only the individual SO state. CONF-MAD-14: cluster_context in HEMContext MUST be populated from the Cluster Registry at HEM_INVOKED time. 6. Orchestrator-Specialist Model 6.1. GEE Orchestration Mode The Goal Execution Engine (GEE) orchestration mode, defined in draft-sato-soos-aep Section 7.6, is the normative operating model for orchestrator agents in SOOS. In GEE mode, the GEE inverts control: rather than the orchestrator agent driving its own AEP loop, the GEE calls the orchestrator's reason() function as a service within a kernel-driven loop. The orchestrator exposes a single reasoning interface: reason(context_package: ContextPackage) -> ReasoningOutput The GEE is responsible for: (a) Delivering normative Context Packages to the orchestrator. (b) Constructing the IDP from the orchestrator's ReasoningOutput. (c) Calling kernel.transition() and kernel cluster operations on behalf of the orchestrator. (d) Issuing sub-agent mandates from the orchestrator's mandate. The orchestrator MUST NOT call kernel.transition() or cluster operations directly in GEE mode (CONF-GEE-06 of draft-sato-soos-aep). 6.2. Orchestrator Mandate Scope An orchestrator agent operates under a mandate issued by a human principal. The orchestrator mandate defines the Cedar action set from which all sub-agent mandates must be derived (INV-4). The orchestrator mandate MUST be SO-instance-bound (INV-6) for each SO the orchestrator will transition directly. For SOs the orchestrator creates and then delegates to specialists, the orchestrator holds a SO-Type-bound creation mandate (Section 3.3) plus the Cedar actions required to declare and manage the cluster. For cluster-spanning workflows, the orchestrator mandate MUST include all Cedar cluster management actions required for the intended topology: DeclareCluster, AddClusterMember (for DYNAMIC clusters), MergeCluster or SplitCluster (if topology evolution is expected), and DissolveCluster. 6.3. Specialist Agent Mandate Issuance The orchestrator issues mandates to specialist agents. Each specialist mandate MUST satisfy INV-4: the specialist's Cedar action set MUST be a strict subset of the orchestrator's Cedar action set on the same SO. Each specialist mandate MUST be SO-instance-bound (INV-6) to a specific member SO UUID. An orchestrator MUST NOT issue a mandate that grants a specialist authority over multiple SO instances in a single mandate. If a specialist requires authority over multiple SOs, the orchestrator MUST issue separate mandates, one per SO, each individually INV-4-compliant. The mandate issuance tree (Section 3.2) records each issuance relationship, enabling full provenance reconstruction at audit time. 6.4. Sub-Agent Failure Recovery When a specialist agent fails, expires, or is revoked, the orchestrator must recover the cluster state. The primary recovery signal is CLUSTER_MEMBER_REACHED_TERMINAL ProximityEvent. The recovery protocol is: (1) The orchestrator receives CLUSTER_MEMBER_REACHED_TERMINAL for the failed specialist's member SO. (2) The orchestrator calls getClusterStatus() to determine the full cluster state. (3) Based on the cluster state and the member SO's terminal state, the orchestrator determines whether to: (a) Continue -- the aggregation rule tolerates this failure (e.g., QUORUM(n) is still achievable). (b) Invoke HEM -- the failure is outside the orchestrator's confident decision scope. (c) Dissolve -- the workflow cannot continue; the orchestrator initiates compensating actions on all remaining members. If the sub-agent's mandate was revoked (not expired), the CASCADE_TO_DESCENDANTS behaviour (Section 3.5) ensures all further transitions under the revoked mandate are blocked. 7. Kernel Events This section specifies the kernel events introduced by this document. All kernel events MUST be signed by the KIA keypair (INV-9 of draft-sato-soos-kia). 7.1. CREATE_SOVEREIGN_OBJECT CREATE_SOVEREIGN_OBJECT { event_type: "CREATE_SOVEREIGN_OBJECT", event_id: , timestamp: , so_uuid: , so_type: , so_type_version: , creation_principal_class: "HUMAN_DIRECT" | "AGENT_DELEGATED" | "AGENT_AUTONOMOUS", creation_mandate_jti: | null, initial_state: , initial_zone_a_data: { }, cedar_creation_result: "PERMIT" | "DENY", kernel_signature: } creation_mandate_jti is null for HUMAN_DIRECT and AGENT_AUTONOMOUS creation. MUST be non-null for AGENT_DELEGATED creation. 7.2. CLUSTER_DECLARED CLUSTER_DECLARED { event_type: "CLUSTER_DECLARED", event_id: , timestamp: , cluster_id: , membership_model: "STATIC" | "DYNAMIC", member_so_uuids: [ , ... ], aggregation_rule: "ALL_COMPLETE" | "ANY_COMPLETE" | "QUORUM" | null, aggregation_quorum_n: | null, orchestrator_session_id: , orchestrator_mandate_jti: , cedar_result: "PERMIT", kernel_signature: } 7.3. CLUSTER_MEMBER_ADDED CLUSTER_MEMBER_ADDED { event_type: "CLUSTER_MEMBER_ADDED", event_id: , timestamp: , cluster_id: , so_uuid: , requesting_agent_id: , mandate_jti: , cedar_result: "PERMIT", kernel_signature: } 7.4. CLUSTER_MEMBER_REMOVED CLUSTER_MEMBER_REMOVED { event_type: "CLUSTER_MEMBER_REMOVED", event_id: , timestamp: , cluster_id: , so_uuid: , member_final_state: , requesting_agent_id: , mandate_jti: , cedar_result: "PERMIT", kernel_signature: } 7.5. CLUSTER_MERGED CLUSTER_MERGED { event_type: "CLUSTER_MERGED", event_id: , timestamp: , source_cluster_id_a: , source_cluster_id_b: , resulting_cluster_id: , membership_model: "STATIC" | "DYNAMIC", requesting_agent_id: , cedar_result: "PERMIT", kernel_signature: } 7.6. CLUSTER_SPLIT CLUSTER_SPLIT { event_type: "CLUSTER_SPLIT", event_id: , timestamp: , source_cluster_id: , resulting_cluster_id_a: , member_uuids_a: [ , ... ], resulting_cluster_id_b: , member_uuids_b: [ , ... ], requesting_agent_id: , cedar_result: "PERMIT", kernel_signature: } 7.7. CLUSTER_DISSOLVED CLUSTER_DISSOLVED { event_type: "CLUSTER_DISSOLVED", event_id: , timestamp: , cluster_id: , final_member_states: [ { so_uuid, final_state }, ... ], requesting_agent_id: , cedar_result: "PERMIT", kernel_signature: } 7.8. ProximityEvent: CLUSTER_MEMBER_REACHED_TERMINAL This ProximityEvent is fired when a cluster member SO reaches a terminal state. It is delivered to the orchestrator session per the ProximityEvent delivery semantics of draft-sato-soos-aep Section 7.3.2. ProximityEvent { condition_id: :, condition_type: "CLUSTER_MEMBER_REACHED_TERMINAL", current_value: , threshold_value: "TERMINAL", proximity_pct: 1.0, cluster_id: , so_uuid: , remaining_active_count: } 7.9. ProximityEvent: CLUSTER_AGGREGATION_CONDITION_MET This ProximityEvent is fired when the cluster's declared aggregation condition is first satisfied. ProximityEvent { condition_id: :AGGREGATION, condition_type: "CLUSTER_AGGREGATION_CONDITION_MET", current_value: , threshold_value: , proximity_pct: 1.0, cluster_id: , aggregation_rule: "ALL_COMPLETE" | "ANY_COMPLETE" | "QUORUM", satisfied_members: [ , ... ] } 8. Cedar Actions The following Cedar actions are introduced by this document. All actions MUST be registered in the SOOS Cedar namespace. SOOS::Action::CreateSovereignObject Required to call kernel.createSovereignObject(). Cedar evaluates against the SO Type's creation policy. SOOS::Action::DeclareCluster Required to call L1-16 declareCluster(). SOOS::Action::AddClusterMember Required to call L1-16 addClusterMember(). SOOS::Action::RemoveClusterMember Required to call L1-16 removeClusterMember(). SOOS::Action::MergeCluster Required to call L1-16 mergeCluster(). SOOS::Action::SplitCluster Required to call L1-16 splitCluster(). SOOS::Action::DissolveCluster Required to call L1-16 dissolveCluster(). 9. Conformance A conforming SOOS multi-agent implementation MUST satisfy all of the following requirements. Items marked REJECT cause the kernel to reject the triggering operation. CONF-MAD-01 A cluster MUST NOT be declared with zero members. (REJECT) CONF-MAD-02 A CLUSTER_MERGED event MUST record both source cluster IDs and the resulting cluster ID. (REJECT) CONF-MAD-03 A CLUSTER_SPLIT event MUST record the source cluster ID and both resulting cluster IDs. (REJECT) CONF-MAD-04 addClusterMember MUST be REJECTED on STATIC clusters. CONF-MAD-05 removeClusterMember MUST be REJECTED for members in non-TERMINAL states on STATIC clusters. CONF-MAD-06 CLUSTER_MEMBER_REACHED_TERMINAL MUST be delivered to all active sessions on the cluster before any subsequent SENSE delivery on the affected cluster. CONF-MAD-07 The orchestrator MUST explicitly call removeClusterMember before dissolveCluster if any members remain in non-TERMINAL states. (REJECT if non-TERMINAL members exist) CONF-MAD-08 The Cluster Registry MUST be rebuilt from the Event Log on kernel restart before processing any cluster queries. (REJECT cluster queries before rebuild is complete) CONF-MAD-09 cluster_context MUST be populated from the Cluster Registry before Cedar evaluation on any cluster member transition. CONF-MAD-10 dissolveCluster MUST be REJECTED if any cluster member SO is in non-TERMINAL state. CONF-MAD-11 Aggregation rule evaluation MUST use the Cluster Registry projection, not an Event Log scan. CONF-MAD-12 CLUSTER_AGGREGATION_CONDITION_MET MUST be delivered exactly once per cluster lifetime. CONF-MAD-13 QUORUM(n) where n exceeds the declared member count MUST be REJECTED at cluster declaration time. CONF-MAD-14 cluster_context in HEMContext MUST be populated from the Cluster Registry at HEM_INVOKED time. 10. Open Issues The following open questions are recorded for resolution in successor documents. 10.1. OQ-S-41: Cross-Principal SO Coordination When two SOs from separate Party Registry principals (or separate SOOS instances) represent the same real-world transaction -- for example, an operator's GuestStaySO and a traveler's TravelBookingSO -- no normative coordination protocol exists for: (a) Declaring the cross-principal relationship between the two SOs. (b) Propagating state change signals between principals without violating each principal's SO autonomy. (c) Handling disputes where the two SOs record conflicting versions of events for the same real-world transaction. (d) Coordinating Zone A data across principals without violating Zone A data residency requirements. This is a genuine architectural gap. OQ-S-41 is a prerequisite for cross-domain ATP deployment and for any multi-operator SOOS federation scenario. It constrains: Zone B cross-principal data sharing, GDPR cross-member accountability, and kernel multi-tenancy. OQ-S-41 is tracked as HIGH priority. It does not block v1 single- operator deployments. 10.2. OQ-S-43: Nested Clusters Whether a cluster of clusters (a cluster whose members are themselves cluster identifiers rather than SO instance identifiers) is a supported construct is unresolved. Nested clusters would support hierarchical multi-agent workflows with independent sub- workflow aggregation conditions. This is tracked as LOW priority and does not block v1. 10.3. OQ-S-44: Cluster-Scope Cedar Evaluation Whether Cedar evaluation at the cluster scope (evaluating a Cedar policy that directly references cluster-level state rather than individual SO state) is warranted in a successor document is unresolved. The cluster_context Cedar attribute (Section 5.5) provides a pragmatic interim mechanism. OQ-S-44 is a prerequisite for OQ-S-43. Tracked as LOW priority; does not block v1. 11. Security Considerations 11.1. Confused Deputy Attack at Delegation Hops The Narrowing Property (INV-4) structurally prevents authority amplification at each delegation hop. However, implementors MUST enforce INV-4 at mandate issuance time in the Party Registry, not only at evaluation time. An implementation that issues non-INV-4- compliant mandates and relies on Cedar evaluation alone to prevent authority amplification is non-conforming. 11.2. Cluster Scope as an Attack Surface Cluster declarations and membership changes are Cedar-evaluated. However, the cluster_context Cedar attribute injected per-transition (Section 5.5) creates a new input surface for Cedar policy evaluation. Implementors MUST ensure that cluster_context is populated exclusively from the kernel-maintained Cluster Registry and cannot be supplied or manipulated by agents. An agent that can inject cluster_context values can potentially bypass Cedar policies conditioned on cluster state. 11.3. Ghost Execution on Cluster Dissolution If an orchestrator mandate expires or is revoked while cluster members remain in non-TERMINAL states, the cluster may enter a state where no active agent has authority to dissolve it. The kernel MUST NOT automatically dissolve clusters. Operator intervention via a human-held Party Registry principal is required to dissolve clusters abandoned by their orchestrator. Implementations SHOULD provide an operator-accessible kernel.forceDissolveCluster() function requiring human-principal authority, for use in recovery scenarios. This function is out of scope for v1 and deferred to a successor document. 11.4. Cascade Revocation in Large Delegation Trees In workflows with deep delegation trees (orchestrator issuing to specialists who issue to sub-specialists), 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 kernel MUST add all listed jtis to the Revocation Registry atomically. 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, DOI 10.17487/RFC2119, March 1997, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SOOS-AEP] Sato, T., "Agent Execution Protocol", draft-sato-soos-aep-00, Work in Progress, May 2026. [SOOS-HEM] Sato, T., "Human Escalation Mechanism", draft-sato-soos-hem-01, Work in Progress, May 2026. [SOOS-KIA] Sato, T., "Kernel Identity and Attestation", draft-sato-soos-kia-00, Work in Progress, May 2026. [SOOS-MJWT] Sato, T., "Mandate JWT", draft-sato-soos-mjwt-00, May 2026. [SOOS-SOV] Sato, T., "Sovereign Object", draft-sato-soos-sov-00, May 2026. 14. Informative References [SOOS-IDP] Sato, T., "Intent Declaration Primitive", draft-sato-soos-idp-03, May 2026. [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. [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, Work in Progress, 2026. 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, each addressed by different working groups and individual submissions: o The credential/token layer: how authority is represented and presented (SPICE, OAuth, WIMSE). o The communication/session layer: how agents exchange messages and manage sessions (ACP, A2A). o The governance-state layer: what the enforcement environment guarantees happens to governed objects when an agent acts. MAD operates exclusively at the governance-state layer. No current IETF working group charter claims this layer as primary scope. The capability coverage matrix published in the IETF WG Charter Analysis (ACP / WIMSE / OAuth / WebBotAuth / AIPREF / DAWN, v0.01, 2026) confirms that policy enforcement is out-of-scope or partial for all six active and proposed agentic AI working groups. B.1. SPICE Actor Chain draft-mw-spice-actor-chain-05 [SPICE-ACTOR-CHAIN] defines a mechanism for preserving the delegation provenance of an agent action: which principals authorised which hops, in what sequence, with what disclosure profile (full chain, subset, or committed). MAD and SPICE actor-chain solve adjacent but distinct problems. SPICE answers: who was in the delegation chain and can you prove it? INV-4 answers: what was each hop in the chain permitted to cause? SPICE is attribution; INV-4 is constraint. Both are necessary for a complete multi-agent security architecture. A conforming SOOS orchestrator SHOULD include the mandate JWT fingerprint (SHA-256 of the mandate JWT) in the SPICE actor-chain for each delegation hop. This makes the SOOS mandate issuance tree (Section 3.2) directly traceable in cross-system audit contexts without requiring the verifying party to have access to the SOOS Party Registry. The delegation_chain JWT claim used in draft-sato-soos-idp-03 and draft-sato-soos-hem-01 follows the SPICE actor-chain profile and should be read in conjunction with this appendix. B.2. OAuth Attenuating Agent Tokens draft-niyikiza-oauth-attenuating-agent-tokens-00 [OAUTH-ATTENUATING] defines a mechanism for issuing attenuated tokens to sub-agents without requiring an Authorization Server round-trip at each delegation hop. The attenuated token carries a narrowed scope set derived from the parent token. This mechanism addresses the same authority-narrowing requirement as INV-4 but at the OAuth scope layer rather than the Cedar action layer. OAuth scopes are coarser than Cedar actions for the agentic context: a scope such as "booking:write" does not distinguish between confirming a booking and cancelling one, both of which a Cedar policy can express as distinct actions with distinct authority requirements. The two mechanisms are complementary. An agent system MAY use OAuth attenuating tokens at the API authentication layer while using SOOS mandate JWTs and INV-4 at the governance-state layer. The attenuating token gates API access; the mandate JWT and Cedar policy gate state transitions on Sovereign Objects. B.3. OAuth Transaction Tokens draft-ietf-oauth-transaction-tokens-08 [OAUTH-TXN-TOKENS] (Tulshibagwale, Fletcher, Kasselman) defines Transaction Tokens (Txn-Tokens): short-lived, signed JWTs that propagate user identity, workload identity, and authorisation context through the call graph within a trusted domain. Txn-Tokens address call graph identity propagation: ensuring that every service in a multi-service call chain knows who initiated the request and what authorisation context applies. MAD mandates address what state transitions each agent in that call chain is permitted to cause on governed objects. A SOOS agent SHOULD embed its mandate JWT fingerprint in the request_context field of a Txn-Token when making calls to external services. This gives the receiving service both the Txn-Token's identity chain and the Cedar action set the SOOS agent is operating under, enabling the receiving system to apply its own policy against the SOOS authority context without implementing the full SOOS kernel. draft-araut-oauth-transaction-tokens-for-agents-06 extends Txn- Tokens specifically for agent-based workloads using the act field for agent identity. This extension is directly compatible with the SOOS mandate JWT as the act claim source. B.4. Agent Communication Protocol (ACP) The Agent Communication Protocol (Proposed WG / BoF at IETF 126) defines the communication and session layer for agent-to-agent and agent-to-tool interaction: message formats, session management, capability negotiation, and long-lived multi-modal sessions. ACP has formally agreed to defer authentication to WIMSE and authorisation to OAuth. MAD occupies the governance-state layer that ACP's authorisation deferral leaves open. When an ACP message arrives at an agent, MAD governs what state transitions the receiving agent is permitted to cause on Sovereign Objects as a result of acting on that message. The relationship is compositional without overlap: ACP is the channel; MAD is the governance of what the channel causes in the state of governed objects. ACP's per-operation user confirmation requirement (primary scope in the ACP capability matrix) maps directly to SOOS HEM Class 1 (HEM_MANDATORY) trigger behaviour. B.5. A2A Protocol The Agent-to-Agent Protocol (Google) defines agent-to-agent coordination via Agent Cards, capability negotiation, and task hand-off. Agent Cards are self-asserted capability declarations with no cryptographic verifier in the loop in the base specification. The SO Type Registry defined in draft-sato-soos-sov provides the operator-side equivalent of discoverable capabilities: SO Type definitions are versioned, signed, and registry-governed. A SOOS SO Type Registry entry SHOULD be exportable as an A2A- compatible signed Agent Card, providing verifiable capability advertisement for the SOOS agent population. MAD's SO Cluster Manager (Section 5.6) provides governance primitives for the kind of multi-agent coordination A2A's task hand-off model requires, with the addition of kernel-enforced authority constraints and an append-only audit trail at each coordination step. B.6. AuthZEN 1.0 AuthZEN 1.0 (OpenID Foundation, January 2026) [AUTHZEN] defines the Policy Enforcement Point / Policy Decision Point (PEP/PDP) separation model: a standardised API for external policy decisions independent of the agent process. SOOS Cedar evaluation at the kernel layer is PEP/PDP separation enforced at the physics of the OS, not middleware: Cedar executes before XState on every transition (INV-3), and the evaluation is kernel-owned, not agent-owned. The AuthZEN model is the correct reference for how SOOS's Cedar enforcement layer relates to external policy infrastructure. An implementation MAY expose the SOOS Cedar evaluation result via an AuthZEN-compatible API surface for consumption by external systems that need to reason about SOOS-governed agent authority without implementing the full SOOS kernel. B.7. SOOS Companion Drafts This document is one of nine SOOS IETF individual submissions. The full stack is: draft-sato-soos-idp-03 Intent Declaration Primitive. Per-transition agent reasoning record. The IDP is the audit artifact that MAD's mandate and cluster events accompany. draft-sato-soos-hem-01 Human Escalation Mechanism. Integrates with MAD via HEMContext cluster_context extension (Section 5.8.3). draft-sato-soos-gar-01 Governance Audit Record. The SCITT-integrated audit layer for all events defined in Section 7 of this document. draft-sato-soos-cap-00 Constitutional AI Protocol. Tier 0 and Tier 1 prohibitions enforced before Cedar. Applies to all agents in all topologies defined in Section 4. draft-sato-soos-sov-00 Sovereign Object. Defines the SO lifecycle model, five-phase structure, and Zone A/B boundary that all cluster members in Section 5 are instances of. draft-sato-soos-mjwt-00 Mandate JWT. Defines the credential format that INV-4 (Section 3.1) and the mandate issuance tree (Section 3.2) operate on. draft-sato-soos-aep-00 Agent Execution Protocol. Defines the per-agent SENSE/REASON/PLAN/ ACT/OBSERVE loop within which MAD cluster operations occur. draft-sato-soos-kia-00 Kernel Identity and Attestation. Defines the keypair and signing authority for all kernel events in Section 7. draft-sato-soos-pt-00 Progressive Trust. Provides per-agent behavioural trust scores used in HEMContext to inform human decisions about multi-agent workflow escalations. draft-sato-soos-faip-00 Federated Agent Intelligence Protocol. Aggregates behavioural intelligence from MAD cluster execution records across operators, providing ecosystem-level insight into multi-agent workflow patterns. 15. 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 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. Author's Address Tom Sato MyAuberge K.K. Chino, Nagano, Japan Email: tomsato@myauberge.jp URI: https://activitytravel.pro/