Bounded Orchestration: Identity, Delegation, and Audit Discipline for Multi-Agent AI Systems in Organizations

> ## ⚠️ Draft — Open for Peer Review > > Paper #3 in the SomaSoft agentic-AI audit series. Per the standing SomaSoft / AURI program audit discipline (see the AIES 2026 paper and its 24-entry ledger of corrected self-deceptions), this paper is itself a candidate confabulation surface. Three reviews are required before any external citation: > > 1. Multi-agent literature review. The orchestration topology framework draws on distributed-systems literature, the bounded-delegation pattern draws on capability-based security (Levy 1984) and least-privilege (Saltzer & Schroeder 1975), and the identity model draws on macaroons (Birgisson et al. 2014) and zero-trust (NIST SP 800-207). The combination is the novel contribution; each component has its own established lineage that domain reviewers should verify against current practice. > 2. Standards-body attribution check. The paper cites MCP (Anthropic, Linux Foundation AAIF since Dec 2025) and A2A (Google, Linux Foundation since June 2025) as the protocol-layer governance that has emerged. Stewardship has shifted recently and current readers should verify the protocol governance state at time of reading. > 3. AURI Reality Engine audit pass. Per the AURI program audit discipline, every concrete claim binds to a publicly cited source. The paper makes no claims requiring inside knowledge of any commercial organization's agentic systems. Each claim should be challenged on whether it survives external grounding. > > What this paper is not: it is not a critique of any specific organization's deployment; it is not a regulatory recommendation beyond "treat orchestration as a regulatory object"; it is not a claim that bounded orchestration is sufficient (it is necessary, not sufficient); it is not a claim that aggregation risk is solved. > > What this paper is: a structural framework for evaluating the discipline of an organization's multi-agent deployment, applicable across industries, vendor stacks, and regulatory regimes. The framework is implementable today without infrastructure cost, provided the discipline is committed to before deployment. > > The reader is invited to challenge specific claims rather than the document as a whole.

---

Identity, Delegation, and Audit Discipline for Multi-Agent AI Systems in Organizations

A SomaSoft Research Paper — Paper #3 in the Agentic AI Audit Series

Authors: Mark Nafe (SOMAsoft) · AURI Substrate System (concept graph, ethics framework, Reality Engine, 24-entry audit ledger) · Claude Code (drafting collaborator) Date: May 29, 2026 Status: DRAFT — open for peer review. Per the standing SomaSoft / AURI program audit discipline, every concrete claim binds to a publicly cited source; the paper makes no claims requiring inside knowledge of any organization's systems. Companion artifacts: - papers/PhD_PAPER_AGENTIC_BEHAVIORAL_TAXONOMY_SOMASOFT_20260518.md — the 4-level taxonomy and 27-behavior rubric this paper extends - papers/PhD_PAPER_MYTHOS_AGENTIC_AUDIT_SOMASOFT_20260519.md — Paper #2, single-agent case study - papers/AIES_2026_full_paper.md — audit methodology and 24-entry ledger this work rests on

---

Abstract

Problem. The agentic AI conversation in 2026 focuses almost entirely on the single autonomous agent — its capability, its safety, its scope. But the deployment unit that organizations are actually buying and standing up is not one agent. It is many: customer-service agents that call billing agents that read fraud-detection agents that trigger account-action agents. The single-agent question — is Mythos safe? — is being answered by a research community while the multi-agent question — what happens when fifty agents share the same enterprise and reach into each other's outputs? — is being deferred to vendors and procurement.

Method. We extend the four-level taxonomy and 27-behavior rubric introduced in our companion papers (Nafe 2026a, 2026b) to org-level orchestration. The contribution is three-fold: (1) a topology framework distinguishing hub-and-spoke, mesh, federated, and hierarchical multi-agent deployments, with the risk profile each carries; (2) an agent identity model explaining why standard human SSO does not transfer cleanly to agents and what the substitution should look like; (3) the bounded-delegation pattern — a structural discipline under which any agent can invoke another agent only within its declared scope, inheriting the audit trail. We argue that aggregation risk (many agents each with small permissions collectively doing something none was authorised for) is the dominant unsolved problem in 2026 agentic deployment, and that the audit trail itself becomes the trust artifact that survives staffing changes, vendor swaps, and incident response.

