The Question
Traditional enterprise security architecture is built on two foundational assumptions: that the entities making requests are human users with verified identities, and that trust boundaries align with network perimeters. Access control policies answer the question "is this user authorized to access this resource?" Firewalls and zero-trust network architectures answer the question "is this request coming from a trusted network segment?"
Multi-agent AI systems break both assumptions simultaneously. In a production multi-agent architecture — an orchestrator agent that directs specialist sub-agents, a planner agent that delegates tasks to executor agents, a supervisor agent that coordinates a pool of worker agents — the entity making most requests is not a human user. It is another agent. The request originates not from a network endpoint with a known security posture, but from an AI reasoning process that could be anywhere in a complex chain of agent-to-agent calls.
The enterprise security perimeter that was designed around user identity and network boundary does not have a concept of agent identity. It does not have policies for agent-to-agent trust. It does not have audit mechanisms designed to reconstruct a chain of agent-to-agent communications. In a multi-agent system, the security architecture must be rebuilt around a new class of principal: the agent.
Multi-agent security is not an extension of single-agent security — it is a new security architecture problem where the principals are agents rather than users, and the security controls must be designed for that principal type.
Why This Matters Now
Multi-agent architectures moved from research prototype to production enterprise deployment in 2025 at a pace that surprised most security teams. The inflection point was the release of production-grade multi-agent frameworks: Microsoft AutoGen 0.4 (released January 2025) introduced a redesigned architecture for production-scale multi-agent systems with improved inter-agent communication protocols. Google's Agent Development Kit, released in April 2025, provided an open-source framework for building multi-agent pipelines with Gemini models as orchestrators. Anthropic's Claude's multi-agent tool use, demonstrated at scale in early 2025, enabled Claude instances to spawn and direct sub-agents within the same API context.
Enterprise adoption followed. The 2025 Databricks State of Data + AI report found that 31% of enterprise AI deployments in production as of Q3 2025 used multi-agent architectures — up from 8% in Q3 2024. The primary use cases driving adoption were complex document processing pipelines (a coordinator agent decomposes a document processing task across specialist agents), software development automation (a planner agent directs coding, testing, and review agents), and enterprise workflow automation (an orchestrator agent routes tasks across functional specialist agents for HR, finance, and IT operations).
The security research community responded quickly. In mid-2025, researchers from Carnegie Mellon, ETH Zurich, and several enterprise security vendors published work demonstrating privilege escalation via agent chains, agent impersonation attacks, and cross-agent prompt injection in multi-agent frameworks. These were not theoretical attacks on contrived scenarios — they were demonstrated against production configurations of AutoGen, LangGraph, and CrewAI. The attack surface for multi-agent systems is real, it is documented, and it is not yet reflected in most enterprise security programs.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Enterprise Agent Platform CURVE™ Report evaluated fifteen vendors on multi-agent security capabilities, spanning agent authentication, inter-agent communication security, audit trail depth, and privilege isolation between agent roles.
Specialized AI security platforms — including HiddenLayer, Robust Intelligence (now part of Cisco), and Protect AI — showed the strongest capabilities for inter-agent communication monitoring and anomaly detection. Their advantage is model-layer visibility: they can inspect the content of agent-to-agent messages, not just the network traffic, which is where most multi-agent attacks manifest.
Agent orchestration frameworks with native security features — Microsoft AutoGen's agent identity capabilities, Salesforce's Einstein Trust Layer (extended to multi-agent workflows in late 2025), and Google ADK's agent authorization model — showed meaningful progress on agent authentication and least-privilege assignment. These frameworks are moving toward treating agents as first-class security principals with verifiable identities.
Enterprise SIEM and XDR platforms — Splunk, Microsoft Sentinel, and CrowdStrike Falcon — are extending their correlation capabilities to cover agent audit logs, but most require custom integration work to ingest and correlate inter-agent communication logs from multi-agent frameworks that do not natively export to SIEM formats.
The full vendor rankings are in the 2026 Stackcurve AI Enterprise Agent Platform CURVE™ Report — free to download.
The Gap Most Buyers Miss
Enterprise security teams evaluating multi-agent deployments consistently underestimate the complexity of the trust and privilege model. The gap is not in identifying that multi-agent systems have security implications — most security teams understand that at a conceptual level. The gap is in understanding the specific attack paths that are unique to agent-to-agent architectures and require specific controls.
Agent impersonation is not solved by API keys
If Agent A calls Agent B's API with an API key, Agent B has no mechanism to verify that the caller is actually Agent A — only that the caller possesses Agent A's API key. API keys can be extracted from compromised agent configurations, forwarded by a compromised intermediary agent, or captured in transit. Robust agent-to-agent authentication requires agent identity credentials that are bound to the agent's runtime environment — not just a shared secret that any process possessing it can present.
Privilege escalation through agent chains is a structural vulnerability
Consider a three-tier agent architecture: a low-privilege user-facing agent (Tier 1) that calls a mid-privilege data aggregation agent (Tier 2) that calls a high-privilege data write agent (Tier 3). If Tier 2 forwards the original request context to Tier 3 — including any injected instructions embedded in the user's original request — an attacker who can manipulate Tier 1's input can potentially escalate privileges to Tier 3's capability level without ever directly interacting with Tier 3. This privilege escalation path does not exist in human-centric access control models because humans cannot forward their requests through other principals. Agents can.
Prompt injection propagates through the chain
In a multi-agent pipeline, Agent A's output becomes Agent B's input. If Agent A has processed adversarial content that includes embedded instructions, those instructions travel downstream as part of Agent A's output. Agent B has no mechanism to distinguish between legitimate output from Agent A and injected instructions embedded in that output — unless B applies its own input validation on content from upstream agents. Most production multi-agent architectures do not apply input validation at each agent boundary, treating upstream agent output as implicitly trusted.
Supervisor trust decisions are a high-value attack target
In hierarchical agent systems, the supervisor agent makes trust and delegation decisions: it decides which tasks to delegate to which sub-agents, and what permissions to grant for those tasks. If the supervisor's trust decisions can be manipulated — through prompt injection in the supervisor's input context, or through a compromised sub-agent that reports false task completion status — an attacker can cause the supervisor to grant excessive permissions to malicious agents or to delegate sensitive tasks to compromised agents.
Questions Your Buying Team Should Be Asking
1. How do agents in this architecture authenticate to each other, and what prevents a compromised agent from impersonating another agent in the chain?
This question exposes the authentication gap faster than any technical review. Most multi-agent deployments authenticate inter-agent calls with API keys or bearer tokens — shared secrets that any process can present. The answer you are looking for is runtime-bound agent credentials, agent identity certificates, or a short-lived token model that ties agent identity to the running process rather than a shared secret stored in configuration.
2. Does each agent in the chain operate with least privilege, or do agents inherit the permission scope of the calling agent?
Permission inheritance through agent chains is the default behavior of most current frameworks — and it is the behavior that enables privilege escalation. Each agent should have its own defined permission scope, independent of whether it was called by a high-privilege orchestrator. Ask vendors and internal architects to show you the permission model for each agent in the chain, not just for the system as a whole.
3. What does the audit trail look like for a complex inter-agent interaction, and can you reconstruct the full chain of agent-to-agent calls for a given user session?
Forensic reconstructability is the test of an effective multi-agent audit system. A good audit trail records not just what each agent did, but which agent called it, with what inputs, and what outputs it returned. Ask vendors to demonstrate audit log reconstruction for a multi-hop agent interaction — not just confirmation that logging is enabled.
4. What input validation does each agent apply to outputs received from upstream agents in the chain?
The correct answer is that each agent validates its inputs regardless of source — upstream agents are not implicitly trusted. Most current architectures do not meet this standard. If your deployment treats upstream agent output as trusted input, you have an undefended cross-agent injection path.
5. How does the architecture handle a scenario where a sub-agent is compromised mid-session — can it be isolated without terminating the entire agent workflow?
Graceful isolation of a compromised agent without cascading failure is a design characteristic of resilient multi-agent architectures. If the answer is "we'd have to kill the whole session," the architecture has no fault isolation, and a single compromised agent can be used to deny service or force unsafe fallback behavior across the full agent system.
The Stackcurve Take
Multi-agent security will define the enterprise AI security agenda for 2026 and 2027. The frameworks are maturing rapidly, adoption is accelerating, and the attack surface is documented and actively researched by both the academic security community and threat actors seeking initial access to enterprise systems through their AI infrastructure.
The security teams that will manage this well are not the ones that add multi-agent deployments to their existing identity and network security programs without modification. They are the ones that recognize agent-to-agent communication as a new trust boundary requiring new authentication, new privilege models, and new audit capabilities — and that engage with their multi-agent vendors and frameworks on those requirements before production deployment, not after an incident.
The principle of least privilege per agent, immutable inter-agent audit trails, and agent authentication that does not rely on shared secrets are the three requirements that separate defensible multi-agent architectures from ones that will be compromised through their own orchestration infrastructure.
The 2026 Stackcurve AI Enterprise Agent Platform CURVE™ Report covers multi-agent security architecture, inter-agent authentication, and vendor capability assessments across major orchestration frameworks. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.