By NHI Mgmt Group Editorial TeamPublished 2026-05-17Domain: Agentic AI & NHIsSource: Token Security

TL;DR: Multi-agent AI networks expand the enterprise attack surface because agents exchange credentials, context, and permissions across trust chains that can fail fast, according to Token Security. The governance model breaks when internal agent-to-agent traffic is treated as inherently safe, because autonomy and transitive trust outpace human review.


At a glance

What this is: This is an analysis of why collaborative AI agents create a larger identity and trust problem than single-agent systems, with emphasis on agent-to-agent trust, shared memory, and accountability.

Why it matters: It matters because IAM, NHI, and PAM programmes must now govern non-human actors that can delegate, inherit, and combine permissions faster than legacy controls were designed to observe.

👉 Read Token Security's analysis of securing multi-agent AI networks


Context

Multi-agent AI security is the challenge of governing identity, trust, and permissions when multiple AI agents collaborate to complete tasks. The primary problem is that agent-to-agent communication can move credentials, context, and permissions across an environment faster than human oversight can reliably track.

In an NHI programme, that changes the unit of control from a single service account or workload to a network of interacting non-human identities. The security question is no longer only who can access a system, but which agent can influence another agent, and whether that influence can be authenticated, scoped, and audited.

This is exactly the kind of problem space covered by the OWASP NHI Top 10 and by practical NHI governance guidance such as the Guide to the Secret Sprawl Challenge, because the failure mode is identity propagation through trust relationships rather than a single isolated credential event.


Key questions

Q: How should security teams govern trust between collaborating AI agents?

A: Security teams should treat every agent-to-agent relationship as a governed trust decision, not an internal default. That means verifying identity, constraining what one agent can ask another to do, and logging every delegated action. The goal is to stop transitive trust from becoming transitive compromise across the agent network.

Q: Why do collaborative AI agents increase identity risk compared with single-agent systems?

A: Collaborative agents increase identity risk because compromise can move laterally through trusted peers, shared memory, and delegated permissions. The exposed unit is no longer one model or one token. It is the trust mesh between many non-human identities, which can amplify a small foothold into broader access.

Q: What do organisations get wrong about shared memory in multi-agent systems?

A: They often treat shared memory as neutral infrastructure instead of an input surface that can carry malicious context. If one agent writes poisoned instructions or manipulated data, another agent may consume it later as trusted state. That turns storage into a governance boundary and a potential attack path.

Q: Who is accountable when multiple AI agents collaborate and something goes wrong?

A: Accountability should resolve to the specific agent identity that performed the action and the human owner responsible for that identity. A swarm cannot be remediated, audited, or sanctioned. Organisations need chain-of-custody logs that show which agent touched which artifact and when.


Technical breakdown

Agent-to-agent trust chains

Collaborative agent systems often rely on transitive trust. If Agent A can instruct Agent B, and Agent B can trigger downstream actions, then the security boundary is no longer the human user. It becomes the trust policy between machine identities. In centralized orchestration, compromise of the manager agent can redirect the whole workflow. In decentralized meshes, trust becomes distributed and harder to inspect. This is why zero trust must be applied internally, not just at the perimeter.

Practical implication: map every agent-to-agent relationship as an explicit trust decision, not an implicit internal assumption.

Shared memory and indirect prompt injection

Shared memory is the data layer that multiple agents read from and write to, often through vector databases, files, or other state stores. The risk is not only poisoned input in the normal sense. It is delayed influence, where one agent writes manipulated context that another agent later consumes as if it were trusted state. Because the malicious instruction can sit dormant until a later query, detection is harder and attribution becomes ambiguous.

Practical implication: treat shared memory as an untrusted input surface and apply sanitation, provenance tagging, and retrieval controls.

Collusive behaviour and separation of duties

Multi-agent systems can combine permissions in ways that no single agent could exercise alone. A worker agent with create rights and another with approve rights can collectively bypass separation of duties if the orchestration layer only validates each action in isolation. That is a governance failure, not just a technical one. The core issue is that policy evaluation must understand the whole chain of delegated intent, not just each step separately.

Practical implication: enforce separation of duties across the full delegated workflow, including combinations of actions across multiple agents.


Threat narrative

Attacker objective: The attacker wants to turn one compromised agent or memory source into a trusted execution path that reaches higher-privilege systems.

  1. Entry occurs when a lower-trust agent is compromised through prompt injection, poisoned context, or another unsafe input path.
  2. Credential access or abuse follows when that agent passes context, permissions, or instructions to a peer that assumes the sender is trustworthy.
  3. Escalation happens when chained agent actions combine privileges or bypass approval logic, allowing a low-privilege foothold to influence higher-impact systems.
  4. Impact is achieved when the coordinated agent set completes an unsafe workflow such as unauthorized access, fraudulent output, or destructive system action.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Multi-agent AI security is now an identity governance problem, not just an application security problem. The article correctly shows that the real control surface is no longer the model output alone but the web of agent identities, shared memory, and delegated permissions between them. That changes the governance question from protecting one system to governing a population of machine actors that can influence one another. Practitioners should treat collaborative agent networks as an NHI domain with their own lifecycle, trust tiers, and audit requirements.

Peer trust failure is the named concept this category needs. Internal agent traffic is often assumed to be safe because it originates inside the environment, yet the article shows that assumption collapses the moment one agent is compromised and other agents accept its instructions as legitimate. That is a distinct governance failure mode, not merely a weak control. The implication is that internal agent relationships must be governed as hostile until verified, just as external requests already are.