Implications. Organizations standing up agentic systems in 2026 face a regulatory environment (FTC 6(b), EU AI Act, NIST AI RMF, ISO 42001) that addresses individual agent safety but treats the orchestration layer as out of scope. We argue this gap is where the next class of incidents will occur, and that the orchestration discipline we describe is implementable today without infrastructure cost — provided the discipline is committed to before deployment, not bolted on after.

---

1. Introduction

A 2026 enterprise rolling out agentic AI does not stand up "an agent." It stands up several, often dozens. A typical pattern in financial services, healthcare, and large-organization IT: a conversational triage agent receives a customer or employee request, classifies the intent, invokes one or more specialist agents (billing, fraud, identity-verification, scheduling), each of which may invoke further agents (database-query agents, third-party-service agents, compliance-check agents), and a final summarisation agent aggregates results for the human or for downstream automation.

The single-agent question that the research community has been working — can we audit Mythos's bounded self-modification? (Nafe 2026b, §3-4) — is not the question that decides whether the enterprise deployment is safe. The deciding question is structural: what determines which agent can invoke which, what each is allowed to do once invoked, how the chain is logged, and how a failure in one agent propagates to the others?

This paper is not a survey of orchestration tools. It is a framework for evaluating the discipline of an orchestration deployment, applicable across industries, vendor stacks, and regulatory regimes. The framework is built from three claims:

1. Multi-agent topologies have qualitatively different risk profiles. A hub-and-spoke topology with a single trusted orchestrator is not the same risk as a mesh topology where any agent can invoke any other.

2. Agents need identities, but agent identity is not user identity. Standard SSO patterns (OAuth, OIDC, SAML) assume the subject is a long-lived human with a slowly-changing capability set. Agents are ephemeral, capability-precise, and may need to be revoked within seconds. The institutional habits around human IAM transfer badly.

3. Bounded delegation — where any agent can only invoke other agents within its declared scope, and the audit trail accumulates as the chain executes — is the only orchestration discipline that scales without producing aggregation risk. Aggregation risk is the dominant unsolved problem in 2026 multi-agent deployment.

We make no claim that this framework is novel in every part. Aspects of bounded delegation echo the principle of least privilege (Saltzer & Schroeder 1975), capability-based security (Levy 1984), zero-trust architecture (NIST SP 800-207), and the recent agent-to-agent communication standards work (MCP, A2A). The contribution is the combined framework, applied at the level the deployment evaluator needs, with the audit discipline (Nafe 2026c) that makes the framework verifiable rather than aspirational.

1.1 What this paper is not

- It is not a critique of any specific organisation's deployment. We have not audited any commercial multi-agent system. The framework is offered as a tool, not a verdict. - It is not a claim that bounded orchestration is solved. Several of the patterns we describe are partial — particularly cross-organizational agent treaties and real-time capability revocation. We name what is unsolved. - It is not a regulatory recommendation. Regulators are mentioned as users of the framework. We do not propose specific rules.

---

2. Background — the four-level taxonomy and behavioral rubric (recap)

Paper #1 (Nafe 2026a) introduced a four-level taxonomy of agentic ability:

- Level 0 — Runtime independence. Multi-step execution within a fixed scope. - Level 1 — Parameter / state regulation. Internal weights, retrieval scores, or memory update from experience, without scope expansion. - Level 2 — Bounded self-modification. The agent modifies downstream artifacts in the world (generated code, system configurations, knowledge bases) within an explicitly enforced sandbox. Does not modify its own source, weights, or operating rules. - Level 3 — Self-redesigning autonomy. The agent modifies its own architecture, weights, safety rules, or operating principles without external review. Argued to be incoherent at any current technology level.

