Multi-Agent Security: Trust, Delegation and Confused Deputies

Multi-agent systems divide work among planners, specialists, reviewers and executors. This can improve modularity, but every handoff creates a trust decision. One agent may pass instructions, data or authority to another without a human seeing the transition.

Security cannot assume that an agent is trusted because another agent called it. Each participant may process untrusted content, use different tools and operate under different identities. Delegation must be explicit, narrow and attributable.

Inventory agents and roles

List every agent, owner, runtime, model, data source, tool, identity and maximum consequence. Distinguish fixed services from dynamically created subagents. Record which agents can discover or invoke others.

Names such as “reviewer” or “safety agent” do not establish independence. Determine whether agents share prompts, credentials, memory, model providers or orchestration code.

Map message and authority flows. A data-only handoff is different from delegating permission to execute.

Authenticate every participant

Give each agent workload a verifiable identity. Validate issuer, audience, environment and lifecycle. Do not rely on self-declared agent names in messages.

Preserve the initiating human or service through delegation. Downstream agents should know both who delegated and for whom the work is performed.

Revoke compromised agents independently. Avoid a shared credential that makes every action appear to come from the platform.

Separate instruction, data and authority

A message may contain a task, supporting data and requested capability. Keep these fields distinct. Untrusted content embedded in data should not become delegation.

Represent authority through trusted policy or narrow capabilities, not prose such as “the parent agent approved this.” Bind capability to operation, resource, tenant and expiration.

Test whether an agent can forge a parent instruction or modify delegation metadata.

Prevent confused deputies

A low-privilege agent may ask a powerful agent to perform an action it cannot do itself. The powerful agent must reauthorize the request using original user, task and resource context.

Do not infer permission from routing. Validate purpose and consequence. Apply approval where authority increases.

Test indirect prompt injection that causes one agent to enlist another. Follow the full path to downstream effect.

Constrain capability transfer

Delegated authority should be narrower than or equal to the delegator's current authority. Prevent agents from forwarding broad tokens. Use audience-bound, short-lived capabilities.

Limit redelegation depth and which agents may receive capability. Record the chain. Expire all descendants when the root task is cancelled or access is revoked.

Test token replay, alternate recipients, changed resources and delegation after role revocation.

Protect message provenance and integrity

Sign or otherwise authenticate messages where trust boundaries require it. Include sender, recipient, run, tenant, timestamp and purpose. Prevent replay and cross-session substitution.

Provenance should survive summarization. If an agent compresses ten messages, downstream systems still need to know which claims came from untrusted sources.

Treat artifacts—files, code, plans and tool results—as untrusted even when passed by an authenticated peer.

Isolate memory and state

Shared memory can become a hidden communication channel. Partition state by tenant, task and role. Apply write and read authorization. Label provenance and expiry.

Test whether a low-trust agent can poison memory consumed by a privileged agent. Verify cancellation and user deletion remove relevant state.

Avoid global scratchpads containing secrets or system prompts. The memory-poisoning guide provides detailed cases.

Control tools at each agent

Assign only tools required by each role. The planner may not need execution. The reviewer may need evidence but not write access. The executor should receive structured approved parameters.

Server-side enforcement remains necessary. Orchestration graphs and prompt roles are not authorization boundaries.

Review tool composition across agents. A reader and sender can combine to exfiltrate even if neither seems high risk alone.

Do not overtrust reviewer agents

An AI reviewer can help classify plans or outputs, but it may share model weaknesses, miss hidden context or be influenced by attacker-controlled content. Preserve raw evidence for human review.

Use explicit criteria and independent context where practical. Do not let the actor rewrite the evidence provided to the judge. Version prompts and models.

High-impact decisions should not depend solely on one probabilistic reviewer.

Control fan-out and resource use

An agent can create many subagents, model calls and tool operations. Set depth, breadth, duration, token and cost limits for the whole run. Detect cycles.

Cancellation should propagate to descendants. Queued work should verify the parent remains authorized. Rate limits per component are insufficient if an attacker fans out across many identities.

Test recursive delegation, duplicate tasks and agents that call each other.

End-to-end evidence

Correlate every agent message, delegation, capability, tool call, approval and effect with a run graph. Record observed facts separately from inferred relationships.

Security teams should reconstruct why a privileged action occurred and which untrusted input influenced it. Preserve message provenance through summaries and transformations.

Use evidence to replay confirmed failures as regression tests. The judge-scored attack-run research explains transcript-backed validation.

Multi-agent test plan

1. Forge another agent's identity or role.
2. Replay a valid delegation in another session.
3. Ask a privileged peer to bypass the caller's restriction.
4. Transfer capability to an unintended agent.
5. Poison shared memory or artifacts.
6. Inject instructions through inter-agent data.
7. Cause recursive fan-out or cycles.
8. Cancel a parent and observe descendants.
9. Compromise a reviewer or judge input.
10. Substitute tenant and resource identifiers.
11. Use permitted agents to compose an exfiltration path.
12. Reconstruct the complete path from evidence.

Security checklist

• Inventory every agent, role, owner and authority.
• Authenticate agents and preserve initiating identity.
• Separate messages, data and delegated capability.
• Reauthorize at every privilege boundary.
• Limit redelegation, recipients, depth and expiry.
• Preserve provenance and prevent replay.
• Isolate memory by tenant, task and role.
• Minimize tools for planners, reviewers and executors.
• Bound fan-out, cost and duration.
• Propagate cancellation and revocation.
• Keep reviewer output challengeable.
• Correlate the full run and downstream effects.

