Multi Agent AI Security: Trust Boundaries and Control Design

Multi agent AI security is not one agent control copied many times. It is trust boundary control across every handoff.

When one agent delegates to another, the workflow crosses identity, authority, data, message, state, and recovery boundaries. A valid request can still ask for the wrong skill, carry excessive context, use a credential outside its purpose, trigger too many peers, or leave no reliable path back to the initiating person.

The receiver should not trust the sender because both belong to the same platform. It should authenticate the caller, verify message integrity, validate the task and data, make a local authorization decision, constrain any tool or peer action, record the result, and remain revocable.

Start with the Agentic AI hub, use the AI Agent Risk Assessment to prioritize scenarios, and use Securing AI Agents for single agent identity and permission design. This guide covers the additional control pressure created by delegation and propagation. GS Consulting integrates that work into a secure enterprise AI strategy.

Multi Agent AI Security: The Short Answer

Secure a multi agent system by treating each exchange as an independent trust decision. Give every operational agent a verifiable identity. Bind delegated authority to the initiating subject, acting agent, purpose, scope, audience, task, and expiry. Validate the message schema, integrity, data labels, content, size, replay state, and protocol version. Let the receiver apply its own policy to the requested skill, data, tool, and action. Limit delegation depth, peer fan out, retries, spend, time, and external effects. Record the entire chain under a common task identifier. Exercise coordinated pause, revocation, containment, rollback or compensation, reconciliation, and safe resume.

A protocol is part of the answer, not the operating model. A2A can structure messages, tasks, discovery, authentication requirements, and authorization behavior. MCP can structure how clients reach tools and protected resources. OAuth token exchange can preserve delegation information. None of them decides which business action is acceptable, which data may cross, how much propagation is safe, or who owns the incident.

The simplest architecture that meets the need is usually easier to secure. If an orchestrator can coordinate narrow specialist agents, do not create a peer mesh merely because the framework supports it. Every extra communication path increases policy, monitoring, test, and recovery work.

Find the Trust Boundaries in the Workflow

A trust boundary exists wherever identity, data, authority, or state moves into a component with a separate policy or owner. In a multi agent workflow, boundaries commonly appear between a user and orchestrator, orchestrator and specialist, peer agents, agent and tool, agent and shared memory, agent and message bus, agent and external provider, callback and receiver, approval interface and action service, and result storage and later consumers.

Draw each boundary as a directed exchange. Record the sender, receiver, message or artifact, schema, identity, delegated subject, credential, requested capability, data classes, policy enforcement point, state created, allowed next hops, logging location, revocation path, and recovery owner. A box and arrow diagram becomes useful only when those fields are attached to the arrow.

Distinguish authentication from authorization. Authentication establishes who or what presented the request. Authorization decides whether that identity, subject, purpose, scope, task, data, action, and context are allowed now. An authenticated agent can still be compromised, confused, excessive, stale, or acting outside the user intent.

NIST SP 800-207 gives the right baseline: do not grant implicit trust from network location or ownership. Apply explicit policy to the resource and current context. For agents, shared orchestration does not remove the need for that decision.

Choose an Orchestrator or Peer Pattern Deliberately

Orchestrator with specialists. One coordinating agent assigns narrow work to agents with defined capabilities. The pattern centralizes task state, policy, fan out limits, and the operating record. It can create a dangerous concentration of authority if the orchestrator holds broad credentials or can silently rewrite delegated goals.

Peer collaboration. Agents discover and delegate to one another directly. The pattern can improve flexibility and resilience, but it creates more communication paths, distributed policy decisions, harder attribution, and wider recovery coupling. Every peer needs a reliable way to verify identity, authority, message integrity, protocol version, and allowed next hops.

Federated agents. Agents cross organizational, tenant, provider, or contractual boundaries. This is the hardest pattern because identity assurance, policy language, data handling, logging, incident response, and evidence quality may differ. Treat external federation as a supplier and trust decision, not merely a network connection.

Architecture should follow the task. A research workflow may use one orchestrator and three read only specialists with no direct peer exchange. A distributed incident workflow may need peers, but their authority and containment must reflect the consequence. If the business case does not justify the extra paths, keep them closed.

Public Specifications Expose the Real Control Work

The current A2A Protocol specification treats agents as enterprise applications. It requires encrypted production communication, requires authentication of incoming requests, and leaves authorization to the receiving server based on its own policy. That policy may consider the requested skill, action, data, and OAuth scope.