The taxonomy distinguishes scope-of-action (how far into the world the agent's actions reach) from scope-of-self (how much of the agent itself the agent's actions can modify). Paper #2 (Nafe 2026b) demonstrated that Mythos sits at L2-action / L0-1-self — high action, narrow self — and argued this asymmetry is the deployable pattern, while the inverse (low action, wide self) is the alignment-anxiety pattern.

The 27-behavior rubric (12 red flags, 7 yellow, 8 green) provides per-system evaluation criteria for a single agent. This paper extends the rubric to the system of systems — what happens when several agents at different levels of the taxonomy share an organisation, and the orchestration layer between them becomes its own object of evaluation.

---

3. Orchestration topology

The first claim: multi-agent topologies have qualitatively different risk profiles, and the topology is often invisible to non-specialist evaluators because the marketing language ("multi-agent system," "agentic workflow") flattens four distinct structures into one label.

3.1 Hub-and-spoke

A single orchestrator agent (often human-supervised at start, increasingly autonomous over time) holds the routing logic. All specialist agents are invoked by the orchestrator and return to the orchestrator. Specialist agents do not invoke each other directly.

- Trust concentration: extreme. The orchestrator becomes a single point of compromise and a single point of audit obligation. - Audit trail: clean. Every request and every response is mediated by the orchestrator. - Failure mode: orchestrator failure paralyses the whole system; orchestrator misbehavior touches everything. - Where seen: most managed customer-service deployments, ITSM ticket-routing platforms, the canonical "AI assistant with tools" pattern.

3.2 Mesh

Any agent can invoke any other agent (subject to coarse-grained authorisation). No central orchestrator.

- Trust concentration: low (per-agent). - Audit trail: difficult. Cross-agent invocations need to be logged at both ends or via a separate audit infrastructure; correlation across invocations becomes a research problem. - Failure mode: cascade. One compromised agent can call others, which call others, in chains that are hard to predict before deployment. - Where seen: research systems, some experimental enterprise stacks, and — under the surface — many "single-agent" deployments where the agent's tools are themselves agentic and not labelled as such.

3.3 Federated

Agents are organised into clusters (e.g., by domain, by trust level, by jurisdiction). Within a cluster the topology is hub-and-spoke or mesh; between clusters there are gateway agents that enforce inter-cluster policy.

- Trust concentration: distributed (per-cluster), with gateway agents as enforcement choke points. - Audit trail: clean within cluster, gateway-mediated between clusters. - Failure mode: gateway compromise. Single-cluster compromise can be contained; gateway compromise crosses clusters. - Where seen: regulated industries (healthcare, finance) where data-residency, role-separation, or jurisdiction requirements force the boundary; emerging in cross-organizational agent ecosystems.

3.4 Hierarchical

Agents are organised in supervisor/worker relationships. Higher-level agents allocate work to lower-level agents, review outputs, and report up. Supervisor agents may themselves be supervised by humans or by higher-level supervisors.

- Trust concentration: layered. Each layer mediates the layer below. - Audit trail: structured (the hierarchy gives natural rollup points). - Failure mode: supervisor failures cascade downward; lower-level failures are usually contained by the supervisor unless aggregation occurs across many lower-level agents simultaneously. - Where seen: complex task automation, agentic research assistants (the planner-worker pattern), some scientific computing pipelines.

3.5 The topology evaluation matrix

| Topology | Trust concentration | Audit-trail tractability | Dominant failure mode | Best for | |---|---|---|---|---| | Hub-and-spoke | Single point | High | Orchestrator compromise | Limited scope, high audit needs | | Mesh | Distributed | Low | Cascade | Research, low-stakes flexibility | | Federated | Per-cluster | Medium-high | Gateway compromise | Regulated, multi-domain | | Hierarchical | Layered | High | Supervisor compromise (top-down) | Complex tasks, planner-worker |

