AI agent orchestration security exposes new inter-agent attack paths

At a glance

What this is: This post argues that multi-agent AI orchestration creates a distinct security problem: trust can spread laterally between agents through messages, shared context, and over-broad tool access.

Why it matters: For IAM, NHI, and AI governance teams, the issue is not just model safety but identity, privilege, and auditability across agents that can amplify each other’s mistakes or abuse.

By the numbers:

• 82% of developers who use AI tools say they use them to write code.
• 68% of breaches involve the human element and mishandled access.
• The average breach cost reached $4.88 million in 2024.

👉 Read Knostic's analysis of AI agent orchestration security and multi-agent risk

Context

Multi-agent AI orchestration is the practice of connecting several AI assistants so they coordinate work, share context, and call tools inside one workflow. The security problem is that internal messages and shared state start to function like trusted identity channels, even though they are still untrusted input.

That matters because the control assumptions behind conventional software pipelines do not hold cleanly here. When one agent can shape another agent’s reasoning, the programme needs identity, privilege, and audit controls that follow the delegation chain instead of assuming the orchestrator is just plumbing.

Key questions

Q: How should security teams govern AI agents that collaborate with each other?

A: Security teams should govern multi-agent systems as a trust and delegation problem, not just a model safety problem. Each agent needs a defined role, tightly scoped tools, and message validation before another agent can act on its output. The orchestrator should be treated as a privileged control point with full audit logging and configuration review.

Q: Why do multi-agent AI systems create more security risk than single-agent assistants?

A: Multi-agent systems create more security risk because one agent can influence another through trusted-looking messages, shared memory, and delegated tool use. That allows prompt injection, context contamination, and capability bleed to spread laterally. The result is a larger identity blast radius and a harder containment problem than a single isolated assistant creates.

Q: What breaks when agents share memory and context too broadly?

A: When agents share memory too broadly, one incorrect or malicious write can shape multiple downstream decisions. The system may reinforce a bad assumption until it looks normal in logs and outputs. That makes investigation harder because the contaminated state becomes part of the workflow’s history, not just a single bad message.

Q: Who is accountable when an AI orchestrator routes unsafe agent actions?

A: Accountability sits with the organisation that designs the delegation model, assigns permissions, and operates the orchestrator. If unsafe actions occur, teams should be able to show which agent had which authority, what validation existed on internal messages, and why the orchestrator could route the action in the first place.

Technical breakdown

Agent-to-agent prompt injection in orchestration graphs

Agent-to-agent prompt injection occurs when one agent introduces instructions that another agent treats as trusted context. In a multi-hop graph, the malicious instruction can be relayed, transformed, and acted on without the normal validation that would apply to user input. This is structurally different from standard prompt injection because the attack path runs through delegated machine-to-machine trust rather than a human request boundary. Once agents begin forwarding each other’s output as operational context, the system can execute unsafe actions while logs still appear internally consistent.

Practical implication: validate internal agent messages as untrusted content, not as trusted function calls.

Context contamination and shared memory risk

Context contamination happens when a shared memory space stores incorrect, unsafe, or sensitive information that multiple agents then reuse. In effect, one bad write becomes a system-wide reference point, and later agents may reinforce the error because it is already in the workspace. The risk is not limited to deliberate exfiltration instructions. Hallucinated facts, partial answers, or misread tasks can poison the shared state just as effectively, which makes recovery difficult because the bad context has already shaped downstream decisions.

Practical implication: isolate memory windows so contaminated state cannot spread across the entire agent graph.

Capability bleed and orchestrator-level privilege

Capability bleed occurs when an agent receives tools or actions beyond its intended role, often because the orchestrator reuses a broad shared toolset. The orchestrator is the control plane, so it becomes the highest-value target and the easiest way to alter many agents at once. If it stores logs, context snapshots, and routing state, compromise of that layer can expose both data and delegated access. This is a familiar identity problem in a new form: the permissions attached to one actor start to describe the entire system if they are not scoped tightly and reviewed continuously.

Practical implication: treat the orchestrator as a privileged identity surface and scope each agent’s tool access separately.

Threat narrative

Attacker objective: The objective is to use trusted orchestration paths to drive unsafe actions at scale without triggering the usual human review boundary.

1. Entry occurs through a trusted inter-agent message, poisoned shared context, or compromised orchestrator integration that is accepted inside the workflow as normal input.
2. Escalation follows when the receiving agent reuses the tainted instruction or over-broad capability to call tools, spread context, or trigger additional agents.
3. Impact lands when the orchestration graph amplifies the bad state across multiple agents, causing unsafe actions, data exposure, or system-wide workflow failure.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.

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

NHI Mgmt Group analysis

Inter-agent trust is the new weak identity boundary: Multi-agent systems turn internal messages into security-relevant objects, even though many teams still treat them as implementation details. That means the real control point is not only authentication at the edge but trust validation inside the orchestration graph. The implication is that identity governance must follow agent delegation, not just external user access.

Capability bleed is the machine version of privilege creep: An agent that starts with a narrow role can accumulate tools, shortcuts, and reused permissions until its actual authority no longer matches its intended function. This is the same governance failure seen in over-permissioned service accounts, but with faster drift and less human visibility. Practitioners should recognise capability bleed as a lifecycle failure, not a one-off configuration error.