A2A also supports authorization requests during a task. Its security discussion warns that credentials passed through a chain can be exposed to each participating agent. It recommends binding credentials to the agent that originated the request and protecting sensitive credential content. The specification does not define the scope, validity, or revocation semantics of the resulting authorization decision. Operators still own those choices.

The MCP authorization specification requires clients to identify the intended resource and servers to validate that tokens were issued for them. It forbids an MCP server from accepting or transiting tokens meant for another resource. This is a concrete control against token passthrough, but tool permissions and business policy remain local responsibilities.

The joint NSA and international partner guidance recommends unified audit logs for inter agent interactions, containment, rollback, red testing, and incremental deployment. The guidance is not a substitute for a system specific assessment, but it makes accountability and recovery part of the architecture rather than an afterthought.

Original Research: The GS Multi Agent Trust Boundary Pressure Index

GS Consulting's derived model shows that external federation, shared credentials, and shared memory create the most concentrated control pressure.

We scored ten common trust boundaries on six ordinal factors from one to five: identity ambiguity at 20 percent, delegated authority at 20 percent, data reach at 15 percent, action propagation at 20 percent, state persistence at 10 percent, and recovery coupling at 15 percent. The weighted result is a zero to 100 planning score.

External agent federation scores 95. A shared credential or token chain scores 93. Shared memory or context scores 88. Agent to tool execution scores 82. Peer agent direct task handoff scores 75. Asynchronous callback or webhook scores 73. Orchestrator to specialist delegation scores 71. Agent discovery and registry scores 63. Human approval round trip scores 62. Result return and artifact storage scores 55.

The lower values do not mean a boundary is safe by default. They indicate lower combined pressure under the modeled assumptions. A result store holding regulated records or an approval interface that can authorize an irreversible action may need stronger local ratings.

The alternate model shifts weight from delegation and propagation toward identity and recovery. Every boundary moves by three points or less, and the top three stay in the same order. The ranking is stable enough to guide sequencing but remains a GS planning judgment.

The GS Multi Agent Trust Boundary Pressure Index is a derived planning tool. It is not an official NIST, NSA, OWASP, A2A, MCP, IETF, legal, audit, compliance, certification, or regulatory determination. Replace the model inputs with evidence from the actual architecture and operating context.

Score Six Boundary Factors

Identity ambiguity. Can the receiver prove which agent, workload, tenant, organization, version, and environment called? Can it distinguish the agent from the initiating human or service? Can operators revoke that caller without disabling unrelated work?

Delegated authority. Can the receiver trace the authority to a subject, actor, purpose, scope, audience, task, and expiry? Does it know whether the agent is acting on behalf of a user, another agent, or itself? Can the receiver narrow the request?

Data reach. What prompt content, context, memory, artifacts, files, task history, personal data, regulated data, credentials, and derived information cross the boundary? What is retained, and who can retrieve it later?

Action propagation. Can one accepted request trigger tools, peers, external messages, code, changes, purchases, access decisions, or more delegations? Set depth, fan out, retry, rate, spend, time, and consequence limits before the first handoff.

State persistence. How long do tasks, subscriptions, callbacks, memory, cached capability records, credentials, artifacts, and logs survive? What invalidates them after a user, policy, agent, model, protocol, or permission change?

Recovery coupling. How many agents, credentials, tasks, tools, data stores, callbacks, and downstream systems must be paused, revoked, repaired, reconciled, and resumed together? Recovery pressure rises when each component owns a different task identifier or clock.

Give Each Agent an Identity and Each Delegation a Bound

Every operational agent should be identifiable enough to support authentication, least privilege, attribution, lifecycle management, and selective revocation. The exact mechanism depends on the platform, but the record should distinguish agent, workload, tenant, owner, version, environment, and status. Do not rely on a friendly display name in a prompt or message.

A shared service identity can make implementation easy and incident response painful. It hides which agent acted, expands the value of one credential, and forces broad revocation. When a shared identity cannot be avoided, compensate with narrow audiences, task bound credentials, separate policy scopes, strong message identity, and complete action attribution.

Delegation must preserve intent. IETF RFC 8693 distinguishes delegation from impersonation and supports token forms that identify both the subject and the actor. That distinction matters. The downstream service should know who benefits from the action and which agent is performing it.