A consequence of this matrix: the right topology is determined by where the organization's audit and compliance load actually sits. A bank with regulatory rollup requirements needs hierarchical or federated; a research lab can run mesh; a customer-service automation can run hub-and-spoke. The marketing claim "multi-agent" does not tell the evaluator which of the four is being shipped.

---

4. Agent identity — why SSO does not transfer

The second claim: agents need identities, but agent identity is not user identity. The institutional muscle memory around human IAM — long-lived accounts, role-based access control (RBAC), single sign-on (SSO), refresh tokens — was built for an entirely different subject. Applying it to agents produces three specific failure modes.

4.1 The lifecycle mismatch

A human identity persists for years. An agent identity may persist for a single task, a single session, or a single function call. Standard SSO infrastructure is not designed for the velocity of agent creation and destruction. Issuing a long-lived bearer token to an ephemeral agent is over-permissioning; treating an agent as a service account fails to capture the scope-precision the agent actually needs.

4.2 The capability-precision mismatch

A human's permissions are coarse-grained because humans interpret context. An employee with "read access to customer database" is implicitly bounded by their professional judgment, role expectations, and the prospect of personnel review. An agent with the same permission has none of those bounds.

The right substitution is fine-grained capability tokens — each agent invocation receives only the capabilities required for the specific task, scoped by: - Action: read, write, delegate, terminate - Resource: specific record IDs, specific endpoints, specific data fields - Time: expiry within seconds or minutes - Audit identifier: the chain of agent invocations that requested this capability

This is recognisably the macaroon model (Birgisson et al. 2014), capability-based security (Levy 1984), and zero-trust principles (NIST SP 800-207) applied to the agent layer. The infrastructure to do this exists. What is missing is the institutional habit.

4.3 The revocation mismatch

A human caught misbehaving can be told to stop, walked out by HR, escorted off premises. The lag from detection to revocation may be hours or days but the human is one entity. An agent caught misbehaving may have already invoked 50 other agents in the last second, each of which may have invoked further agents. Revocation needs to be transitive — when agent A is revoked, every agent invoked by A in the current capability chain is also revoked.

Real-time transitive revocation is not solved at production scale in 2026. We name it explicitly as an unsolved orchestration problem. Until it is solved, scope-of-action containment at deployment time is the only reliable defence: agents should never have permissions broad enough that real-time revocation would matter for the catastrophic case.

4.4 The recommendation: replace agent SSO with capability tokens + chain audit

For each agent invocation, issue a short-lived (seconds-to-minutes) capability token scoped to the specific task. The token carries the agent's chain identifier — the sequence of upstream invocations that requested this capability. Tokens are not renewable; new tasks require new tokens. Misbehaviour detection triggers chain-wide revocation by chain identifier, not by agent identity.

This replaces agent SSO with task SSO. The agent never "logs in"; each task does. The audit trail becomes the canonical identity artifact.

---

5. Bounded delegation — the orchestration discipline

The third claim: bounded delegation is the only orchestration discipline that scales without producing aggregation risk.

Definition. Bounded delegation is the rule that any agent A invoking another agent B can transfer to B only capabilities that A itself currently holds; B must request capabilities explicitly; A's audit trail accumulates B's audit trail; and A is held accountable for actions B takes under capabilities A granted.

This is the agent-layer analogue of the principle of least privilege (Saltzer & Schroeder 1975) applied to delegation. It has four practical consequences.

5.1 Capability monotonicity

Capabilities can only narrow as the delegation chain extends. A customer-triage agent invoking a billing agent cannot grant the billing agent capabilities the triage agent does not itself hold. The audit trail makes this verifiable: if a billing agent acted under a capability never granted to the triage agent, the orchestration discipline was violated.

5.2 Explicit capability request

Delegated agents must request the specific capabilities they need, not receive blanket access. This forces the orchestration layer to make capability granting an auditable decision rather than an implicit transfer.

5.3 Audit-trail accumulation