Frequently asked questions

Is a multi-agent system safer because roles are separated?

Not automatically. Separation helps only when identities, tools, memory and authority are actually isolated and enforced.

Can one agent approve another agent's action?

It can provide a review signal, but consequential authorization should come from trusted policy and qualified human approval where required.

What is the main multi-agent risk?

Delegation can launder untrusted instructions into privileged action, especially when downstream agents trust the caller without reauthorization.

How should multi-agent systems be logged?

Use a correlated run graph containing sender, recipient, provenance, delegated capability, tool decisions and final effects.

Multi-agent security is less about the number of agents than the quality of the boundaries between them. Continue with A2A security, agent identity and agent threat modeling.

Define roles without trusting role names

Planner, researcher, reviewer and executor are useful design labels, not security principals. Give each runtime identity explicit permissions based on its actual task. A component called “reviewer” should not automatically gain access to every transcript or tool.

Document which agents may create tasks, delegate them, modify shared state, approve actions and communicate externally. Enforce those rights in services rather than prompts. Test unknown and newly registered agents to ensure they receive no implicit trust.

Keep environment and tenant identity attached to every message. When an agent forwards content, provenance should survive instead of being replaced by the forwarding agent's reputation.

Secure task delegation

A delegated task needs a bounded objective, permitted resources, expiry and return channel. The child should receive no more authority than required, and never more than the parent may delegate.

Test task smuggling: untrusted content adds a second objective, changes the recipient or asks the child to create further agents. Validate structured task fields and reject unsupported instructions.

Cancellation and revocation must propagate. Confirm that children and queued work stop when the parent run ends. Short leases reduce the risk of disconnected workers acting indefinitely.

Protect inter-agent messages

Authenticate senders and authorize message types. Apply integrity protection where appropriate and prevent arbitrary agents from impersonating system, policy or human approval channels.

Treat message content as untrusted even when transport is authenticated. A compromised agent can send malicious instructions with valid credentials. Recipients should validate requests against their own policy and current delegation.

Control replay, ordering and duplication. Include message IDs and task state so retries cannot execute the same consequence twice. Bound message size and attachment formats to reduce parser and resource attacks.

Isolate shared memory and workspaces

Shared scratchpads improve collaboration but create hidden trust. Define who can read and write each object, and preserve author, source and timestamp. Prevent a low-trust researcher from rewriting the executor's policy.

Use separate tenant and run scopes. Test collisions, stale state and a child agent writing instructions that activate in a later task. Derived summaries should retain the sensitivity of their sources.

For filesystem workspaces, restrict paths, links and executable content. A shared file can become both data and a command channel if another agent automatically runs it.

Prevent consensus from becoming authority

Multiple agents agreeing does not prove correctness when they share the same model, prompt or poisoned source. Independence must be architectural, not cosmetic.

Use deterministic policy for permissions and consequence. A critic can flag risk, but it should not grant a credential or approve a transaction solely through natural language.

Test collusion and correlated failure by feeding the same poisoned evidence to every role. Observe whether one compromised component can shape the facts that all others evaluate.

Observe the distributed attack path

Create a trace that links parent run, child tasks, identities, messages, retrieved sources, tool calls, approvals and effects. Synchronized timestamps and stable IDs are essential.

Do not log unrestricted secrets merely for visibility. Record references and classifications, with protected access to raw evidence when investigation requires it.

Alert on unexpected delegation depth, new peers, authority increases, cross-tenant messages, repeated tasks and an agent calling tools unrelated to its role. Visualize the run graph so operators can contain descendants.

Test failure and compromise scenarios

Compromise one synthetic agent at a time and attempt to influence peers, steal context, expand delegation, poison memory and trigger tools. Then test two cooperating compromised roles.

Simulate unavailable agents, delayed messages, duplicate delivery and partial cancellation. Verify safe fallback instead of silent reassignment to a more privileged identity.

Preserve evidence of where the path stopped. A strong assessment identifies the boundary that held as clearly as the one that failed. Convert confirmed paths into multi-agent regression tests.

Govern a changing agent population

Maintain an inventory of agents, owners, models, prompts, tools and identities. Require review when a role gains a new peer or capability. Expire temporary agents and credentials automatically.

Version communication schemas and reject incompatible messages safely. Review third-party agents and frameworks as supply-chain components. Their updates can change behavior without a visible application release.

Run periodic access reviews based on observed use. Remove dormant delegation edges. Multi-agent systems remain governable only when the trust graph stays smaller and more explicit than the conversational graph.

Define multi-agent incident containment

Operators need to stop a parent, descendants, shared tools and queued work. Keep a run graph and propagate trusted cancellation independently of conversational messages.

Quarantine compromised agents and shared memory while preserving evidence. Rotate delegated credentials and identify messages or artifacts already consumed by peers.

Recovery should rebuild from verified configuration and clean state. Replay the attack with synthetic identities and confirm that delegation, messaging and tool controls now break the path.

Final review questions

Can every task, message and action be attributed to a runtime identity and originating tenant? Does each recipient independently validate authority? Can one compromised role modify policy, approval or shared state for another?

Check delegation depth, expiry, cancellation and token handling. Verify that duplicate or delayed messages cannot repeat effects and that unavailable agents do not trigger an unsafe privileged fallback.

Review the run graph with responders and ensure they can isolate descendants without losing evidence. Record model and framework limitations, then preserve representative cross-agent attacks as regressions whenever roles or communication schemas change.