Carry purpose, audience, scope, task identifier, expiry, and constraints with the delegation. The receiving agent should make its own decision. It may allow a narrower scope, request new authorization, require human review, or deny the task. A sender should not be able to declare its own authority final.

The preliminary NIST NCCoE concept paper on agent identity asks how agents prove authority, convey intent, adapt authorization to changing context, handle aggregated data, bind to human approval, and preserve verifiable action records. These are open implementation questions, not settled requirements, but they define the evidence a credible design should address.

Treat Messages, Context, and Memory as Untrusted Inputs

A message from an authenticated peer is still data. Validate it against the expected schema, task state, protocol version, content type, size, allowed fields, data labels, freshness, sequence, and replay rule. Verify signatures where used. Reject unknown capabilities and unexpected next hops.

Separate instructions from untrusted content where the architecture permits. A peer may pass a document that contains malicious text without being compromised itself. The receiving agent should know which fields express the delegated task, which carry evidence, which are human supplied, and which came from external sources.

Minimize context. Do not send the entire conversation, memory store, source corpus, or user profile because the next agent might need part of it. Send the fields required for the task, preserve provenance, and enforce data rules at the receiver. An encrypted message can still contain excessive data.

Shared memory is a high pressure boundary because it combines data reach, persistence, and propagation. Namespace it by tenant, workflow, agent, user, task, and purpose as needed. Validate before write and before read. Set retention and deletion. Record provenance and version. Prevent one agent from turning untrusted content into trusted memory for every peer.

Agent discovery deserves the same care. The A2A specification supports Agent Cards that describe capabilities and authentication. Cache and version rules matter. Verify the endpoint and signature where available, restrict which registries are trusted, and do not treat a declared skill as authorization to use it.

Keep Agent, Tool, and Credential Boundaries Separate

An agent to agent request and an agent to tool request are different security decisions. A specialist may be allowed to analyze a file without receiving the credential needed to change the source system. Keep tool authority at the narrowest component that needs it.

Use resource specific tokens and validate audience. The MCP authorization specification requires the target resource in authorization requests and requires an MCP server to reject tokens not issued for it. Do not pass a user token through a chain of agents and tools as a convenience. Each exchange should receive authority suited to its purpose and audience.

Limit parameters, not only tool names. Permission to call “update record” can still be excessive if the agent may select any record, field, value, tenant, or volume. Enforce allowed targets, fields, value ranges, time windows, rates, spend, and change size outside the model.

Credentials should expire, rotate, and revoke. Record issuance, subject, actor, audience, scope, task, time, and use. Keep them out of prompts, messages, task history, memory, traces, and logs. A credential that appears in context can propagate farther than the action it was meant to support.

AI access control and permission design provides a deeper control pattern for identities, roles, purpose, tools, approval, and revocation.

Use a Five Step Secure Handoff

1. Authenticate each caller. Verify the server, client, agent, workload, tenant, protocol, and channel before accepting a task. Do not infer identity from message text.

2. Bind the delegation. Preserve the initiating subject, acting agent, purpose, requested scope, audience, expiry, task identifier, and constraints. Refuse a request that cannot explain its authority.

3. Validate the exchange. Enforce schema, integrity, data labels, content rules, size, sequence, freshness, replay protection, and protocol version. Treat files, links, artifacts, peer output, and retrieved context as untrusted until checked.

4. Authorize the receiver. Apply local policy to the requested skill, data, tool, parameters, target, consequence, and current context. The receiver may narrow, pause, escalate, or deny.

5. Record and recover. Link the request, decision, messages, peer calls, tool actions, approvals, outputs, results, errors, revocation, rollback, and resume under one traceable task. Keep sensitive content out of logs unless the evidence requirement justifies and protects it.

Limit Propagation and Exercise Coordinated Recovery

Set a maximum delegation depth and peer fan out. Set rate, retry, cost, time, data volume, and action limits. Require explicit permission for external federation. Detect new peers, changed capability records, unusual task creation, repeated denial, excessive cancellation, unexpected tools, and tasks that continue after their parent stopped.

Use segment boundaries so one compromised agent cannot reach every peer, tool, memory store, or tenant. Keep high consequence agents in smaller trust zones with stricter policy and stronger observation. Separate research, drafting, execution, and approval roles where that separation reduces authority.

Use one task and trace identity across the chain. Each event should record the local agent and the initiating subject without losing actor history. A unified trail supports investigation, but it also supports live containment: operators can find active descendants, revoke their credentials, cancel callbacks, quarantine artifacts, and block downstream action.