When agent A invokes agent B, B's audit trail is concatenated to A's. The full chain — A invokes B invokes C invokes D — becomes a single auditable artifact. Aggregation analysis (what did agents collectively do under this user request?) becomes tractable.

5.4 Accountability locus

When something goes wrong, the audit trail identifies which agent in the chain held the capability that was misused. Accountability tracks back through the granting decisions, not just to the agent that acted. This produces the structural pressure that prevents permissive capability granting.

5.5 Aggregation risk — the dominant unsolved problem

Even with bounded delegation, aggregation risk remains the hardest problem in 2026 multi-agent deployment.

Aggregation risk: many agents each with small, individually-defensible permissions collectively performing an action no single agent was authorized for.

A canonical example: a fraud-detection agent (read access to transactions), a customer-profile agent (read access to demographics), a marketing agent (read access to engagement data), and a recommendation agent (write access to customer communications) each have permissions that individual auditors would find defensible. Composed in a chain — fraud agent flags a customer, profile agent enriches the flag, marketing agent generates a "we noticed unusual activity, please confirm" message, recommendation agent sends it — the system performs unauthorized profiling and pretextual surveillance.

Bounded delegation makes aggregation risk auditable (the chain is logged), but does not make it detectable in advance. The problem is the same one that has dogged compositional analysis of privacy in human systems: each step is fine, the composition is not.

We propose three partial mitigations, none of which is sufficient alone:

1. Topology constraints — disallow certain agent-to-agent invocation patterns at deployment time. A marketing agent should not be invokable by a fraud-detection chain. This is a static analysis problem, tractable. 2. Capability-class compatibility rules — define classes of capability (read-personal, write-customer-comms, etc.) and prohibit certain class combinations in a single audit chain. 3. Aggregation-aware monitoring — log capability-class compositions and surface novel compositions for review. This is reactive but tractable.

The honest position: aggregation risk is not solved in 2026, will not be solved in 2026, and is where the next class of multi-agent incidents will originate.

---

6. Cross-organizational coordination

When agents from Organisation A interact with agents from Organisation B, the orchestration question crosses a regulatory and trust boundary that the single-organisation orchestration discipline does not address.

6.1 The treaty problem

Two organisations running multi-agent systems eventually need cross-organisational protocols: a fraud-detection agent at one bank needs to query a counter-fraud agent at a partner bank; a healthcare scheduling agent needs to negotiate with an insurance-verification agent. Standard institutional patterns (B2B integrations, OAuth-based service-to-service authentication, EDI) were not designed for the velocity and the audit needs of agent-to-agent traffic.

A cross-organisational agent treaty would specify, between two organisations: - Which agent classes from A can invoke which from B - What audit trail must be preserved by each side - What revocation events must be signalled across the boundary - What capability-class composition rules apply jointly

This is structurally an agent-layer FIDO Alliance or agent-layer Open Banking — protocol standards plus a governance body that defines conformance tiers, trust certification, and cross-org policy arbitration. The protocol layer has emerged: the Model Context Protocol (MCP) and the Agent2Agent (A2A) Protocol are both now governed by the Linux Foundation (MCP via the Agentic AI Foundation since December 2025; A2A under direct Linux Foundation stewardship since June 2025; A2A v1.0 shipped early 2026 with Signed Agent Cards and the Agent Payments Protocol extension, adopted by 150+ organizations). What does not yet exist is the policy layer above them — the trust-tier certification regime, the aggregation-rule arbitration body, the cross-jurisdictional treaty framework. The wire format is governed; the cross-org policy is not.

6.2 The asymmetric trust problem

When organisations have asymmetric trust postures — one has strong audit discipline, the other does not — cross-org coordination defaults to the weaker discipline. The organisation with strong audit needs is forced to accept exchanges with the weaker side or refuse the integration.

The asymmetric-trust problem mirrors the supply-chain attack vector: the weakest link in the agent chain becomes the attack surface for the whole composition.