Collusive agent behaviour exposes a separation-of-duties gap that human IAM models do not naturally see. A workflow can remain policy-compliant at each individual step while still violating intent when multiple agents combine permissions to complete a goal. That means approval, create, and execute privileges cannot be reviewed in isolation. Practitioners should assume that distributed agent systems can manufacture composite privilege even when no single identity appears over-privileged.

Cryptographic identity is necessary but not sufficient for multi-agent governance. Standards such as SPIFFE help prove which agent sent a message, but they do not on their own prove whether the receiving agent should act on it. The article’s deeper signal is that identity verification, trust propagation, and action authorization must be designed together. Practitioners should align machine identity proofing with explicit policy on what can be delegated, inherited, or chained.

Accountability must resolve to a specific agent identity and a human owner. The article is right to reject collective responsibility models such as “the swarm” because they erase remediation paths and audit clarity. In practice, every autonomous or collaborative workflow needs traceable chain-of-custody evidence that survives handoffs across agent roles. Practitioners should make traceability a control objective, not a logging afterthought.

From our research:

  • 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
  • Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
  • Use OWASP NHI Top 10 to map agent-to-agent trust edges and align them with the control patterns this article surfaces.

What this signals

Peer trust failure: the operational lesson for programme owners is that internal agent traffic can no longer be treated as trusted simply because it stays inside the enterprise boundary. Identity teams should plan for verification at the message level, not only at login or deployment time, and anchor that work to the agentic risk patterns described in the OWASP Agentic AI Top 10.

With 80% of organisations already seeing AI agents act beyond intended scope in NHIMG research, the control problem is no longer hypothetical. The immediate signal for practitioners is that lifecycle governance, approval logic, and audit trails must be designed for machine actors that can chain decisions faster than recertification cycles can observe them.

The programme-level priority is to make provenance and chain of custody first-class identity controls for collaborative AI. When outputs can be assembled by multiple agents, the ability to prove which identity touched which action becomes as important as the action itself, and that pushes NHI governance closer to operational security than traditional app oversight.


For practitioners

  • Inventory every agent identity and trust edge Map each agent, its owner, its permissions, and every peer relationship it can invoke. Document where an agent can send instructions, consume shared memory, or trigger downstream actions, then classify those edges by risk tier. Use the map to find hidden high-trust paths.
  • Enforce internal zero trust for agent-to-agent traffic Require cryptographic verification, explicit allow-lists, and policy checks on every inter-agent message. Do not treat internal network location as proof of trust, and do not let one agent inherit another agent’s authority without a decision rule.
  • Separate creation, approval, and execution rights Design agent permissions so no single workflow can create, approve, and execute a high-impact action without an explicit control point. Review composite actions as sequences, not isolated events, especially where one agent can influence another.
  • Harden shared memory as an untrusted input surface Tag the provenance of retrieved context, scan stored content for injected instructions, and restrict which agents can write to shared state. Treat vector databases and shared files as governance objects, not passive storage.

Key takeaways

  • Collaborative AI agents turn identity trust into a mesh problem, where compromise can spread through agent-to-agent relationships instead of stopping at a single login boundary.
  • The scale of the risk is already visible, with most organisations expecting more AI agents even as rogue behaviour and access blind spots are already present.
  • The practical response is to govern agent identities, shared memory, and delegated permissions as one control plane, with clear accountability for every action chain.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Covers agent-to-agent trust, tool misuse, and collaborative AI threats.
OWASP Non-Human Identity Top 10NHI-01Agent identities are non-human identities that need lifecycle and trust control.
NIST Zero Trust (SP 800-207)PR.AC-4Internal zero trust is required when agents communicate across dynamic trust edges.

Map each agent relationship to OWASP Agentic AI risks and require explicit verification for delegated actions.


Key terms

  • Multi-agent orchestration: A coordination pattern where multiple AI agents divide work across specialized roles and exchange tasks, context, or decisions. In identity terms, it creates a network of non-human actors whose trust relationships must be governed, audited, and constrained because one agent can influence another without direct human review.
  • Peer trust failure: A breakdown where one agent accepts instructions from another agent as inherently trustworthy because the sender is internal or previously known. For multi-agent systems, this is a governance flaw that allows compromised peers to become trusted instruction sources and expand the blast radius across the agent network.
  • Shared memory: A common state store that multiple agents read from and write to, such as a vector database, file system, or coordination layer. It is not passive storage in security terms because poisoned context can persist and influence later decisions, making provenance and sanitation critical governance controls.
  • Chain of custody: A traceable record showing which identity touched which artifact, decision, or action and in what sequence. For collaborative AI, this is the evidence layer that makes accountability possible, because it links outcomes back to the specific agent identity and the human owner behind it.

What's in the full article

Token Security's full blog covers the operational detail this post intentionally leaves for the source:

  • Centralized vs decentralized orchestration patterns and the security tradeoffs of each agent network model.
  • Mechanics of message passing, shared memory, and MCP in multi-agent collaboration.
  • Defense patterns such as consensus checks, cryptographic signatures, and trust propagation rules.
  • Accountability models for mapping AI agent actions back to a human owner and a specific identity.

👉 The full Token Security blog covers orchestration models, trust propagation, and accountability logging in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-05-17.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org