Multi-Agent Delegation in Sovereign Object Systems
draft-sato-soos-mad-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tom Sato | ||
| Last updated | 2026-09-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Additional Web Page
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sato-soos-mad-04
Internet Engineering Task Force T. Sato
Internet-Draft MyAuberge K.K.
Intended Status: Standards Track 4 September 2026
Expires: 4 March 2027
Multi-Agent Delegation in Sovereign Object Systems
draft-sato-soos-mad-04
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?
This document defines the Multi-Agent Delegation (MAD) protocol,
extended in version -03 with four new normative mechanisms: the
Sub-Agent Composition Record (SACR) for kernel-governed sub-agent
spawning; the hub-only constraint for sub-agent communication
topology; XPID cross-cluster integration derived from KIA-03; and
full normative specifications for the R-1 through R-7 revocation
trigger classes with completion states and cascade behavior.
Version -04 adds an eighth trigger class, R-8 (Compromise), closing
a gap identified while mapping MAD's taxonomy onto the Mandate
Lifecycle Events (MLE) profile's `reason: compromise` value, which
had no R-code counterpart.
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. SACR means the spawning of that tree is itself governed.
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 4 March 2027.
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 (UPDATED in -03)
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
4. Sub-Agent Composition Record (SACR) (NEW in -03)
4.1. Purpose and Design
4.2. SACR Schema
4.3. SACR Issuance Procedure
4.4. SACR Kernel Events
5. Hub-Only Constraint (NEW in -03)
5.1. Normative Requirement
5.2. Hub-Only Override
5.3. Hub-Only Enforcement
6. XPID Cross-Cluster Integration (NEW in -03)
6.1. Sub-Agent XPID Derivation
6.2. Cross-Cluster XPID Verification
6.3. XPID in Delegation Audit Records
7. Revocation Trigger Classes R-1 through R-8 (UPDATED in -04)
7.1. R-1: CAP Tier 0-A Violation
7.2. R-2: Scope Boundary
7.3. R-3: Non-Response
7.4. R-4: Irreversible Threshold
7.5. R-5: Scheduled Rotation
7.6. R-6: Operator Override
7.7. R-7: DEADLOCK
7.8. R-8: Compromise
7.9. Completion State Matrix
7.10. Cascade Behavior by Trigger
8. SO Instance Topology Types
9. SO Cluster Coordination
10. Orchestrator-Specialist Model
11. Kernel Events (UPDATED in -03)
12. Cedar Actions (UPDATED in -03)
13. Conformance (UPDATED in -03)
14. Open Issues
15. Security Considerations (UPDATED in -04)
16. IANA Considerations (UPDATED in -03)
17. Normative References (UPDATED in -03)
18. Informative References
Appendix B. Related Work
Appendix C. Vibe Coding Assets (UPDATED in -03)
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 [SOOS-AEP] (Agent Execution Protocol), which defines
the per-agent execution loop; [SOOS-SOV] (Sovereign
Object), which defines the SO structure and lifecycle;
[SOOS-MJWT] (Mandate JWT), which defines the delegation
credential format; and [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 [SOOS-IDP] provides
the per-transition audit artifact at each delegation hop; HEM
[SOOS-HEM] is the escalation mechanism when a hop
requires human judgment; GAR [SOOS-GAR] is the permanent
audit record for the full workflow; CAP [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", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in
all capitals, as shown here.
(RECONSTRUCTED in -04: the text above is carried forward from
draft-sato-soos-mad-02 Section 1; -03 carried only a bracket
placeholder. The addition below is -03's own new material,
unchanged.)
Version -03 adds four new normative mechanisms:
(1) Sub-Agent Composition Record (SACR, Section 4): the kernel-
governed primitive for sub-agent spawning. DR-SPAWN-01
identified the gap -- MAD governed what a sub-agent was
authorized to do once it existed, but specified no mechanism
for how it came into existence. SACR closes this gap:
the kernel witnesses every sub-agent composition event,
issues an ephemeral KIA reference, and records the
tool-subset invariant at spawn time.
(2) Hub-Only Constraint (Section 5): a normative requirement
derived from DR-SPAWN-01 OQ-SPAWN-06 resolution. Sub-agents
spawned from a hub MUST NOT communicate with each other
directly; all coordination routes through the hub. This
closes the audit-trail and re-planning-authority gaps
that direct sub-agent messaging would create.
(3) XPID Cross-Cluster Integration (Section 6): integration of
the Cross-Principal Identifier from the current [SOOS-KIA]
into MAD's delegation audit model. Sub-agent XPIDs
are derived from parent XPID + session nonce, providing
stable cross-cluster correlation without a trusted third
party.
(4) Full normative specifications for the R-1 through R-7
revocation trigger classes (Section 7), including complete
completion state matrices and cascade behavior per trigger.
The R-1 through R-7 taxonomy was introduced in MAD-02 but
lacked per-trigger normative depth.
Further information: https://soosproject.ai/drafts/mad
2. Terminology (UPDATED in -03)
The following terms are used in this document. Terms defined in
[SOOS-SOV] and [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 [RFC7519] 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.
(RECONSTRUCTED in -04: the terms above are carried forward from
draft-sato-soos-mad-02 Section 2; -03 carried only a bracket
placeholder. The additions below are -03's own new terms,
unchanged.)
SACR (Sub-Agent Composition Record):
The kernel-issued record that governs the spawning of a new
sub-agent under Mechanism B (runtime instantiation, as
defined in DR-SPAWN-01 Section 2.2). The SACR captures the
composition event: the ephemeral identity issued, the tool
subset granted, the parent mandate reference, and the scope
constraints applied. Distinct from Assignment (which governs
what the sub-agent may do once it exists): SACR governs how
the sub-agent comes to exist. See Section 4.
Ephemeral KIA Reference (ephemeral_kia_ref):
A session-scoped identity issued by the GEC at SACR issuance
for a sub-agent instantiated under Mechanism B. The ephemeral
KIA reference is valid only for the duration of the spawned
sub-agent's session and is retired when that session closes.
It is not a persistent Party Registry entry.
Hub-Only Mode:
The normative default communication model for sub-agents
spawned from a hub orchestrator. In hub-only mode, all
cross-sub-agent coordination MUST route through the hub;
direct sub-agent to sub-agent communication is prohibited.
See Section 5.
XPID (Cross-Principal Identifier):
Defined in [SOOS-KIA] Section 6. In MAD-03, XPIDs
are used for sub-agent identity correlation across cluster
boundaries. Sub-agent XPIDs are derived from the parent
XPID + session nonce per Section 6.1.
max_spawn_depth:
An integer field in the SACR that strictly decrements at each
recursive sub-agent spawn. A sub-agent with max_spawn_depth:
0 is a leaf and MUST NOT spawn further sub-agents. A parent
MUST NOT issue a SACR granting max_spawn_depth greater than
(parent's own max_spawn_depth - 1). See Section 4.2.
can_decompose:
A boolean field in the SACR indicating whether the spawned
sub-agent may itself decompose its sub-goal and spawn further
children. Default: false. max_spawn_depth: 0 implies
can_decompose: false regardless of the field value.
Mechanism A / Mechanism B:
Two sub-agent spawning mechanisms identified in DR-SPAWN-01.
Mechanism A: delegation to an already-existing, independently-
deployed agent. Mechanism B: runtime instantiation of a wholly
new agent via SACR. Both mechanisms produce Assignment records
per DR-PLAN-01; only Mechanism B produces a SACR.
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 (a MAD-defined field on the
MANDATE_REVOCATION_ISSUED (Section 7.10) and SESSION_REVOKED_BY_
OPERATOR (Section 11) events; the underlying per-jti cascade
mechanism this scope triggers is specified in draft-sato-soos-mjwt
Section 7.2 and 7.3, whose MANDATE_REVOKED Event Stream entries
record each resulting revocation as revocation_type: "CASCADE"
with a cascade_root_jti pointing back to this mandate's jti), 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 Section 3.6)
for the
revocation procedure. Implementations MUST treat MAD Section
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, [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, R-8. 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 [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 [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 ([SOOS-AEP] Section 4.2). Actions
classified as irreversible are declared in the IDP intent record
([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-8)
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-8.
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).
R-8 -- Compromise
A mandate or the credential presented under it is believed
compromised due to a suspected or confirmed external attack
(e.g. key material exposure, credential theft, a KIA
attestation failure indicating the agent's runtime identity no
longer matches its attested state). Distinct from R-1: a
compromise is a security incident against the mandate's
integrity, not a violation of the constitutional bounds the
mandate itself grants. Revocation is immediate and
unconditional. 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 or R-8.
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-7. 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.
DEADLOCK state:
Entry condition: circular resource dependency across two or
more sessions, detected by the cluster coordinator.
Exit -- resolved: transitions to ACTIVE on a resolution
mandate with Cedar PERMIT for Action::"ResolveDeadlock".
Exit -- timeout: REVOKED under R-7 after deadlock_timeout.
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 [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, R-8):
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-8).
(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 [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 [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-8. 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.
(RECONSTRUCTED in -04: Sections 3.1 through 3.9 above are the
actual text carried forward from draft-sato-soos-mad-02 Section 3,
reproduced in full per the WIMSE Security Review's standing
reconstruction rule -- -03's text for this entire section was a
bracket note claiming full carry-forward with no body text at
all. Section 3.6.4's high-level R-1 through R-7 taxonomy is
unchanged from MAD-02; full normative per-trigger specifications
remain in Section 7 of this document. R-8 (Section 3.6.4) is new
normative material added directly in this -04 revision, not part
of the MAD-02 carry-forward described here.)
4. Sub-Agent Composition Record (SACR) (NEW in -03)
4.1. Purpose and Design
The SACR is the kernel-governed record of a sub-agent spawning
event under Mechanism B (runtime instantiation). Its design
derives from [DR-SPAWN-01] (June 19, 2026), which identified the
following gap in MAD-02:
MAD-02 fully specifies what a sub-agent may do once it exists
(Assignment, INV-4 Narrowing Property, DEADLOCK detection,
cascade revocation). It does not specify how the sub-agent
comes into existence. Assignment assumes assigned_agent_id
resolves to a known, attested identity. For Mechanism B
sub-agents (runtime instantiation), no such identity exists
before the spawn event.
The SACR fills this gap by providing a kernel-witnessed record of:
(a) The composition event itself (spawning principal, spawned
identity, scope constraints applied).
(b) The tool-subset invariant check at spawn time: the spawned
sub-agent's tool access MUST be a subset of the spawning
agent's own tool access at composition time.
(c) The ephemeral KIA reference scoped to the sub-agent's session.
(d) The spawn-depth governance: max_spawn_depth strictly
decrements per recursion level.
The kernel-mediated spawn model is the normative approach: SACR
issuance is a GEC operation, not an agent-to-agent call. This is
the only model consistent with the SOOS OS/application boundary
(DEC-PLAN-13) and the only one where SACR issuance has an
unambiguous issuer.
SACR and Assignment are sequential, not redundant:
- SACR governs how the sub-agent comes to exist.
- Assignment governs what the now-existing sub-agent may do.
Assignment's assigned_agent_id normatively resolves to either:
(a) A persistent Party Registry identity (Mechanism A), or
(b) A SACR-issued ephemeral_kia_ref (Mechanism B).
4.2. SACR Schema
{
"sacr_id": string, ; REQUIRED. UUID v4. Primary
; key for this composition
; record.
"parent_assignment_id": string, ; REQUIRED. The Assignment
; record ID that authorized
; this spawn. Cross-
; references DR-PLAN-01
; S.5.4 schema.
"parent_session_id": string, ; REQUIRED. The spawning agent's
; session_id.
"parent_mandate_id": string, ; REQUIRED. MJWT jti of the
; spawning agent's mandate.
"parent_xpid": string, ; REQUIRED. The spawning agent's
; XPID (see Section 6.1).
; Used for ephemeral XPID
; derivation.
"ephemeral_kia_ref": string, ; REQUIRED. The ephemeral
; identity issued by the GEC
; for this sub-agent session.
; Format: UUID v4, GEC-
; generated. Valid only for
; this session's duration.
; Not a persistent Party
; Registry entry.
"scope_constraints": { ; REQUIRED.
"cedar_action_subset": string[], ; REQUIRED. The Cedar actions
; granted to the spawned
; sub-agent. MUST be a
; strict subset of the
; spawning agent's own
; action set at spawn time.
; Verified by the GEC at
; issuance.
"so_type_scope": string[], ; REQUIRED. SO Types the
; sub-agent may act on.
; MUST be a subset of the
; parent's SO type scope.
"resource_envelope": object, ; REQUIRED. Compute/memory/
; time budget allocated.
; MUST NOT exceed the
; parent's remaining resource
; envelope.
"tool_subset": string[], ; REQUIRED. Tools accessible
; to the sub-agent. MUST be
; a subset of the parent's
; tool access at composition
; time (DR-SPAWN-01 S.5.1
; tool-subset invariant).
"temporal_scope": object ; OPTIONAL. not_before /
; not_after bounds for this
; sub-agent session.
},
"can_decompose": boolean, ; REQUIRED. May this sub-agent
; spawn further sub-agents?
; Default: false (most
; restrictive). MUST be
; false when max_spawn_depth
; is 0.
"max_spawn_depth": integer, ; REQUIRED. Strictly
; decrements at each
; recursive spawn. Parent
; MUST NOT grant a value
; greater than (parent's
; own max_spawn_depth - 1).
; Value 0: leaf agent,
; cannot spawn. MUST be
; >= 0.
"hub_only": boolean, ; REQUIRED. Whether this
; sub-agent is restricted to
; hub-only mode (Section 5).
; Default: true. Direct
; sub-agent communication is
; only permitted when
; hub_only: false AND an
; explicit Cedar PERMIT on
; Action::
; "DirectSubAgentComm"
; exists.
"replan_authority": string, ; REQUIRED. Values:
; NONE: execute assigned plan
; exactly; no deviation.
; BOUNDED: may deviate within
; declared bounds; must
; surface deviations via
; HEM-DIV-1.
; AUTONOMOUS: may replan
; independently; must
; record
; replan rationale in GAR.
; Default: NONE.
"composition_timestamp": string, ; REQUIRED. ISO 8601 UTC.
"sacr_signature": string ; REQUIRED. GEC Ed25519
; signature over canonical
; JSON of all
; preceding fields (excluding
; sacr_signature itself).
}
4.3. SACR Issuance Procedure
The SACR issuance procedure is kernel-mediated. No agent may
directly call a SACR issuance operation; the request MUST flow
through the GEC.
Step 1 -- Spawn request validation.
The GEC receives a spawn request from the spawning agent
(via the gec.spawnSubAgent() call). The request MUST include
the proposed scope_constraints, tool_subset, can_decompose,
max_spawn_depth, and replan_authority values.
Step 2 -- Tool-subset invariant check.
The GEC MUST verify that the requested tool_subset is a strict
subset of the spawning agent's currently authorized tool access.
A tool_subset that is not a subset of the parent's access MUST
cause the GEC to REJECT the spawn request and emit
ALE-SPAWN-03 (TOOL_SUBSET_VIOLATION).
Step 3 -- Spawn-depth invariant check.
The GEC MUST verify that the requested max_spawn_depth is not
greater than (spawning agent's own max_spawn_depth - 1). A
request that would result in a negative max_spawn_depth MUST
be REJECTED and ALE-SPAWN-02 (SPAWN_DEPTH_EXCEEDED) emitted.
Step 4 -- Cedar action subset check.
The GEC MUST verify that the requested cedar_action_subset is
a strict subset of the spawning agent's own Cedar action set
(INV-4 Narrowing Property). A violation MUST cause REJECTION
with MANDATE_NARROWING_VIOLATION.
Step 5 -- Ephemeral identity issuance.
On all checks passing, the GEC issues the ephemeral_kia_ref
(a UUID v4 scoped to this session's lifetime) and derives the
sub-agent's XPID per Section 6.1.
Step 6 -- SACR signing and recording.
The GEC constructs the SACR, signs it with the GEC keypair
(INV-9), and commits ALE-SPAWN-01 (SUB_AGENT_COMPOSED) to GAR.
Step 7 -- Assignment linkage.
The GEC notifies the spawning agent that the sub-agent is
ready, providing the sacr_id and ephemeral_kia_ref. The
spawning agent then issues an Assignment per DR-PLAN-01 S.5.4,
using ephemeral_kia_ref as the assigned_agent_id.
CONF-MAD-SACR-01: The GEC MUST complete all five validation
steps before issuing the ephemeral_kia_ref. Partial validation
followed by SACR issuance is a conformance violation.
CONF-MAD-SACR-02: A SACR MUST be committed to GAR (ALE-SPAWN-01)
before the sub-agent begins execution. Sub-agent execution without
a prior committed SACR is a conformance violation detectable via
GAR audit.
CONF-MAD-SACR-03: The tool_subset in the SACR MUST be enforced
at runtime. The sub-agent MUST NOT access tools not listed in
its sacr.scope_constraints.tool_subset. The GEC MUST enforce
this at each gec.transition() call for the sub-agent session.
4.4. SACR Kernel Events
The following kernel events are introduced for SACR lifecycle
management. All events MUST be signed by the KIA keypair (INV-9).
ALE-SPAWN-01: SUB_AGENT_COMPOSED
Emitted by the GEC when a SACR is issued and the ephemeral
sub-agent identity is created. Required fields:
sacr_id, parent_assignment_id, parent_session_id,
parent_mandate_id, ephemeral_kia_ref, can_decompose,
max_spawn_depth, hub_only, replan_authority,
composition_timestamp, gec_signature.
ALE-SPAWN-02: SPAWN_DEPTH_EXCEEDED
Emitted when a spawn request is rejected because the requested
max_spawn_depth would exceed the parent's own max_spawn_depth
minus 1. Required fields: requesting_session_id,
requesting_mandate_id, requested_depth, parent_max_depth,
rejection_reason, gec_signature.
ALE-SPAWN-03: TOOL_SUBSET_VIOLATION
Emitted when a spawn request is rejected because the requested
tool_subset is not a subset of the parent's tool access.
Required fields: requesting_session_id, requesting_mandate_id,
requested_tools (array), parent_tools (array),
violating_tools (array -- tools requested but not held by
parent), rejection_reason, gec_signature.
ALE-SPAWN-04: EPHEMERAL_IDENTITY_EXPIRED
Emitted when the spawned sub-agent's session closes and the
ephemeral_kia_ref is retired. Required fields: sacr_id,
ephemeral_kia_ref, session_id, completion_state, expired_at,
gec_signature.
5. Hub-Only Constraint (NEW in -03)
5.1. Normative Requirement
Sub-agents spawned from a hub orchestrator MUST operate in hub-
only mode by default. Hub-only mode means:
CONF-MAD-HUB-01: A sub-agent with hub_only: true in its SACR
MUST NOT send messages, state updates, or coordination signals
directly to any sibling sub-agent. All cross-sub-agent
coordination MUST route through the hub orchestrator.
CONF-MAD-HUB-02: The GEC MUST enforce hub-only mode at the
Cedar layer. A gec.transition() call from a hub_only: true
sub-agent session that would write to a Zone A Sovereign Object
controlled by a sibling session MUST be evaluated against the
INV-17 horizontal non-contamination Cedar policy (MAD-02
Section 3.7.1).
CONF-MAD-HUB-03: The GEC MUST NOT accept a direct sub-agent
to sub-agent communication call (Action::"DirectSubAgentComm")
from a session with hub_only: true. The GEC MUST return
HUB_ONLY_VIOLATION and emit the violation to GAR.
Design rationale (from DR-SPAWN-01 OQ-SPAWN-06 resolution):
Hub-only is the only communication model consistent with:
(a) DEC-PLAN-13 (the kernel governs state, traversal, and
enforcement -- a direct, ungoverned sub-agent link bypasses
this);
(b) DEC-PLAN-11 (Mission Status SO as kernel-maintained live
state -- direct sub-agent communication would produce state
changes invisible to the Mission Status SO);
(c) Horizontal non-contamination (INV-17) -- the existing DAG
dependency types (SEQUENTIAL, PARALLEL, CONDITIONAL; see
[SOOS-AOP] Section 7.2, the authoritative definition) already
model required data flow between sub-goals without requiring
direct sub-agent messaging.
The hub-only constraint does not prevent high-bandwidth
coordination within a hub-orchestrated cluster. It requires
that coordination route through the kernel-governed hub, where
it can be Cedar-evaluated, GAR-recorded, and INV-17-enforced.
5.2. Hub-Only Override
The hub_only constraint MAY be overridden in a SACR when
all of the following conditions are met:
(a) The SACR carries hub_only: false.
(b) The spawning agent's own SACR (or initial mandate) also
carried hub_only: false, or the spawning agent is the
cluster coordinator.
(c) An explicit Cedar PERMIT exists for
Action::"DirectSubAgentComm" in the active policy set,
scoped to the specific sub-agent pair and the specific
communication content type.
(d) The communication is recorded in GAR with a
DIRECT_COMM_PERMITTED event before the first direct
message is sent.
CONF-MAD-HUB-04: hub_only: false in a SACR issued by a
hub_only: true parent is a conformance violation UNLESS the
conditions (a) through (d) above are satisfied (including the
cluster-coordinator case in (b)). The GEC MUST reject SACR
issuance under any other circumstance with
HUB_OVERRIDE_NOT_PERMITTED. (CORRECTED in -04: -03's text
stated this rule independently of the conditions above, with
no coordinator exception, making condition (b)'s
cluster-coordinator clause permanently unreachable under a
literal reading -- see the WIMSE Security Review's Stage
1/Stage 2 findings for -03.)
5.3. Hub-Only Enforcement
The GEC enforces hub-only mode through two mechanisms:
(a) Cedar policy evaluation: INV-17 (horizontal non-
contamination) prevents cross-session Zone A access.
The hub_only: true flag in the SACR is injected as a
Cedar context attribute (context.hub_only_active) on
every gec.transition() call for the sub-agent session.
(b) SACR registry: the GEC maintains a SACR Registry (a
kernel-internal lookup of active SACRs by session_id)
to enforce hub_only at direct-communication call time
without requiring Cedar evaluation for every communication
attempt.
Recursive hub-only: when can_decompose: true and the spawned
sub-agent itself spawns children, the hub_only constraint of
the grandchild MUST NOT be less restrictive than the child's
own hub_only value. A hub_only: true child MUST NOT spawn
hub_only: false grandchildren.
GAR events for hub-only violations:
HUB_ONLY_VIOLATION
Emitted when a hub_only: true sub-agent attempts direct
communication with a sibling. Required fields: session_id,
sacr_id, target_session_id, attempted_action, gec_signature.
6. XPID Cross-Cluster Integration (NEW in -03)
6.1. Sub-Agent XPID Derivation
Every sub-agent session instantiated under Mechanism B MUST
be assigned an XPID derived from the parent agent's XPID and
the sub-agent's session nonce.
Derivation procedure:
sub_agent_xpid = UUID5(KIA_XPID_NAMESPACE,
parent_xpid + ":" + sacr_id)
where:
KIA_XPID_NAMESPACE is the KIA XPID namespace UUID currently
defined in [SOOS-KIA] Section 6.2. (CORRECTED in -04: -03
hardcoded this document's own copy of the namespace UUID
value, which had gone stale as of KIA-06 -- KIA-06 minted a
dedicated namespace UUID under RFC 9562 Section 6.5, replacing
the standard DNS namespace UUID -03 was still citing. MAD
references the constant symbolically for exactly this reason:
a value copied here can silently drift from the source of
truth.)
parent_xpid is the XPID of the spawning agent session, as
recorded in the parent agent's Party Registry entry or SACR.
sacr_id is the UUID v4 of the SACR issued for this sub-agent
(Section 4.2), which is unique per spawning event.
Properties of this derivation:
(a) Deterministic: any party with the parent XPID and sacr_id
can compute the sub-agent XPID.
(b) Traceable: the sub-agent XPID encodes its lineage -- it
can be traced back to the root XPID by following the SACR
chain.
(c) Non-forgeable without SACR chain: an attacker cannot
claim a specific sub-agent XPID without knowledge of
the full SACR chain from the root.
CONF-MAD-XPID-01: The GEC MUST derive and record the sub-agent
XPID at SACR issuance time. The sub-agent XPID MUST appear in
ALE-SPAWN-01 and in every subsequent GAR governance span for
the sub-agent session, as the soos.governance.xpid attribute.
6.2. Cross-Cluster XPID Verification
When a receiving GEC instance encounters a sub-agent XPID from
a delegation tree originating in a different GEC instance:
(a) The receiving GEC MUST obtain the SACR for the sub-agent
session from the presenting GEC's SACR Registry via the
federation channel.
(b) The receiving GEC MUST obtain the parent agent's XPID from
the SACR's parent_xpid field.
(c) The receiving GEC MUST recompute the sub-agent XPID using
the derivation in Section 6.1 and verify it matches the
received XPID.
(d) A XPID that does not verify MUST cause the receiving GEC
to emit XPID_VERIFICATION_FAILED (as defined in
[SOOS-KIA] Section 16) and to treat the cross-
cluster event as invalid.
CONF-MAD-XPID-02: Cross-cluster sub-agent XPID verification
MUST complete before the receiving GEC accepts any governance
events from the sub-agent session.
6.3. XPID in Delegation Audit Records
The sub-agent XPID MUST appear in:
(a) ALE-SPAWN-01 (SUB_AGENT_COMPOSED): the sacr_xpid field
records the derived sub-agent XPID at composition time.
(b) ALE-013 (DELEGATION_INITIATED): the sub_agent_xpid field
for the sub-agent session.
(c) ALE-014 (DELEGATION_COMPLETED) and ALE-015
(DELEGATION_FAILED): the sub_agent_xpid field.
(d) Every GAR governance span for the sub-agent session, as
the soos.governance.xpid OTel attribute per [SOOS-GAR]
Section 5.
The XPID chain from root to leaf sub-agent is the audit
correlation primitive for reconstructing the full delegation
tree across GEC instance boundaries.
7. Revocation Trigger Classes R-1 through R-8 (UPDATED in -04)
The revocation trigger taxonomy introduced in MAD-02 Section
3.6.4 is carried forward. This section adds full normative
per-trigger specifications that were deferred in MAD-02.
7.1. R-1: CAP Tier 0-A Violation
Trigger condition: A CAP constitutional prohibition (Tier 0-A
per [SOOS-CAP] Section 7.2) has been violated or
imminently threatened by the agent session.
GEC behavior on detection:
(a) The GEC MUST immediately halt the session without
completing any in-progress transition. No CLEAN exit
is available for R-1.
(b) The GEC MUST add the mandate JWT jti to the Revocation
Registry atomically with halting.
(c) The GEC MUST emit a CONSTITUTIONAL_VIOLATION event to GAR
with violation_class and tier fields populated.
(d) The GEC MUST cascade revocation to all descendant mandates
in the issuance tree (CASCADE_TO_DESCENDANTS, Section 3.5).
(e) The GEC MUST route to HEM_TIER0_OBSERVED escalation
(HEM Class 6) for the highest-authority principal.
Completion state:
PARTIAL always. INV-15: UNKNOWN is treated as PARTIAL.
R-1 never produces CLEAN completion.
Continuation mandate authority:
Human principal MUST reauthorize. The operator MUST NOT
issue a continuation mandate for R-1 without explicit human
principal approval. GAR MUST record CONTINUATION_AWAITING_
PRINCIPAL until the principal issues the continuation mandate.
Cascade behavior:
Full CASCADE_TO_DESCENDANTS. All descendant sessions are
simultaneously terminated. The cascade is atomic at the
Revocation Registry layer.
SACR implications for R-1:
All SACRs issued by the revoked session (and by its
descendants) are voided at the same time. All ephemeral
KIA references issued under those SACRs MUST be retired
immediately. The GEC MUST emit ALE-SPAWN-04 (EPHEMERAL_
IDENTITY_EXPIRED) for each retired ephemeral identity with
completion_state: PARTIAL.
7.2. R-2: Scope Boundary
Trigger condition: The agent has attempted or is imminently
about to attempt an action outside its mandate scope. This
includes INV-4 violations detected at execution time (the
action is not in the agent's Cedar action set) and mandate
scope violations detected by Cedar DENY on
Action::"MandateScopeCheck".
GEC behavior on detection:
(a) The GEC MUST halt the session at the point of the
attempted out-of-scope action.
(b) The GEC MUST record the Cedar DENY result with the
out-of-scope action identifier in the SCOPE_BOUNDARY_
VIOLATION event in GAR.
(c) The GEC MUST cascade revocation to all descendant mandates.
(d) The GEC MUST route to HEM Class 1 (HEM_CEDAR_ROUTED)
escalation.
Completion state:
CLEAN if the out-of-scope action was detected before
execution (Cedar DENY at Step 1). PARTIAL if the
detection occurred during execution or after an irreversible
action had already been taken. UNKNOWN if the GEC cannot
determine execution state at detection time.
Continuation mandate authority:
Human principal MUST reauthorize.
Cascade behavior:
Full CASCADE_TO_DESCENDANTS.
7.3. R-3: Non-Response
Trigger condition: The agent session has failed to respond to a
governance signal (revocation propagation, HEM escalation, or
cascade timeout) within the required window. The cascade_timeout
period (Section 3.6.2) has elapsed without receipt of a
revocation acknowledgment or HEM response.
GEC behavior on detection:
(a) The GEC MUST emit CASCADE_TIMEOUT_REVOCATION for the
non-responsive session.
(b) The GEC MUST record completion_state: UNKNOWN for the
session, as the GEC cannot determine the session's
actual state.
(c) The GEC MUST NOT cascade to descendant sessions solely
on R-3 grounds: descendant sessions that ARE responsive
MUST be individually evaluated and revoked only if their
parent session's revocation makes them without authority.
Completion state:
UNKNOWN always for the non-responsive session.
UNKNOWN is treated as PARTIAL per INV-15.
Continuation mandate authority:
Operator MAY issue continuation mandate. Operator MUST
notify the human principal within principal_notification_
timeout (default 300 seconds). The principal MAY revoke
the continuation mandate within that window.
Cascade behavior:
Selective. Responsive descendant sessions continue until
their own mandate authority chain is evaluated.
7.4. R-4: Irreversible Threshold
Trigger condition: The agent has reached or is about to exceed
an irreversible action threshold declared in the mandate or SO
Type. This may fire before (anticipatory detection via
IDP declared intent) or at the moment of an irreversible
action.
GEC behavior on detection:
(a) The GEC MUST fire HEM Class 4 (HEM_CEDAR_ROUTED with
irreversibility context) before the irreversible action
executes, where anticipatory detection has occurred.
(b) Where detection occurs at execution time (not
anticipatory), the GEC MUST halt immediately without
completing the action.
(c) The GEC MUST emit IRREVERSIBLE_THRESHOLD_REACHED in GAR
with the action identifier, the mandate's declared
threshold value, and the current count.
Completion state:
CLEAN if halted before the irreversible action.
PARTIAL if halted after one or more irreversible actions
have been taken but mission is incomplete.
Continuation mandate authority:
Human principal MUST reauthorize.
Cascade behavior:
Full CASCADE_TO_DESCENDANTS.
7.5. R-5: Scheduled Rotation
Trigger condition: The agent session is being revoked as part
of a planned rotation or maintenance operation declared in
the cluster MJWT or operator configuration.
GEC behavior on detection:
(a) The GEC MUST wait for the next natural breakpoint before
revoking the session, where feasible and where the
rotation schedule permits. CONF-MAD-R5-01: A GEC MUST
NOT revoke an R-5 session mid-transition.
(b) The GEC MUST emit SCHEDULED_ROTATION_INITIATED in GAR
with the rotation_schedule_id.
Completion state:
CLEAN when natural breakpoint is reached before revocation.
PARTIAL when the rotation schedule does not permit waiting.
Continuation mandate authority:
Operator MAY issue continuation mandate (new session with
rotated identity). Human principal notification is
RECOMMENDED but not REQUIRED for R-5.
Cascade behavior:
None. R-5 applies to the specified session only.
Descendant sessions continue under their own mandates
unless separately revoked.
7.6. R-6: Operator Override
Trigger condition: An operator has explicitly revoked the
agent session via an operator-issued MANDATE_REVOCATION_ISSUED
event.
GEC behavior on detection:
(a) The GEC MUST halt the session on receipt of the
revocation signal, completing any atomic operation
already in progress.
(b) The GEC MUST emit SESSION_REVOKED_BY_OPERATOR in GAR.
(c) Cascade to descendants is operator-specified:
CASCADE_TO_DESCENDANTS or THIS_MANDATE_ONLY per the
revocation scope in MANDATE_REVOCATION_ISSUED.
Completion state:
CLEAN if halted at a natural breakpoint.
PARTIAL if halted mid-mission with irreversible actions
taken.
Continuation mandate authority:
Operator MAY issue continuation mandate. Human principal
notification is REQUIRED within principal_notification_
timeout.
Cascade behavior:
As specified in revocation_scope field.
7.7. R-7: DEADLOCK
Trigger condition: The cluster coordinator has detected a
DEADLOCK condition per Section 3.6.5. Two or more agent
sessions hold exclusive resource locks such that no session
can make progress without acquiring a lock held by another
session in the same cluster.
GEC behavior on detection:
(a) The cluster coordinator MUST simultaneously suspend all
participating sessions.
(b) The GEC MUST emit HEM_MULTI_PRINCIPAL_REQUIRED.
(c) The GEC MUST route to a human arbitrator.
(d) The GEC MUST record DEADLOCK_DETECTED in GAR citing
all participating session_id values, contested so_id
values, and mandate_id values.
(e) On deadlock_timeout expiry, all DEADLOCK-suspended
sessions MUST be auto-revoked under R-7 with
DEADLOCK_TIMEOUT_REVOCATION per session.
Completion state:
UNKNOWN always for DEADLOCK-suspended sessions.
Continuation mandate authority:
Human principal MUST reauthorize. On successful human
resolution, GAR MUST record DEADLOCK_RESOLVED.
Cascade behavior:
All participating sessions simultaneously. Non-participating
sessions in the same cluster that depend on DEADLOCK-
suspended sessions enter CLUSTER_BLOCKED state.
SACR implications for R-7:
SACR-spawned sub-agents participating in the DEADLOCK
are treated identically to directly-mandated agents.
Their ephemeral KIA references are retained while
DEADLOCK resolution is pending and retired only when
R-7 timeout or resolution is confirmed.
7.8. R-8: Compromise
Trigger condition: A mandate or the credential presented under it
is believed compromised due to a suspected or confirmed external
attack. Detection sources include a KIA reattestation failure
(the agent's runtime identity no longer matches its attested
state), a CAEP RISC signal indicating credential compromise, or an
operator-reported compromise finding.
GEC behavior on detection:
(a) The GEC MUST halt the session immediately, without waiting
for the current action to reach a natural breakpoint.
(b) The GEC MUST emit COMPROMISE_REVOCATION in GAR with the
detection source and, where available, the specific
attestation or signal that triggered detection.
(c) The GEC MUST cascade revocation to all descendant mandates
in the issuance tree (CASCADE_TO_DESCENDANTS, Section 3.5) --
a compromised mandate's descendants cannot be assumed
uncompromised.
(d) The GEC MUST route to HEM_TIER0_OBSERVED escalation (HEM
Class 6) for the highest-authority principal, the same
escalation class used for R-1.
Completion state:
PARTIAL or UNKNOWN. UNKNOWN if the GEC cannot determine
whether in-flight actions completed before compromise;
PARTIAL if it can. INV-15: UNKNOWN is treated as PARTIAL.
R-8 never produces CLEAN completion.
Continuation mandate authority:
Human principal MUST reauthorize. The operator MUST NOT
issue a continuation mandate for R-8 without explicit human
principal approval, and MUST NOT reuse the compromised
credential or any credential derived from the same key
material. GAR MUST record CONTINUATION_AWAITING_PRINCIPAL
until the principal issues the continuation mandate.
Cascade behavior:
Full CASCADE_TO_DESCENDANTS. All descendant sessions are
simultaneously terminated, mirroring R-1's cascade behavior,
since a compromised mandate's authority to have issued any
descendant is itself in question.
SACR implications for R-8:
All SACRs issued by the revoked session (and by its
descendants) are voided at the same time. All ephemeral
KIA references issued under those SACRs MUST be retired
immediately. The GEC MUST emit ALE-SPAWN-04 (EPHEMERAL_
IDENTITY_EXPIRED) for each retired ephemeral identity with
completion_state: PARTIAL.
7.9. Completion State Matrix
The following matrix summarizes completion state per trigger:
+--------+----------+----------------------------+------------------+
| Trigger| CLEAN | PARTIAL | UNKNOWN |
+--------+----------+----------------------------+------------------+
| R-1 | Never | Always | Treated as |
| | | | PARTIAL (INV-15) |
+--------+----------+----------------------------+------------------+
| R-2 | If Cedar | If irreversible action | If execution |
| | DENY at | taken before detection | state unknown |
| | Step 1 | | at detection |
+--------+----------+----------------------------+------------------+
| R-3 | Never | N/A | Always |
+--------+----------+----------------------------+------------------+
| R-4 | If halted| If halted after 1+ irrever-| N/A |
| | before | sible actions, mission | |
| | action | incomplete | |
+--------+----------+----------------------------+------------------+
| R-5 | If nat. | If rotation does not permit| N/A |
| | breakpt. | natural breakpoint wait | |
+--------+----------+----------------------------+------------------+
| R-6 | If halted| If mid-mission with irrev. | N/A |
| | at nat. | actions taken | |
| | breakpt. | | |
+--------+----------+----------------------------+------------------+
| R-7 | Never | N/A | Always |
+--------+----------+----------------------------+------------------+
| R-8 | Never | If in-flight completion | If in-flight |
| | | state determinable | state undeter- |
| | | | minable |
+--------+----------+----------------------------+------------------+
Table 1: Completion State Matrix by Revocation Trigger
7.10. Cascade Behavior by Trigger
The following matrix summarizes cascade behavior per trigger:
+--------+-----------------------------+----------------------------+
| Trigger| Cascade scope | SACR implication |
+--------+-----------------------------+----------------------------+
| R-1 | Full CASCADE_TO_DESCENDANTS | All SACRs voided; |
| | always | ephemeral refs retired |
+--------+-----------------------------+----------------------------+
| R-2 | Full CASCADE_TO_DESCENDANTS | All SACRs voided; |
| | always | ephemeral refs retired |
+--------+-----------------------------+----------------------------+
| R-3 | Selective; responsive | SACRs of responsive |
| | descendants continue | descendants survive |
+--------+-----------------------------+----------------------------+
| R-4 | Full CASCADE_TO_DESCENDANTS | All SACRs voided |
+--------+-----------------------------+----------------------------+
| R-5 | None (session-specific) | SACRs of session only |
+--------+-----------------------------+----------------------------+
| R-6 | Operator-specified scope | Per revocation_scope field |
+--------+-----------------------------+----------------------------+
| R-7 | All participating sessions | Ephemeral refs retained |
| | simultaneously | pending resolution; retired|
| | | on timeout or resolution |
+--------+-----------------------------+----------------------------+
| R-8 | Full CASCADE_TO_DESCENDANTS | All SACRs voided; |
| | always | ephemeral refs retired |
+--------+-----------------------------+----------------------------+
Table 2: Cascade Behavior by Revocation Trigger
8. SO Instance Topology Types
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
(RECONSTRUCTED in -04: real text from draft-sato-soos-mad-02
Section 4, renumbered 4.1-4.7 -> 8.1-8.7; -03 carried only a
bracket placeholder here.)
9. SO Cluster Coordination
9.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.
9.2. Cluster Declaration Protocol
A cluster is declared after its member SOs are created. Member
SOs MUST be created individually before cluster declaration.
9.3. Cluster Membership Model
STATIC clusters have a fixed membership declared at creation.
DYNAMIC clusters allow addClusterMember and removeClusterMember
operations after declaration.
9.4. Cluster Registry
The GEC MUST maintain an in-memory Cluster Registry rebuilt from
the Event Log on kernel restart (INV-14).
9.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.
9.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.
9.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.
9.8. Visibility Extensions
HEMContext carries cluster_context for HEM escalation decisions
involving cluster member sessions.
9.9. SACR Registry Addition (NEW in -03)
(RECONSTRUCTED in -04: Sections 9.1-9.8 above are the actual text
carried forward from draft-sato-soos-mad-02 Section 5, renumbered
5.1-5.8 -> 9.1-9.8; -03 carried only a bracket placeholder for this
part. The paragraph below is -03's own new addition, unchanged.)
The SACR Registry is a new kernel-internal structure introduced
in MAD-03 Section 4.3, distinct from but related to the Cluster
Registry (Section 9.4). The SACR Registry maps active sub-agent
session_ids to their SACRs for hub-only enforcement (Section 5.3).
The SACR Registry MUST be rebuilt from committed ALE-SPAWN-01
events in the GAR on kernel restart, before any sub-agent session
may execute.
10. Orchestrator-Specialist Model
10.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).
10.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.
10.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.
10.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.
10.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.
10.6. Mechanism B Interaction with SACR (NEW in -03)
(RECONSTRUCTED in -04: Sections 10.1-10.5 above are the actual text
carried forward from draft-sato-soos-mad-02 Section 6, renumbered
6.1-6.5 -> 10.1-10.5; -03 carried only a bracket placeholder for this
part. The paragraphs below are -03's own new addition, unchanged.)
When the Orchestrator-Specialist model employs Mechanism B
spawning (Section 4), the SACR MUST be issued and committed to GAR
before the orchestrator issues the Assignment for that specialist.
The Assignment's assigned_agent_id MUST equal the SACR's
ephemeral_kia_ref for Mechanism B specialists.
hub_only default: Specialist agents spawned from an orchestrator
via SACR carry hub_only: true by default (Section 4.2). Overriding
this to hub_only: false requires the conditions in Section 5.2 to
be satisfied and MUST be declared explicitly in the SACR.
11. Kernel Events (UPDATED in -03)
This section specifies the GEC events introduced by this
document. All GEC events MUST be signed by the KIA keypair
(INV-9 of [SOOS-KIA]).
(RECONSTRUCTED in -04: the event definitions below are the actual
text carried forward from draft-sato-soos-mad-01 Sections 7.1-7.9
and draft-sato-soos-mad-02 Sections 7.10-7.11; -03 carried only a
bracket placeholder claiming full carry-forward, with no event
schema actually present. Subsection numbers are omitted here to
match how -03's own new events below are presented, as named
blocks rather than a renumbered X.Y sequence.)
7.1. CREATE_SOVEREIGN_OBJECT
CREATE_SOVEREIGN_OBJECT {
event_type: "CREATE_SOVEREIGN_OBJECT",
event_id: <UUID>,
timestamp: <ISO-8601 microsecond>,
so_uuid: <UUID v4, GEC-assigned>,
so_type: <type_registry_id>,
so_type_version: <semver>,
creation_principal_class: "HUMAN_DIRECT" |
"AGENT_DELEGATED" |
"AGENT_AUTONOMOUS",
creation_mandate_jti: <jti> | null,
initial_state: <state_name>,
initial_zone_a_data: { <typed_graph_nodes> },
cedar_creation_result: "PERMIT" | "DENY",
gec_signature: <Ed25519 over canonical JSON>
}
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: <UUID>,
timestamp: <ISO-8601 microsecond>,
cluster_id: <UUID v4, GEC-assigned>,
membership_model: "STATIC" | "DYNAMIC",
member_so_uuids: [ <UUID>, ... ],
aggregation_rule: "ALL_COMPLETE" | "ANY_COMPLETE" |
"QUORUM" | null,
aggregation_quorum_n: <integer> | null,
orchestrator_session_id: <UUID>,
orchestrator_mandate_jti: <jti>,
cedar_result: "PERMIT",
gec_signature: <Ed25519 over canonical JSON>
}
7.3. CLUSTER_MEMBER_ADDED
CLUSTER_MEMBER_ADDED {
event_type: "CLUSTER_MEMBER_ADDED",
event_id: <UUID>,
timestamp: <ISO-8601 microsecond>,
cluster_id: <UUID>,
so_uuid: <UUID>,
requesting_agent_id: <party_registry_id>,
mandate_jti: <jti>,
cedar_result: "PERMIT",
gec_signature: <Ed25519 over canonical JSON>
}
7.4. CLUSTER_MEMBER_REMOVED
CLUSTER_MEMBER_REMOVED {
event_type: "CLUSTER_MEMBER_REMOVED",
event_id: <UUID>,
timestamp: <ISO-8601 microsecond>,
cluster_id: <UUID>,
so_uuid: <UUID>,
member_final_state: <state_name>,
requesting_agent_id: <party_registry_id>,
mandate_jti: <jti>,
cedar_result: "PERMIT",
gec_signature: <Ed25519 over canonical JSON>
}
7.5. CLUSTER_MERGED
CLUSTER_MERGED {
event_type: "CLUSTER_MERGED",
event_id: <UUID>,
timestamp: <ISO-8601 microsecond>,
source_cluster_id_a: <UUID>,
source_cluster_id_b: <UUID>,
resulting_cluster_id: <UUID v4, GEC-assigned>,
membership_model: "STATIC" | "DYNAMIC",
requesting_agent_id: <party_registry_id>,
cedar_result: "PERMIT",
gec_signature: <Ed25519 over canonical JSON>
}
7.6. CLUSTER_SPLIT
CLUSTER_SPLIT {
event_type: "CLUSTER_SPLIT",
event_id: <UUID>,
timestamp: <ISO-8601 microsecond>,
source_cluster_id: <UUID>,
resulting_cluster_id_a: <UUID v4, GEC-assigned>,
member_uuids_a: [ <UUID>, ... ],
resulting_cluster_id_b: <UUID v4, GEC-assigned>,
member_uuids_b: [ <UUID>, ... ],
requesting_agent_id: <party_registry_id>,
cedar_result: "PERMIT",
gec_signature: <Ed25519 over canonical JSON>
}
7.7. CLUSTER_DISSOLVED
CLUSTER_DISSOLVED {
event_type: "CLUSTER_DISSOLVED",
event_id: <UUID>,
timestamp: <ISO-8601 microsecond>,
cluster_id: <UUID>,
final_member_states: [ { so_uuid, final_state }, ... ],
requesting_agent_id: <party_registry_id>,
cedar_result: "PERMIT",
gec_signature: <Ed25519 over canonical JSON>
}
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: <cluster_id>:<so_uuid>,
condition_type: "CLUSTER_MEMBER_REACHED_TERMINAL",
current_value: <terminal_state_name>,
threshold_value: "TERMINAL",
proximity_pct: 1.0,
cluster_id: <UUID>,
so_uuid: <UUID>,
remaining_active_count: <integer>
}
7.9. ProximityEvent: CLUSTER_AGGREGATION_CONDITION_MET
This ProximityEvent is fired when the cluster's declared
aggregation condition is first satisfied.
ProximityEvent {
condition_id: <cluster_id>:AGGREGATION,
condition_type: "CLUSTER_AGGREGATION_CONDITION_MET",
current_value: <satisfied_count>,
threshold_value: <required_count>,
proximity_pct: 1.0,
cluster_id: <UUID>,
aggregation_rule: "ALL_COMPLETE" | "ANY_COMPLETE" | "QUORUM",
satisfied_members: [ <so_uuid>, ... ]
}
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, R-7, or R-8 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.
The following events are added in MAD-03:
Events from SACR lifecycle are specified in Section 4.4:
ALE-SPAWN-01: SUB_AGENT_COMPOSED
ALE-SPAWN-02: SPAWN_DEPTH_EXCEEDED
ALE-SPAWN-03: TOOL_SUBSET_VIOLATION
ALE-SPAWN-04: EPHEMERAL_IDENTITY_EXPIRED
Additional events added in MAD-03:
HUB_ONLY_VIOLATION
Emitted when a hub_only: true sub-agent session attempts
direct communication with a sibling sub-agent session.
Required fields: session_id, sacr_id, target_session_id,
attempted_action, detected_at, gec_signature.
DIRECT_COMM_PERMITTED
Emitted when a hub_only: false override has been validated
and the first direct communication between sub-agent sessions
is authorized. Required fields: initiating_session_id,
receiving_session_id, cedar_permit_ref, authorized_comm_types
(array), authorized_at, gec_signature.
IRREVERSIBLE_THRESHOLD_REACHED
Emitted when R-4 trigger fires. Required fields: session_id,
mandate_id, action_id, threshold_value, current_count,
anticipatory (boolean -- true if detected before action,
false if at execution time), gec_signature.
SCHEDULED_ROTATION_INITIATED
Emitted when R-5 trigger fires. Required fields: session_id,
mandate_id, rotation_schedule_id, next_natural_breakpoint_id,
initiated_at, gec_signature.
SESSION_REVOKED_BY_OPERATOR
Emitted when R-6 trigger fires. Required fields: session_id,
mandate_id, revoking_operator_principal_id, revocation_scope,
revoked_at, gec_signature.
SACR_REGISTRY_REBUILT
Emitted on kernel restart when the SACR Registry rebuild
from GAR is complete. Required fields: sacr_count,
active_sacr_ids (array), rebuilt_at, gec_signature.
Additional events added in MAD-04:
COMPROMISE_REVOCATION
Emitted when R-8 trigger fires. Required fields: session_id,
mandate_id, detection_source (KIA_REATTESTATION_FAILURE |
CAEP_RISC_SIGNAL | OPERATOR_REPORTED), attestation_ref
(reference to the specific attestation or signal that
triggered detection; null if operator-reported with no
machine-verifiable artifact), revoked_at, gec_signature.
12. Cedar Actions (UPDATED in -03)
The following Cedar actions are introduced by this document. All
actions MUST be registered in the SOOS Cedar namespace.
(RECONSTRUCTED in -04: the actions below are the actual text carried
forward from draft-sato-soos-mad-01 Section 8 and draft-sato-soos-
mad-02 Section 8's own additions; -03 carried only a bracket
placeholder claiming full carry-forward, with no action list
actually present.)
SOOS::Action::CreateSovereignObject
Required to call gec.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().
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).
The following Cedar actions are added in MAD-03:
SOOS::Action::SpawnSubAgent
Requested by a spawning agent to initiate SACR issuance.
Evaluated by the GEC before SACR issuance proceeds.
Cedar context includes: proposed scope_constraints,
requested_max_spawn_depth, requested_hub_only,
parent_mandate_id.
SOOS::Action::DirectSubAgentComm
Requested for direct sub-agent to sub-agent communication.
MUST NOT be permitted for sessions with hub_only: true
in their SACR. Cedar context includes: initiating_session_id,
target_session_id, comm_content_type.
13. Conformance (UPDATED in -03)
A conforming SOOS multi-agent implementation MUST satisfy all of
the following requirements. Items marked REJECT cause the kernel
to reject the triggering operation.
(RECONSTRUCTED in -04: CONF-MAD-01 through CONF-MAD-14 and
CONF-MAD-GEC-01/02 below are the actual text carried forward from
draft-sato-soos-mad-01 Section 9; CONF-MAD-INV4-01, CONF-MAD-BT-01,
CONF-MAD-15 through CONF-MAD-18, and CONF-MAD-GEC-03 are
draft-sato-soos-mad-02 Section 9's own additions. -03 carried only
a bracket placeholder naming these requirements without stating
any of them.)
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 GEC 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.
CONF-MAD-GEC-01: A conforming GEC implementation MUST enforce the
Narrowing Property (INV-4) at mandate issuance time in the Party
Registry. Enforcement solely at gec.transition() evaluation time
does not satisfy this requirement.
CONF-MAD-GEC-02: A conforming GEC implementation MUST rebuild the
Cluster Registry from the Event Log on GEC restart before
processing any cluster queries. A GEC serving cluster queries
from an unverified in-memory state without rebuild verification
does not satisfy this requirement.
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)
The following conformance requirements are added in MAD-03:
CONF-MAD-SACR-01: The GEC MUST complete all validation steps
(Section 4.3, Steps 1-4) before issuing the ephemeral_kia_ref.
CONF-MAD-SACR-02: A SACR MUST be committed to GAR (ALE-SPAWN-01)
before the sub-agent begins execution.
CONF-MAD-SACR-03: The tool_subset in the SACR MUST be enforced
at runtime at each gec.transition() call for the sub-agent session.
CONF-MAD-HUB-01: A sub-agent with hub_only: true MUST NOT send
messages, state updates, or coordination signals directly to any
sibling sub-agent.
CONF-MAD-HUB-02: The GEC MUST enforce hub-only mode at the Cedar
layer using context.hub_only_active on every gec.transition() call
for hub_only: true sub-agent sessions.
CONF-MAD-HUB-03: The GEC MUST NOT accept
Action::"DirectSubAgentComm" from a hub_only: true session.
CONF-MAD-HUB-04: see Section 5.2 for the full statement,
including the Section 5.2(a)-(d) override conditions. (This
summary entry restated the rule independently in -03, which
drifted out of sync with Section 5.2's coordinator exception;
-04 makes this entry a pointer to the single normative
statement in Section 5.2 rather than a second copy of it, to
remove the drift risk rather than just fixing the wording
twice.)
CONF-MAD-XPID-01: The GEC MUST derive and record the sub-agent
XPID at SACR issuance time and in every subsequent GAR governance
span for the sub-agent session.
CONF-MAD-XPID-02: Cross-cluster sub-agent XPID verification MUST
complete before the receiving GEC accepts any governance events
from the sub-agent session.
CONF-MAD-R5-01: A GEC MUST NOT revoke an R-5 session mid-transition.
CONF-MAD-19: max_spawn_depth MUST strictly decrement at each
recursive spawn. Parent MUST NOT issue a SACR with max_spawn_depth
greater than (parent's own max_spawn_depth - 1).
CONF-MAD-20: A sub-agent with can_decompose: false MUST NOT call
gec.spawnSubAgent(). The GEC MUST reject such calls with
CAN_DECOMPOSE_FALSE_VIOLATION.
CONF-MAD-21: A sub-agent with max_spawn_depth: 0 MUST NOT call
gec.spawnSubAgent(). The GEC MUST reject such calls with
SPAWN_DEPTH_ZERO_VIOLATION.
CONF-MAD-22: The SACR Registry MUST be rebuilt from committed
ALE-SPAWN-01 events on kernel restart before any sub-agent
session may execute.
14. Open Issues
The following open questions are recorded for resolution in
successor documents.
(RECONSTRUCTED in -04: OQ-S-41/43/44 (now 14.1-14.3) are the actual
text carried forward from draft-sato-soos-mad-01 Section 10;
OQ-S-45 (now 14.4) is draft-sato-soos-mad-02 Section 10's own
addition. -03 carried only a bracket placeholder for all four.
-03's own new items, originally numbered 14.4-14.6, are renumbered
14.5-14.7 below to make room -- restoring the real carried-forward
content is what surfaces this collision; a bracket placeholder
hides it.)
14.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.
14.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.
14.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.
14.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.
The following open issues are added in MAD-03:
14.5. OQ-SPAWN-01: Spawn Authority Propagation to AOP
The SACR mechanism specified in Section 4 covers the kernel-
mediated spawning primitive for Mechanism B sub-agents. How
the spawning authority itself flows through the AOP (Agentic
Orchestration Protocol) layer -- specifically, whether AOP's
Mission Plan SO issuance implicitly grants spawning authority
or whether an explicit spawning mandate is required -- is
deferred to the AOP specification [SOOS-AOP].
OQ-SPAWN-01 is tracked as HIGH priority. (CORRECTED in -04:
-03 said resolution was expected in AOP-00 before Vienna; AOP
has since closed its own WIMSE Security Review pass at -02,
without resolving this cross-draft question. Retargeted to
AOP's next revision.)
14.6. OQ-SPAWN-06: Bounded Direct Channel for KEE Performance
DR-SPAWN-01 OQ-SPAWN-06 identified a potential need for a
bounded direct channel between sub-agents for latency-sensitive
use cases (relevant to KEE performance). The hub-only constraint
(Section 5) is the default normative position. Whether a bounded
direct channel (scoped to declared DAG edge content types, not
general messaging) should be normatively specified as an override
is deferred.
OQ-SPAWN-06 is tracked as MEDIUM priority.
14.7. OQ-MAD-XPID-01: SACR Chain Depth Limit for XPID Derivation
The XPID derivation for sub-agents (Section 6.1) chains from
parent XPID + sacr_id. In deeply recursive delegation trees
(max_spawn_depth > 10), the XPID chain may become unwieldy for
cross-cluster verification. Whether a normative depth limit on
XPID chaining is required, or whether the max_spawn_depth limit
itself provides sufficient bound, is an open question.
OQ-MAD-XPID-01 is tracked as LOW priority.
15. Security Considerations
(RECONSTRUCTED in -04: Sections 15.1-15.7 below are the actual
text carried forward -- 15.1-15.3 from draft-sato-soos-mad-01
Section 11, 15.4-15.7 from draft-sato-soos-mad-02 Section 11's own
additions. -03 carried only a bracket placeholder for all seven;
internal cross-references renumbered to match this document's
current section numbers.)
15.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.
15.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 9.5) creates a new input surface for Cedar policy
evaluation. Implementors MUST ensure that cluster_context is
populated exclusively from the GEC-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.
15.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.
15.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 14.4.)
15.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 15.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.
15.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.
15.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.
The following considerations are added in MAD-03:
15.8. Cascade Revocation Timing Attack (NEW in -03)
An adversary who can observe the timing of mandate revocation
events may exploit the window between CASCADE_TO_DESCENDANTS
authority revocation (atomic at the Revocation Registry) and
session termination signal delivery (bounded by cascade_timeout)
to execute actions during the propagation window under a
technically valid mandate.
The attack vector: the adversary controls a specialist agent
deep in a delegation tree. When the orchestrator mandate is
revoked, the adversary's agent continues executing for up to
cascade_timeout seconds before receiving the termination signal.
If the agent is engaged in an irreversible action, it may
complete that action under a revoked authority.
Defense requirements:
CONF-MAD-SEC-CASCADE-01: Implementations MUST ensure that the
cascade_timeout period does not exceed 30 seconds for single-
region clusters, and MUST be declared in the GEC Manifest for
any higher value.
CONF-MAD-SEC-CASCADE-02: Irreversible actions MUST require
a pre-execution Revocation Registry check via HEM-PRE-2
(Section 7.2.2 of [SOOS-HEM]) when the action is
classified IRREVERSIBLE in the IDP. This check occurs within
the cascade window and prevents completion of irreversible
actions after the Revocation Registry is updated.
CONF-MAD-SEC-CASCADE-03: Sessions executing irreversible
actions MUST subscribe to the revocation notification stream.
A session that proceeds with an irreversible action while the
revocation stream subscription is inactive is non-conforming.
15.9. Sub-Agent Scope Inflation (NEW in -03)
A malicious spawning agent may attempt to issue a SACR that
grants the spawned sub-agent a tool_subset or cedar_action_subset
that exceeds the spawning agent's own authorized access -- either
by misrepresenting its own scope at spawn time, or by exploiting
a TOCTOU (time-of-check/time-of-use) race between the GEC's
scope validation and SACR issuance.
Defense requirements:
CONF-MAD-SACR-04: The GEC MUST perform the tool-subset and Cedar
action-subset validation (Section 4.3, Steps 2-4) atomically
with SACR issuance. The spawning agent's authorized scope MUST
be locked at the time of validation and MUST NOT be updatable
between validation and issuance.
CONF-MAD-SACR-05: The GEC MUST verify the spawning agent's
current Cedar action set from the Revocation Registry and the
active mandate JWT at validation time, not from an agent-supplied
claim. An agent-supplied scope claim MUST be treated as
untrusted.
CONF-MAD-SACR-06: All SACR issuances MUST be recorded in GAR
(ALE-SPAWN-01) with the full scope_constraints object, enabling
post-hoc audit of whether the granted scope was valid. The
GAR entry MUST carry the gec_signature over the scope_constraints
to make the grant tamper-evident.
15.10. XPID Cross-Cluster Spoofing (NEW in -03)
A malicious agent or compromised GEC instance may attempt to
present fabricated sub-agent XPIDs to a receiving cluster to
gain unauthorized access to cross-cluster resources or to
insert fraudulent audit records.
The attack vector: an attacker with knowledge of a legitimate
parent XPID constructs a fabricated sacr_id and derives a
plausible-looking sub-agent XPID. If the receiving GEC does
not verify the full SACR chain, the fabricated XPID may be
accepted.
Defense requirements:
CONF-MAD-XPID-03: Receiving GEC instances MUST obtain the
SACR from the originating GEC instance via the authenticated
federation channel (Section 6.2, Step (a)) before accepting
any cross-cluster sub-agent events. The SACR MUST be signed
by the originating GEC's keypair (INV-9) and verified before
XPID computation.
CONF-MAD-XPID-04: A XPID presented without a verifiable SACR
chain to the root XPID MUST be rejected. The receiving GEC
MUST emit XPID_VERIFICATION_FAILED and route to the operator
notification channel.
CONF-MAD-XPID-05: The SACR Registry maintained by the
originating GEC constitutes the authoritative record for SACR
existence verification. Receiving kernels MUST verify SACR
authenticity against the originating GEC's signed SACR
Registry, not against a copy supplied by the presenting agent.
15.11. Partial Completion Race Condition (NEW in -03)
When a session revocation signal arrives while an irreversible
action is in progress, a race condition can occur between the
action completing (CLEAN) and the revocation halting it
(PARTIAL). Implementations that resolve this race incorrectly
may permit an irreversible action to complete under a revoked
mandate or classify a completed irreversible action as CLEAN
when the action's outcome is actually uncertain.
Defense requirements:
CONF-MAD-SEC-RACE-01: The GEC MUST implement an atomic
check-halt for irreversible actions: before any irreversible
action is committed to the SO Event Stream, the GEC MUST
check the Revocation Registry. If the mandate jti appears
in the Revocation Registry at the time of this check, the
action MUST NOT be committed.
CONF-MAD-SEC-RACE-02: The check-halt MUST be atomic with
the commitment. A two-phase implementation that separates
the Revocation Registry check from the commitment (with a
window between them) is non-conforming.
CONF-MAD-SEC-RACE-03: completion_state MUST be determined
at the instant of halt. A GEC that determines completion
state after the halt (from log reconstruction) MUST document
this as an implementation constraint and MUST classify the
state as UNKNOWN if the log reconstruction is incomplete.
INV-15 applies: UNKNOWN MUST be treated as PARTIAL.
15.12. Compromise Report False-Positive as a Denial-of-Service
Vector
(NEW in -04)
R-8 revocation is immediate and unconditional (Section 7.8), with
no timeout-and-recover mechanism analogous to R-7's
deadlock_timeout (Section 15.6) -- a compromise finding is treated
as too urgent to wait on. This creates an asymmetric attack
surface: an entity able to inject a false detection_source signal
(a spoofed CAEP RISC signal, a manipulated KIA reattestation
result, or a false operator report) can trigger an unconditional,
immediately-cascading revocation of a legitimate session and its
entire descendant tree, with no auto-recovery window to bound the
damage the way R-7's timeout does.
Implementations MUST verify the authenticity and integrity of any
detection_source signal before committing an R-8 revocation --
in particular, a CAEP_RISC_SIGNAL or KIA_REATTESTATION_FAILURE
detection_source MUST be independently verified against the
signing authority's own key material, not accepted on the basis
of transport-layer trust alone. Operators SHOULD treat repeated
OPERATOR_REPORTED compromise findings against the same principal
or agent as a signal warranting its own investigation, since this
is the one detection_source with no independent machine
verification available.
16. IANA Considerations
(draft-sato-soos-mad-02 Section 12 had no IANA actions at that
time. This document requests the creation of the following IANA
registries:)
16.1. SACR Media Type Registry (New)
Registry Name:
SOOS Sub-Agent Composition Record (SACR) Media Type
Registration Procedure:
Standards Action [RFC8126]
Registered Media Type:
application/soos-sacr+json
Description:
The SOOS Sub-Agent Composition Record as defined in Section 4.2
of this document. A SACR is a GEC-signed JSON object recording
the spawning of a Mechanism B sub-agent, including the ephemeral
identity issued, the tool subset granted, the scope constraints
applied, and the spawn-depth and hub-only governance parameters.
Required fields: sacr_id, parent_assignment_id, parent_session_id,
parent_mandate_id, parent_xpid, ephemeral_kia_ref,
scope_constraints, can_decompose, max_spawn_depth, hub_only,
replan_authority, composition_timestamp, sacr_signature.
16.2. Revocation Trigger Class Registry (New)
Registry Name:
SOOS Agent Session Revocation Trigger Classes
Registration Procedure:
Specification Required [RFC8126]
Initial Values:
+--------+-----------------------------+----------------------------+
| Code | Name | Description |
+--------+-----------------------------+----------------------------+
| R-1 | CAP_TIER_0A_VIOLATION | CAP constitutional |
| | | prohibition violated; |
| | | human reauth required |
+--------+-----------------------------+----------------------------+
| R-2 | SCOPE_BOUNDARY | Out-of-scope action |
| | | detected; human reauth |
| | | required |
+--------+-----------------------------+----------------------------+
| R-3 | NON_RESPONSE | Governance signal not |
| | | acknowledged within |
| | | cascade_timeout; |
| | | operator may reauth |
+--------+-----------------------------+----------------------------+
| R-4 | IRREVERSIBLE_THRESHOLD | Irreversible action |
| | | threshold reached; human |
| | | reauth required |
+--------+-----------------------------+----------------------------+
| R-5 | SCHEDULED_ROTATION | Planned rotation; |
| | | operator may reauth |
+--------+-----------------------------+----------------------------+
| R-6 | OPERATOR_OVERRIDE | Explicit operator |
| | | revocation; operator |
| | | may reauth |
+--------+-----------------------------+----------------------------+
| R-7 | DEADLOCK | Circular resource lock |
| | | across cluster sessions; |
| | | human reauth required |
+--------+-----------------------------+----------------------------+
| R-8 | COMPROMISE | Mandate or credential |
| | | believed compromised; |
| | | human reauth required |
+--------+-----------------------------+----------------------------+
Table 3: Revocation Trigger Class Registry Initial Values
16.3. SACR Kernel Event Types in GAR ALE Registry
This document requests registration of the following ALE types in
the GAR ALE Type Registry defined in [SOOS-GAR]:
+----------------+--------------------------------------------------+
| ALE Name | Description |
+----------------+--------------------------------------------------+
| ALE-SPAWN-01 | SUB_AGENT_COMPOSED: SACR issued; ephemeral |
| (SUB_AGENT_ | identity created. Section 4.4. |
| COMPOSED) | |
+----------------+--------------------------------------------------+
| ALE-SPAWN-02 | SPAWN_DEPTH_EXCEEDED: spawn request rejected due |
| (SPAWN_DEPTH_ | to max_spawn_depth constraint. Section 4.4. |
| EXCEEDED) | |
+----------------+--------------------------------------------------+
| ALE-SPAWN-03 | TOOL_SUBSET_VIOLATION: spawn request rejected |
| (TOOL_SUBSET_ | due to tool_subset not being a subset of the |
| VIOLATION) | parent's access. Section 4.4. |
+----------------+--------------------------------------------------+
| ALE-SPAWN-04 | EPHEMERAL_IDENTITY_EXPIRED: sub-agent session |
| (EPHEMERAL_ | closed; ephemeral_kia_ref retired. |
| IDENTITY_ | Section 4.4. |
| EXPIRED) | |
+----------------+--------------------------------------------------+
17. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Token (JWT)", RFC 7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[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-03, Work in Progress, August 2026.
[SOOS-HEM] Sato, T., "Human Escalation Mechanism",
draft-sato-soos-hem-06, Work in Progress, August 2026.
[SOOS-KIA] Sato, T., "Kernel Identity and Attestation",
draft-sato-soos-kia-06, Work in Progress, August 2026.
[SOOS-MJWT] Sato, T., "Mandate JWT",
draft-sato-soos-mjwt-05, August 2026.
[SOOS-SOV] Sato, T., "Sovereign Object",
draft-sato-soos-sov-03, August 2026.
[SOOS-GAR] Sato, T., "Governance Audit Record",
draft-sato-soos-gar-07, Work in Progress, September 2026.
[SOOS-CAP] Sato, T., "The Constitutional AI Protocol (CAP)",
draft-sato-soos-cap-05, Work in Progress, August 2026.
[SOOS-IDP] Sato, T., "Intent Declaration Primitive",
draft-sato-soos-idp-05, Work in Progress, June 2026.
[SOOS-AOP] Sato, T., "Agentic Orchestration Protocol",
draft-sato-soos-aop-02, Work in Progress, August 2026.
18. Informative References
[OIF-REVOC] OpenID Foundation, "Agentic AI Authorization
Challenges: Revocation Across Attenuated Delegation
Chains", arXiv:2604.23280, April 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.
[OAUTH-TXN-TOKENS]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"OAuth 2.0 Transaction Tokens",
draft-ietf-oauth-transaction-tokens-08, Work in
Progress, 2026.
[AUTHZEN] OpenID Foundation, "AuthZEN Authorization API 1.0",
January 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.
[DR-SPAWN-01] Sato, T., "Sub-Agent Composition and Spawning
Architecture", SOOS Discussion Record DR-SPAWN-01,
June 19, 2026. Internal working document.
[DR-MAD-REC-01] Sato, T., "Agent Session Revocation and Recovery
Lifecycle", SOOS Discussion Record DR-MAD-REC-01,
June 4, 2026. Internal working document.
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.
(RECONSTRUCTED in -04: B.1-B.6 and B.8-B.10 below are the actual
text carried forward from draft-sato-soos-mad-01 Appendix B; -03
carried only a bracket placeholder for all ten. B.7 is updated
with the current -04 batch version list, including AOP -- omitted
from every prior version of this list since AOP wasn't recognized
as a tracked companion draft until the WIMSE Security Review's SOV
pass surfaced it. B.11 is draft-sato-soos-mad-02's own real text,
unchanged.)
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-05 and
draft-sato-soos-hem-06 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 (UPDATED in -03)
This document is one of seventeen SOOS IETF individual
submissions tracked in the Phase 2 WIMSE Security Review batch.
References updated to current versions:
draft-sato-soos-idp-05 Intent Declaration Primitive.
draft-sato-soos-hem-06 Human Escalation Mechanism.
draft-sato-soos-gar-07 Governance Audit Record.
draft-sato-soos-cap-05 The Constitutional AI Protocol (CAP).
draft-sato-soos-sov-03 Sovereign Object.
draft-sato-soos-mjwt-05 Mandate JWT.
draft-sato-soos-aep-03 Agent Execution Protocol.
draft-sato-soos-kia-06 Kernel Identity and Attestation.
draft-sato-soos-pt-03 Progressive Trust.
draft-sato-soos-faip-02 Federated Agent Intelligence Protocol.
draft-sato-soos-cap-rrs-03 CAP Regulation Record Schema.
draft-sato-soos-aop-02 Agentic Orchestration Protocol.
B.8. ICON Initiative: Control Pillar
The ICON initiative [ICON-PS] defines Control as one of three
pillars for autonomous agent governance in network management
contexts, alongside Observability and Intervention.
Relationship: Direct composition. MAD addresses the ICON Control
pillar in full. The two properties ICON requires of a Control
mechanism are precisely what MAD specifies: authority delegation
governance (INV-4 ensures control cannot amplify across delegation
hops) and revocation propagation (CASCADE_TO_DESCENDANTS ensures
a single revocation decision reaches all agents in the delegation
tree immediately -- the stop-with-one-decision requirement).
In network management: when a network management orchestrator
delegates routing decisions to segment specialists, MAD ensures
(a) each specialist is authorized only for its specific segment;
(b) if the orchestrator's authorization is revoked, all specialist
sub-agents immediately lose authority to make further changes.
The SO Cluster Coordination Primitives (Section 5) address the
ICON operational topology: network management parallel fan-out
workflows with QUORUM or ALL_COMPLETE aggregation rules map
directly to Topology 2 (Parallel Fan-Out) SO Clusters.
The ICON Intervention pillar is addressed by HEM; the
Observability pillar by PT. Together HEM + PT + MAD cover all
three ICON pillars.
Integration: ICON-conforming Control pillar implementations
SHOULD adopt MAD's Narrowing Property and CASCADE_TO_DESCENDANTS
as normative specifications for delegation authority governance
and cascade revocation.
B.9. AUDIT Working Group
The AUDIT working group [AUDIT-BOF] is developing interoperable
mechanisms for auditing AI agents across Internet protocols.
Relationship: Composition. MAD generates multi-agent audit events
that AUDIT WG formats must accommodate: CREATE_SOVEREIGN_OBJECT,
CLUSTER_DECLARED, CLUSTER_MEMBER_ADDED, CLUSTER_MEMBER_REMOVED,
CLUSTER_MERGED, and CLUSTER_DISSOLVED are candidate AUDIT WG
interaction record entry types. The mandate issuance tree
(Section 3.2) is the delegation provenance record that AUDIT WG
Deliverable 2 must support.
Integration: AUDIT WG audit data models SHOULD include a multi-
agent workflow record type carrying cluster_id,
orchestrator_mandate_jti, member_so_uuids, and
aggregation_rule_applied from the CLUSTER_DECLARED event schema.
B.10. DAWN Working Group
The DAWN proposed working group (Definitions for AI Workloads on
the Network) is developing terminology and named entity definitions
for AI workloads operating on network infrastructure.
Relationship: Composition at the registry layer. The SO Type
Registry (draft-sato-soos-sov) is the operator-side implementation
of the DAWN named entity concept: SO Types are versioned, signed,
registry-governed definitions of the state machines that govern
AI agent behavior. MAD extends the SO Type Registry to multi-
agent workflows through SO-Type-Bound Creation Mandates (Section
3.3): an orchestrator with a creation mandate can instantiate
cluster member SOs of that type, creating a distributed workflow
topology derivable from the SO Type Registry definition alone.
Integration: DAWN named entity definitions SHOULD reference SO
Type Registry entries as a concrete implementation. A SOOS SO
Type Registry entry SHOULD be exportable as a DAWN-conforming
named entity record.
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 (UPDATED in -04)
C.1. Protocol Summary
Protocol: Multi-Agent Delegation (MAD)
Version: draft-sato-soos-mad-04
Family: SOOS protocol suite
Role: Coordination governance layer for multi-agent workflows --
authority narrowing (INV-4), cascade revocation with full
R-1 through R-8 trigger taxonomy, SACR sub-agent spawning,
hub-only communication constraint, XPID cross-cluster
integration
Stack position: Coordinates across AEP, SOV, MJWT, HEM, GAR, CAP,
and KIA (for XPID derivation and ephemeral KIA refs).
C.2. Key Identifiers
Core invariants (unchanged from MAD-02):
INV-4 (Narrowing Property), INV-15 (UNKNOWN != CLEAN),
INV-16 (completion_state REQUIRED in GAR on revocation)
New in MAD-03:
SACR schema: sacr_id, parent_assignment_id, ephemeral_kia_ref,
scope_constraints, can_decompose, max_spawn_depth, hub_only,
replan_authority, sacr_signature
Sub-agent XPID: UUID5(KIA_NS, parent_xpid + ":" + sacr_id)
Hub-only constraint: hub_only: true default; CONF-MAD-HUB-01-04
SACR events: ALE-SPAWN-01 through ALE-SPAWN-04
Hub events: HUB_ONLY_VIOLATION, DIRECT_COMM_PERMITTED
R-1 through R-7: full normative specs in Section 7
Completion state matrix: Table 1
Cascade behavior matrix: Table 2
New in MAD-04:
R-8 (Compromise) trigger class: Section 7.8
COMPROMISE_REVOCATION event: Section 11
Completion state matrix and cascade behavior matrix updated
with an R-8 row (Tables 1 and 2)
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), R-8 (Compromise)
Topology ALE events (unchanged): ALE-013 through ALE-016
Cluster Cedar actions (unchanged + new):
ResolveDeadlock, ApproveBudgetTransfer, ApproveDelegation,
RetryDelegation, ReleasePooledSession,
SpawnSubAgent (new), DirectSubAgentComm (new)
Conformance (new in MAD-03):
CONF-MAD-SACR-01 through CONF-MAD-SACR-06
CONF-MAD-HUB-01 through CONF-MAD-HUB-04
CONF-MAD-XPID-01 through CONF-MAD-XPID-05
CONF-MAD-R5-01, CONF-MAD-19 through CONF-MAD-22
CONF-MAD-SEC-CASCADE-01 through -03
CONF-MAD-SEC-RACE-01 through -03
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
Acknowledgements
Sections 1 through 11 of this document build on
draft-sato-soos-mad-02, whose full acknowledgments are incorporated
by reference.
The SACR (Section 4) and hub-only constraint (Section 5) were
designed in DR-SPAWN-01 (June 19, 2026), which identified the gap
in MAD-02's spawning model. The hub-only direction was adopted
from DR-SPAWN-01 OQ-SPAWN-06 resolution: hub-only is the only
model consistent with DEC-PLAN-13 and the horizontal non-
contamination property.
The full normative per-trigger specifications for R-1 through R-7
(Section 7) were developed from [DR-MAD-REC-01] (June 4, 2026)
which
identified the revocation taxonomy gap. The completion state matrix
(Table 1) and cascade behavior matrix (Table 2) formalize the
per-trigger behavior that was described only at the taxonomy level
in MAD-02. R-8 (Compromise) was added in -04, surfaced while
mapping this taxonomy onto the Mandate Lifecycle Events (MLE)
profile's `reason` enum during the WIMSE Security Review's
cross-draft consistency pass (`soos-crossdraft-findings-mjwt-
mad-gar.md`, OQ-MADTAX-01).
XPID cross-cluster integration (Section 6) follows directly from
the XPID design in the current [SOOS-KIA]. The sub-agent
XPID derivation using parent_xpid + sacr_id extends the KIA-03
derivation to the delegation tree case.
The four new Security Considerations (Sections 15.8 through 15.11)
were developed as part of the SOOS UpgradeSprint Day 7 security
pass (June 30, 2026), as recorded in SOOS_UpgradeSprint_v12.md
ORDER 7.
Author's Address
Tom Sato
MyAuberge K.K.
Chino, Nagano, Japan
Email: tomsato@myauberge.jp
URI: https://soosproject.ai/drafts/mad