Mitigations require inbound capability scoping by audit-discipline tier — accepting cross-org invocations only at capability scopes proportionate to the inviting organisation's audit posture. Organizations with weaker discipline get narrower capability access. This is implementable; what is missing is the trust-tier registry to enable it at scale.

---

7. The audit trail as trust artifact

A recurring theme across §3-6: the audit trail is not a byproduct of multi-agent operation; it is the primary trust artifact.

In single-agent deployment, the agent's behaviour is the trust artifact — what it does, how it explains itself, what it refuses. In multi-agent orchestration, no single agent's behaviour is the artifact; the composition is. The audit trail is the only thing that captures composition.

7.1 What this implies operationally

- Audit trail integrity is a security requirement, not an ops convenience. Tamper-resistance, append-only logging, cryptographic chaining (Merkle-trees, blockchain-style structures where appropriate) become first-class. - Audit trail retention duration is a regulatory question. Some regulatory regimes (financial services, healthcare) require multi-year retention; some agent vendors offer days or weeks. The mismatch is a compliance liability. - Audit trail accessibility to the deploying organisation must be guaranteed by contract. Many SaaS agent platforms hold audit data on the vendor's infrastructure; organizations that cannot retrieve their own audit data at vendor termination are exposed.

7.2 What this implies strategically

For organizations evaluating agent vendors and orchestration platforms in 2026: the vendor's audit-trail discipline is the strongest single indicator of whether the platform is deployable. Capability claims, model benchmarks, demo polish — none predict deployment outcome the way audit-trail discipline does. The vendor that can answer "show me the audit trail for the action this agent took six months ago" with the actual artifact is qualitatively different from the vendor that cannot.

7.3 What this implies for the SomaSoft audit methodology

The audit methodology developed in our earlier work (Nafe 2026c, 24-entry ledger) was built around single-system architectural decoration. Extending it to multi-agent orchestration produces three new ledger-entry classes:

- Orchestration decoration — claims about topology that do not survive trace audit (e.g., a vendor claims hub-and-spoke but the actual call graph is mesh) - Identity decoration — claims about capability scoping that do not survive token inspection (e.g., capability tokens carry broader scope than the documentation claims) - Audit decoration — audit trails that exist but cannot be inspected, queried, or correlated with reasonable effort

These three become a natural extension of the single-system ledger and are observable from outside the vendor's infrastructure with reasonable instrumentation.

---

8. The 27-behavior rubric extended to orchestration

The Paper #1 rubric was structured for single-agent evaluation. The orchestration-layer extension adds the following observable behaviors:

Green-flag additions (orchestration-friendly):

- G9 — Published topology diagram with audit-trace correspondence. Vendor states topology and the audit traces match the stated structure. - G10 — Capability-token sample available. Vendor can produce a representative capability token showing the scope, expiry, and chain identifier fields. - G11 — Cross-agent audit-trail correlation tooling. Vendor or platform provides tools to follow an action through the agent chain that produced it. - G12 — Documented revocation procedure with stated lag. Vendor names the time from misbehavior detection to chain-wide revocation. Naming it (even if it is hours) is qualitatively better than not.

Yellow-flag additions (incomplete but tractable):

- Y8 — Cross-organizational interaction patterns not fully documented. Vendor offers cross-org integrations but cannot fully describe the trust-tier mapping. - Y9 — Audit retention period shorter than regulatory floor in target industry. May indicate vendor-side cost optimization at organisation-side compliance expense. - Y10 — Aggregation-risk monitoring exists but is reactive, not proactive. Vendor surfaces unusual capability compositions after the fact; static analysis at deployment time is not offered.

Red-flag additions (orchestration-hostile):

- R13 — Mesh topology without per-pair authorisation rules. Any agent can invoke any other agent with default policy; aggregation risk is structural. - R14 — Long-lived capability tokens. Tokens persist past task duration; this is RBAC-for-humans applied to agents and produces capability accumulation. - R15 — Audit trail hosted only on vendor infrastructure with no contractual export guarantee. Organisation cannot retrieve its own audit data on vendor termination. - R16 — Cross-org integrations without documented trust-tier policy. Asymmetric-trust failures will accumulate.

