Multi-agent systems need zero-trust controls because autonomous agents can escalate privileges, leak data, or collude when their access is too broad.
2
Each agent should have a verified identity, scoped and time-limited permissions, protected communication, and activity monitoring.
3
Prompt injection, data poisoning, cross-agent leaks, and rogue behavior require controls such as API gateways, data labels, sandboxing, mutual TLS, and dynamic policy checks.
Summary
Surendra Narang and Venkata Gopi Kolla explain how zero-trust security can be applied to multi-agent systems. They describe an architecture with an orchestrator, autonomous agents, communication channels, shared memory, a policy plane, and auditability. The examples cover edge and CDN operations, where agents manage certificates, DNS, bot mitigation, and caching, as well as cloud defense, where agents detect exposed services and infrastructure drift. The speakers focus on risks that grow with autonomy: excessive permissions, prompt injection, data poisoning, data leakage between agents, fake or colluding agents, and insider-style behavior caused by bugs. Their proposed controls include non-human identity verification, just-in-time access, attribute- and policy-based controls, mutual TLS, encrypted messaging, context-aware input filtering, data sensitivity labels, sandboxing, quarantine, and behavior monitoring. Their conclusion is that trust-once models do not fit autonomous agents. Access and trust need to be reassessed as the agent, context, and workflow change.
A multi-agent system coordinates specialised autonomous workers through an orchestrator
Venkata Gopi Kolla defines a multi-agent system as a network of independent software agents, each assigned a specific role or function. Agents make decisions from the data they receive, then coordinate through a central orchestrator or communication framework. The orchestrator distributes tasks, manages workflows, handles conflicts, and reallocates responsibilities. The architecture also includes communication channels, shared memory for state and session context, a policy plane, and auditability. The speakers compare the model with an emergency response team, where specialised participants work independently while coordinating around a common operation.
The policy plane applies least privilege to every agent
The policy plane is where identity, access controls, and policy rules are enforced. An agent is allowed to perform only the actions defined by those policies. The speakers connect this to least privilege and to the need for real-time monitoring, debugging, and auditing. They describe the orchestrator as the central coordinating component, while agents handle specific business or technical functions such as inventory management, database queries, or security scans. Shared memory makes it possible to retain state and context, which also makes protecting that information part of the security design.
Specialised edge agents can create outages and data exposure when compromised
In a large CDN or edge environment, separate agents might manage TLS certificates, DNS routing, bot mitigation, and content caching. These agents operate independently but must coordinate during events such as domain migration or policy changes. A compromised certificate agent could create a man-in-the-middle risk. A misconfigured routing agent could leak customer metadata or cause an outage. Observability agents could also be abused to inject or alter logs. The proposed controls include scoped permissions, mutual authentication, signed activity records, and dynamic quarantine for malicious or malfunctioning agents.
Autonomous cloud-security agents can detect and remediate exposed infrastructure
The speakers describe agents that assess cloud attack surfaces in real time. A cloud asset agent checks for publicly exposed resources, while service-map and drift-watcher agents examine infrastructure changes. In their example, a DevOps engineer deploys a billing API without authentication. The agent detects missing API controls, TLS settings, or approved change records, then blocks public access and creates a pull request to fix the code. The example is intended to show how agents can provide visibility and automated response when infrastructure code or deployed resources drift from approved settings.
Autonomy expands the attack surface across permissions, inputs, memory, and decisions
The speakers identify several risks that arise because agents make decisions with partial knowledge. Poorly scoped permissions can cause privilege escalation or unauthorised access. Prompt injection can manipulate an LLM-powered agent through input from a user, another agent, or external data. An agent may accidentally share sensitive information with another agent that is not authorised to see it. Multiple compromised agents could collude to bypass policies. A well-intentioned agent can also behave abnormally because of a bug or logical flaw. These risks span communication paths, shared memory, and decision processes.
The speakers recommend that agents receive exactly the access they need, and only when they need it. They describe just-in-time access, risk-based privileges, and attribute- or policy-based access control for non-human identities. During long-running sessions, a policy enforcer should reevaluate permissions as the agent's environment changes. This replaces a set-and-forget approach with adaptive trust. Their example is an agent that begins by deploying containers but then deletes firewall rules because it has overly broad permissions. The problem is the permission model, even if the agent is operating as configured.
Input filtering and isolation reduce prompt-injection and data-poisoning risks
Agents can receive hostile content through URLs, APIs, other agents, and LLM prompts. The speakers place API gateways at the first line of defence. Gateways can intercept and validate inputs, filter malicious content, and enforce schemas. They also describe context-aware sanitisation, where middleware considers who sent the data and what the sender intends before passing it on. Untrusted agents or systems can be quarantined in isolated environments, with their communications examined by an AI model or a human. These controls are intended to limit the effect of poisoned or manipulated inputs.
Agent-to-agent data flow needs trust zones and sanitised payloads
Data can leak between agents even when there is no external breach. The example is an agent trained on billing data assisting a support agent and exposing financial records in a support workflow. The speakers recommend treating every agent as if it operates in a separate trust zone. Access tags, sensitivity labels, and role-based filters restrict what one agent can pass to another. Collaborating agents should exchange sanitised payloads rather than unrestricted memory or context. They compare this arrangement to a clean room for inter-agent messaging.
Verified identities and encrypted communication limit fake-agent and collusion attacks
The speakers warn that attackers can create fake agents, send false signals, or take over legitimate agents and make them appear normal. They recommend cryptographically verified identities and mutual TLS so both the sender and receiver authenticate each other and communications are encrypted. Certificates should be revoked over time and according to the communication context. Behaviour monitoring and traffic recognition can help detect collusion. End-to-end encryption also reduces the chance that attackers on a breached network can impersonate agents, hijack workflows, or alter communications.
"The orchestrator manages the workflows, handles conflicts and dynamically reallocates responsibilities among them."01:45
Who should watch
You are designing an agent architecture with an orchestrator, shared memory, and multiple specialised workers, and need to decide where identity and policy checks belong.
Your agents can call APIs, access cloud resources, or exchange data, and you need concrete examples of how excessive permissions and cross-agent leaks can happen.
You are evaluating security controls for prompt injection, rogue agents, fake-agent attacks, or collusion in an automated system.
