TL;DR: Multi-agent AI systems expand development speed but also widen the attack surface through agent-to-agent prompt injection, context contamination, capability bleed, and orchestrator compromise, according to Knostic. The governance assumption that internal agent messages are trusted breaks once agents can independently influence one another at runtime.
NHIMG editorial — based on content published by Knostic: What This Blog Post on AI Agent Orchestration Security Covers
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Knostic's analysis of AI agent orchestration security and multi-agent risk →
AI agent orchestration risks: what changes for IAM and security teams?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent orchestration security exposes new inter-agent attack paths