The total rubric is now 39 behaviors (14 green, 9 yellow, 16 red) when orchestration is in scope. The framework remains observable, evaluable, and citation-grounded.

---

9. Recommendations

For three distinct audiences, the framework supports the following operational positions.

9.1 For organizations deploying multi-agent systems

1. Choose topology before choosing vendor. The right topology is a function of the organization's audit and compliance load, not the vendor's preferred architecture. Hub-and-spoke for limited scope, federated for regulated multi-domain, hierarchical for complex tasks, mesh only when audit is genuinely not required. 2. Demand capability-token sample from any prospective vendor. Inspect the scope, expiry, and chain identifier fields. Reject vendors who cannot produce a representative token. 3. Negotiate audit-trail export and retention into the master contract. Default vendor terms are insufficient for regulated industries. 4. Run a deployment-time aggregation-risk analysis. Map capability-class compositions across the agent set; identify combinations that would compose into unauthorized actions. Disallow those compositions structurally. 5. Plan for revocation lag. Assume real-time transitive revocation is not available; size scope-of-action accordingly.

9.2 For agent and orchestration vendors

1. Publish the topology diagram and prove correspondence to the call graph. Decoration in the documentation will be caught by the first thorough audit. 2. Issue capability tokens, not session credentials. The institutional habit of OAuth-for-everything must be broken for agent identity to scale. 3. Invest in audit-trail tooling as a product feature, not an ops afterthought. The vendor that can answer audit queries six months later wins enterprise procurement in 2026. 4. Document revocation procedure and stated lag. Even a multi-hour lag, honestly stated, is better than implied real-time revocation that does not exist.

9.3 For regulators

1. Treat orchestration as a regulatory object distinct from individual agent capability. Current frameworks (EU AI Act, NIST AI RMF, ISO 42001) address agents largely as individuals; orchestration risk needs its own treatment. 2. Require audit-trail integrity, retention, and export portability in regulated industries. Vendors will optimise away from these unless required. 3. Create cross-organizational agent-treaty frameworks. The agent-layer equivalent of FIDO Alliance or Open Banking governance does not exist; the regulatory window to shape it is now. 4. Recognize aggregation risk as a distinct regulatory category. Single-action authorization analysis will miss the composition cases that produce the next class of incidents.

---

10. What this paper is not claiming

Per the SomaSoft audit discipline:

- We are not claiming bounded orchestration is sufficient for safe multi-agent deployment. It is necessary, not sufficient. - We are not claiming any specific organisation's deployment matches or fails to match this framework. We have not audited any commercial system. - We are not claiming the agent-layer FIDO Alliance equivalent we describe will form, or that any specific organisation will lead it. We are claiming the gap exists. - We are not claiming the 39-behavior extended rubric is final. It is a working version, open to refinement by other practitioners.

The contribution is the framework, applied at the level the orchestration evaluator can use, with the audit discipline that makes the framework verifiable. Specific verdicts on specific systems belong to those organisations and to the audits they choose to commission or accept.

---

11. Conclusion

The single-agent question — is this agent safe? — has been the focus of the 2026 agentic AI research conversation. The single-agent question is not the deployment question. The deployment question is structural: which agent can invoke which, what each is allowed to do, how the chain is logged, how failures propagate, how revocation works, and how cross-organisational coordination is governed.

We have extended the 4-level taxonomy and 27-behavior rubric to org-level multi-agent orchestration. The contribution is a topology framework, an agent-identity model that distinguishes from human SSO, a bounded-delegation discipline, an account of aggregation risk as the dominant unsolved problem, and a recognition that the audit trail itself becomes the primary trust artifact in multi-agent operation. The framework is implementable without infrastructure cost, applies across vendor stacks and industries, and remains observable to external auditors.