Recovery has to reconcile distributed state. A parent may believe a task stopped while a child is still running. A callback may arrive after revocation. A shared memory item may remain poisoned after agents restart. Exercise coordinated pause, credential revocation, peer quarantine, tool disablement, rollback or compensation, memory repair, artifact review, task reconciliation, retesting, and safe resume.

A 2026 NIST presentation on emerging agent threats discusses message signing, mutual authentication, strict tool scopes, workflow bound tokens, memory isolation, segmentation, provenance, and testing for cascades. Treat it as informative material, not a formal NIST standard.

Six Multi Agent Security Failure Modes

Shared service identity. Agents become indistinguishable and one credential compromise affects the whole group.

Token passthrough. A credential moves beyond its intended resource and becomes reusable by intermediaries.

Unsigned discovery. A false or stale capability record redirects tasks, weakens authentication, or introduces an unexpected endpoint.

Unbounded context. Sensitive data, credentials, private instructions, and malicious content travel together through the chain.

Local only logs. Each agent records its own action, but no record reconstructs the subject, delegation, messages, decisions, peers, tools, and result together.

Independent recovery. One agent is repaired while descendant jobs, callbacks, memory, credentials, or downstream actions remain active.

Build One Multi Agent Security Evidence Packet

The agent identity record names owner, tenant, workload, version, environment, status, lifecycle, and revocation. The delegation record preserves subject, actor, purpose, scope, audience, expiry, task, and constraints. The capability record preserves skills, endpoint, schema, authentication, signature, version, and trust source.

The message control record documents integrity, replay, size, content, data, protocol, and rejection behavior. The receiver decision log records caller, subject, context, requested skill, policy, result, and reason. The action trail records the tool, target, parameters, effect, result, and actor.

The cascade monitor covers peer depth, fan out, new partners, retry, rate, anomaly, throttle, pause, and stop. The recovery exercise proves revocation, coordinated pause, rollback or compensation, memory and artifact repair, state reconciliation, retesting, and safe resume.

Connect every artifact with stable identifiers. The same task should be traceable from the initiating request through all child tasks and tool actions. AI audit trails and activity logging provides the event design. AI agent lifecycle management adds registration, ownership, change review, and retirement.

Implementation Sequence for a Multi Agent Workflow

• Week 1: bound one workflow, draw every trust boundary, and remove communication paths the task does not need.
• Week 2: assign agent identities, define delegation fields, set local authorization policy, and narrow tool credentials.
• Week 3: enforce schemas, integrity, data labels, memory scope, replay rules, protocol versions, and capability trust.
• Week 4: connect task and trace identifiers, add depth, fan out, retry, rate, spend, time, and consequence limits.
• Week 5: test malicious messages, poisoned context, token misuse, false discovery, policy denial, callback abuse, and cascade behavior.
• Week 6: exercise coordinated pause, selective revocation, quarantine, rollback or compensation, reconciliation, and resume.

Start with narrow read only collaboration. Expand one authority or boundary at a time. Each expansion should have a specific business value, owner, policy, test, monitor, recovery step, and approval. Do not move from a controlled orchestrator to broad peer discovery as a default maturity step. More connections are not the same as more capability.

The final standard is simple: no agent should accept a task it cannot authenticate, authorize, constrain, record, and recover from. If any receiver relies on inherited trust, the chain is not ready for production authority.

Research Sources and Method

The model uses public material from NIST, NIST NCCoE, NIST CAISI, the joint NSA partner guidance, OWASP, the A2A specification, the MCP authorization specification, and IETF RFC 8693. Protocol requirements and public observations remain separate from GS boundary definitions, analyst ratings, weights, and scores.

• NIST AI 800-5 security considerations response summary
• NIST NCCoE agent identity and authorization concept paper
• A2A Protocol current specification
• MCP authorization specification
• IETF RFC 8693 OAuth token exchange
• NIST SP 800-207 Zero Trust Architecture
• NSA and international partner agent adoption guidance
• OWASP Top 10 for Agentic Applications for 2026
• NIST presentation on agent threats and mitigations

Multi Agent AI Security FAQ

Related Reading

• Agentic AI Resource Hub
• AI Agent Risk Assessment
• Securing AI Agents
• AI Access Controls and Permission Design
• AI Audit Trails and Activity Logging
• AI Agent Lifecycle Management
• Secure Enterprise AI Strategy