Context contamination creates an identity blast radius: Shared memory makes one compromised or mistaken agent able to influence many others through state, not just through direct action. That is why a group of individually safe agents can still produce unsafe system behaviour. The named concept here is identity blast radius, the distance over which one actor’s bad state can propagate through delegated trust.

Orchestrator security is the control plane question that teams keep underestimating: The orchestrator does not just move messages, it concentrates routing, state, and delegated access in one place. That makes it the equivalent of a high-value identity broker for the whole agent graph. Security programmes that ignore the orchestrator are assuming the most privileged component in the system does not need the strongest controls.

Zero-trust principles need to apply inside the agent mesh, not only around it: The article’s core lesson is that internal traffic is no safer than external traffic once agents can rewrite each other’s task context. That widens the scope of zero-trust architecture from perimeter and endpoint enforcement to message inspection, tool gating, and per-agent authorisation. The practitioner takeaway is to design for continuous verification between agents, not implied trust.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Another finding from the same research shows that only 44% of organisations have implemented any policies to govern AI agents.
• For a deeper threat-model view, Anthropic's first AI-orchestrated cyber espionage campaign report shows how agentic abuse can chain across multiple stages.

What this signals

Identity blast radius is the right lens for multi-agent governance. If a single agent can contaminate shared context or reuse an over-broad capability, the programme has already lost the assumption that authority is local and contained. Teams should expect greater pressure to log delegation chains, not just top-level prompts, and to align agent controls with zero-trust verification inside the workflow.

With 80% of organisations already seeing agents act outside intended scope, the governance problem is no longer theoretical. Practitioner programmes should prepare for more explicit controls around message validation, memory isolation, and orchestrator change management, because those are the points where agent behaviour becomes auditable and containable. The most useful next step is to map where current AI workflows still rely on implicit trust between machines.

The strongest near-term signal is not more AI functionality, but more evidence that AI identity needs policy boundaries at runtime. That means security teams should review how their existing IAM and PAM practices translate to agents, especially where tool access, configuration changes, and data access can be reached through one delegated control plane. If the orchestrator can change many things at once, then it deserves the same scrutiny as any other privileged identity broker.

For practitioners

• Validate internal agent traffic Treat inter-agent messages as untrusted input and inspect them before they are passed to the next agent or tool call. Build filtering for prompt injection patterns, unsafe instructions, and context that attempts to expand scope across the workflow.
• Scope each agent’s tools independently Map every agent to a narrowly defined role and remove any tool it does not need for that role. Reconcile the orchestrator’s shared toolset against the intended permission model so that drafting, testing, deployment, and data access are not bundled together.
• Isolate context windows and memory stores Replace shared global memory with task-scoped context where possible, and limit what each agent can read or write. Review whether one contaminated state could influence downstream decisions across multiple agents, then separate those paths.
• Harden the orchestrator as a privileged service Apply strict authentication, authorisation, logging, and configuration review to the orchestrator because it is the control plane for the full graph. Monitor routing changes, context snapshots, and tool wiring as privileged changes, not routine code maintenance.

Key takeaways

• Multi-agent orchestration creates a new attack surface where trust can spread between agents through messages, shared state, and over-broad tool access.
• The evidence is already visible in real deployments, with most organisations reporting agent behaviour beyond intended scope and a large share of agents exposed to governance gaps.
• The practical response is to treat agents, memory, and the orchestrator as identity surfaces that require scoped permissions, continuous validation, and full auditability.

Key terms

• Agent-to-Agent Prompt Injection: An attack where one AI agent places misleading or malicious instructions into a message another agent treats as trusted context. The risk is not limited to direct user prompts. It appears when machines inherit each other’s instructions without validation, allowing the injected content to steer downstream tool use or decisions.
• Context Contamination: The spread of incorrect, unsafe, or sensitive information through shared memory or context that multiple agents read and reuse. Once contaminated, the state can influence several decisions at once, which makes the issue harder to trace than a single bad output and harder to clean after the fact.
• Capability Bleed: The gradual expansion of an agent’s tool access beyond the role it was originally assigned. In practice, this happens when shared permissions, reused configurations, or forgotten boundaries give one agent powers that belong to another. It is privilege creep expressed through machine delegation.
• Orchestrator: The control plane that routes messages, stores workflow state, and manages tool access across multiple AI agents. Because it concentrates delegation and logging in one place, it becomes the highest-value identity surface in the system and needs privileged-service treatment, not ordinary application handling.

What's in the full article

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

• A walkthrough of the Kirin control layer and how it monitors inter-agent messages, actions, and policy decisions.
• Specific examples of prompt filtering, audit trails, and capability enforcement at the IDE, MCP, and tooling boundary.
• Operational guidance on blocking unsafe commands, redacting sensitive data in real time, and logging agent behaviour for investigation.
• The article’s concrete framing for using the orchestrator as a security control plane rather than as plumbing code.

👉 Knostic's full post covers the attack patterns, control layer functions, and governance model in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.