The framework is not novel in every part. Bounded delegation echoes capability-based security; capability tokens echo macaroons and zero-trust; topology classification echoes distributed-systems literature. The contribution is the combination, applied at the level the multi-agent evaluator needs, and bound to the audit discipline that survived the SomaSoft program's own 24-entry ledger.

Organizations standing up agentic AI in 2026 face a regulatory environment built for single agents. The orchestration discipline this paper proposes is implementable today. The institutional question — whether organizations will commit to bounded orchestration before deployment or learn it after the first incident — is the open one.

> The single agent is not the deployment unit. The composition is the deployment unit. The composition is what must be audited.

---

References

Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A., Vrable, M., & Lentczner, M. (2014). Macaroons: Cookies with contextual caveats for decentralized authorization in the cloud. Network and Distributed System Security Symposium.

European Parliament. (2024). Regulation (EU) 2024/1689 — Artificial Intelligence Act.

Levy, H. M. (1984). Capability-based computer systems. Digital Press.

Nafe, M. (2026a). What to Watch For: A Behavioral Taxonomy for Evaluating Agentic AI Systems and Their Self-Modification Claims. SomaSoft Research, May 18, 2026. papers/PhD_PAPER_AGENTIC_BEHAVIORAL_TAXONOMY_SOMASOFT_20260518.md.

Nafe, M. (2026b). Mythos Through the Four-Level Taxonomy: A Behavioral Audit of Anthropic's Vulnerability-Finding Agent. SomaSoft Research, May 19, 2026. papers/PhD_PAPER_MYTHOS_AGENTIC_AUDIT_SOMASOFT_20260519.md.

Nafe, M. (2026c). What Counts as Working? An Audit Protocol for Detecting Confabulation in Autonomous Multi-Agent Systems. SomaSoft Research / AIES 2026 submission. papers/AIES_2026_full_paper.md.

NIST. (2020). Special Publication 800-207: Zero Trust Architecture.

NIST. (2023). AI Risk Management Framework (AI RMF 1.0).

Linux Foundation, Agentic AI Foundation. (2024-2026). Model Context Protocol (MCP) Specification. Originally introduced by Anthropic, November 2024; donated to the Agentic AI Foundation (AAIF) within the Linux Foundation, December 2025. Specification versioned by date (e.g., 2024-11-05, 2025-11-25). [https://modelcontextprotocol.io/specification](https://modelcontextprotocol.io/specification).

Linux Foundation. (2025-2026). Agent2Agent (A2A) Protocol. Originally published by Google, April 2025; contributed to the Linux Foundation under Apache 2.0 license, June 2025; v1.0 released early 2026 with Signed Agent Cards and Agent Payments Protocol (AP2) extension. Adopted by 150+ organizations including Microsoft, AWS, Salesforce, SAP, and ServiceNow.

Saltzer, J. H., & Schroeder, M. D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278-1308.

Tyler, T. R. (2006). Why people obey the law. Princeton University Press. [Cited for procedural-justice framing applicable to cross-org agent treaties.]

US Federal Trade Commission. (2025-2026). 6(b) inquiry into AI agent products and platforms.

---

License. This work is released under the Symbiotic AGI License v1.0 (SAGL-1.0) — see LICENSE_SAGL_v1.md in the project repository and at somasoft.ai/license. Permissive use with eight binding ethical-use restrictions; 20% Universal Benefit Fund contribution applies above USD 10,000/year commercial revenue. Copyright (c) 2025-2026 Mark Nafe / SomaSoft / AURI Project Contributors.

Provenance. This paper was written with the assistance of an LLM-driven coding agent (Claude Code, May 2026), which is itself a documented source of Mechanism A confabulation in this program's audit ledger. Every concrete claim about industry standards, specification documents, or institutional patterns binds to a publicly cited source. The paper makes no claims requiring inside knowledge of any commercial organisation's agentic systems. Readers should challenge specific claims rather than the document as a whole.