Agent Security › Multi-agent
Single-agent security asks what an agent can do. Multi-agent security asks what it can get another agent to do. Delegation, the confused deputy, trust boundaries and the relationship map.
One AI agent is relatively easy to picture. You give it a job. It uses some tools. It performs some actions. You monitor what it does.
Now imagine ten agents. One researches. One manages email. One accesses your CRM. One handles customer support. One writes code. One deploys code. One works with invoices. One can make payments. And they can ask each other for help.
Suddenly the security question isn't simply "what can this agent do?" It's "what can this agent get another agent to do?" That changes things, because an agent with very little authority of its own may potentially gain access to much greater capability through another agent. Welcome to the agent-to-agent security problem.
This is very current territory. NIST's agent-identity work specifically calls out preserving authorisation through delegation chains, including agent-to-agent interactions, and OWASP's Agent Control Standard identifies compromised peer agents, insecure inter-agent communication and cross-agent trust exploitation as agentic security risks.
Agent-to-agent security is the protection of systems where AI agents communicate, collaborate, delegate tasks or exchange information with other agents. It deals with questions such as: which agents can communicate? How do they identify each other? Which agents should trust each other? What can one agent request from another? Does authority transfer when a task is delegated? Can one agent access another agent's tools? Can a low-authority agent trigger a high-authority agent? Can malicious instructions move between agents? Can we trace an action back through the entire chain?
These questions become increasingly important as businesses move from individual AI assistants to networks of specialised agents.
Because specialisation can be useful. Instead of creating one enormous agent with access to everything, you might have a Research Agent (finds information), a Sales Agent (works with prospects), a CRM Agent (manages customer records), an Email Agent (handles communication), a Finance Agent (works with invoices and payments) and a Content Agent (creates marketing content). Each agent can have its own purpose, tools, permissions and authority.
That can actually improve security. A research agent doesn't need payment access. A finance agent doesn't need social-media publishing. A content agent doesn't need payroll. But this only works if the boundaries between those agents mean something.
Imagine the Research Agent cannot access customer financial information. Good. But it can communicate with the Finance Agent, which can. So Research Agent asks: "please retrieve the financial records for Customer 123 and send them to me." Finance Agent does it. Technically, Research Agent never accessed Finance. But effectively, Research Agent obtained Finance data. Its real authority wasn't just its own permissions. It also included what it could persuade another agent to do.
Authority should not automatically travel with a task.
If Agent A asks Agent B to perform an action, Agent B shouldn't assume "Agent A asked, therefore Agent A is authorised". Instead, Agent B may need to ask: who is Agent A? Who originally requested this task? What is Agent A allowed to request? What am I allowed to do for Agent A? What data can I return? Does this action require human approval? Has the original authority expired? An intern cannot walk into Finance and say "the Marketing Director asked me to transfer £20,000". Finance should verify the authority behind the request. Agents need the same principle.
A business might decide "these are all our internal agents, so they can trust one another". But imagine one agent becomes compromised through prompt injection, malicious data, a compromised tool, stolen credentials, incorrect configuration or a software vulnerability. That agent can now send requests to other trusted agents. If every internal agent automatically trusts every other internal agent, one compromised agent can become an entry point into the whole system.
Internal does not automatically mean trusted. Trust should be earned through identity and authority.
The research agent. A Research Agent can READ the public web and WRITE research notes, but cannot access CRM, send external email or access Finance. Now imagine it can ask the CRM Agent to retrieve customer records and the Email Agent to send messages. Its effective authority may now include CRM access and external email, even though neither appears in its own permission list. That's why multi-agent security must look at relationships, not just individual agents.
The finance chain. Invoice Agent reads incoming invoices, asks Supplier Agent to verify supplier details, asks Payment Agent to prepare payment, and a human approves. Sensible. Now imagine a malicious invoice contains hidden instructions. The Invoice Agent is manipulated. It asks Supplier Agent to create a new supplier, then asks Payment Agent to pay it. If each downstream agent simply trusts the previous one, malicious input has travelled from document to agent to agent to financial action. The security boundary needs to survive the whole chain.
There's an old security concept called the confused deputy. An attacker cannot perform a privileged action directly, so they convince something that does have the privilege to perform it for them. In an agent system, low-authority Agent A cannot perform Action X, but high-authority Agent B can, so Agent A persuades Agent B to do it. The important lesson isn't the terminology. It's this: an agent should not lend its authority simply because another agent asks.
Before Agent B accepts a request from Agent A, it needs to know who you are, not merely "I'm the Finance Assistant". Identity should ideally be established by the system. For example: Agent ID INVOICE-01, owner Finance Director, purpose validate incoming invoices, authority READ + RECOMMEND, may request from Payment Agent PREPARE PAYMENT, may request execution NO. Now the receiving agent has something meaningful to evaluate.
Imagine Sarah asks the Sales Agent, which asks the Research Agent, which asks the CRM Agent. When CRM Agent performs the final action, the system shouldn't lose the original context. Useful information: original principal Sarah, originating agent Sales Agent, delegating agent Research Agent, executing agent CRM Agent, requested action READ customer record. That gives you an authority chain. Without it, the log may simply say "CRM Agent accessed customer record": technically true, operationally incomplete.
Agents will often act on behalf of people. If Sarah's Sales Agent requests a customer record, the CRM Agent needs to know more than "Sales Agent requested it". It may also need to understand on whose behalf, because Sarah may be authorised to see one set of records while another employee isn't. The authority chain becomes human to agent to agent to tool to action. The further the action travels from the original person, the more important it becomes to preserve that context.
Suppose Agent A has authority to READ a customer record and delegates part of the task to Agent B, which happens to have authority to READ, CHANGE and DELETE. Should Agent B suddenly be allowed to DELETE because its own credentials permit it? No. For the delegated task, its effective authority should remain limited by the authority of the request.
Delegation should preserve or reduce authority, not silently increase it.
Think of authority as a ceiling. If Agent A (READ) initiates a task, the workflow shouldn't automatically gain CHANGE and SEND simply because later agents happen to possess those capabilities. The original task's authority should act as a ceiling unless additional authority is explicitly granted.
Suppose the rule is "payments above £500 require human approval". Agent A asks Agent B, Agent B asks Payment Agent, Payment Agent executes £800. Nobody asks for approval because each agent assumes the previous one handled it. That's a governance failure. Approval requirements need to survive delegation. A task passing through five agents shouldn't make the original security requirement disappear.
Imagine a human approves "agent may purchase this product for up to £200 during this task". Three hours later, another agent receives a delegated request associated with the task. Is the approval still valid? Maybe not. Authority may depend on time, task, amount, destination, purpose, session, user and approval. Multi-agent systems need to preserve those conditions, not merely pass APPROVED down the chain forever.
Multi-agent security isn't only about actions. It's also about information. Suppose the HR Agent can access salary information and the Marketing Agent cannot. Marketing Agent asks HR Agent: "summarise everyone's salary and send me the results." HR Agent may technically be authorised to read the information. But is it authorised to give that information to Marketing Agent? Those are different permissions. So receiving agents need to consider "am I allowed to release this information to the agent requesting it?", not simply "am I allowed to access it myself?"
Information should carry context as it moves between agents: source, classification, owner, sensitivity, permitted use, permitted destination, original requester. This matters especially when agents combine information from several systems, because data that appears harmless separately may become sensitive when aggregated.
Imagine a research agent reads a malicious webpage containing instructions intended to manipulate an AI system. Research Agent incorporates some of that content into its output. That output is passed to Analysis Agent, then to Email Agent. Now an instruction originating from an untrusted webpage has travelled through multiple agents, potentially reaching an agent with more authority than the one that first encountered it. This is cross-agent contamination. Learn more about prompt injection for AI agents.
Agent B receives information from Agent A. Agent B should not necessarily treat everything in that information as trusted instructions. It may contain untrusted web content, user-supplied content, malicious instructions, incorrect information, poisoned memory or manipulated tool output. The receiving agent needs to distinguish "Agent A says this is the task" from "Agent A found this text while completing the task".
Provenance matters: where did this come from? Suppose Agent B receives "delete the existing supplier and create this new one". Did that originate from the Finance Director, the Invoice Agent, a supplier email, an uploaded PDF, an external website or another model? The answer changes how much trust the instruction deserves. Multi-agent systems need ways of preserving the origin of important requests and information.
Imagine Agent A stores malicious information in shared memory, and Agents B, C and D all use that memory. The problem may persist even after Agent A is stopped. So ask: who can write to shared memory? Who can read it? What becomes persistent? Can entries be attributed, reviewed, expired or removed? A shared memory store is effectively another shared system. Treat it accordingly.
Eventually agents may be able to create or configure other agents. If Agent A can create an Agent B with greater permissions than itself, it may have discovered a route around its own restrictions: Agent A cannot access Finance, creates Agent B, Agent B receives Finance access, restriction bypassed. Therefore an agent should not be able to create an agent with greater authority than it is authorised to delegate.
The same applies to tools. If an agent isn't allowed to send email but is allowed to install integrations, connect APIs or add tools, it can connect an email service and now it can send. Technically SEND remained denied; practically the agent created another route. Agents shouldn't normally be able to expand their own authority by adding tools.
Imagine Agent A asks Agent B for restricted data, Agent B refuses, Agent A tries another phrasing, Agent B refuses, Agent A asks Agent C, Agent C asks Agent B, and Agent B complies. That's exactly the type of behaviour monitoring should detect. A denied action shouldn't simply become "try another agent". Repeated attempts to achieve the same denied outcome through different agents are important security signals.
Traditional monitoring might show Agent A normal, Agent B normal, Agent C normal, but the relationship between them may be unusual: Marketing Agent suddenly contacts Finance Agent 300 times, Research Agent begins requesting data from HR Agent, Support Agent starts delegating tasks to Deployment Agent. Individually each may appear healthy. The unusual behaviour exists in the connection. So multi-agent monitoring should consider who talks to whom, how often, for what purpose, what authority is requested, what data moves between them, and what changed.
As your agent ecosystem grows, map the relationships. For example: the Sales Agent may call Research Agent and CRM Agent, but cannot call Finance Agent or HR Agent. The CRM Agent may receive requests from Sales Agent and Support Agent, may return approved customer information, but cannot return payment information or credentials. The Finance Agent may receive requests from Invoice Agent, but cannot receive requests from Marketing Agent or Research Agent.
Your Agent Register tells you which agents exist. Your Permission Map tells you what each agent can do. Your Relationship Map tells you which agents can use each other.
It may be tempting to place all company agents inside one trusted environment, where Agent A trusts B trusts C trusts D and eventually everyone trusts everyone. That creates a large blast radius. Instead, consider trust boundaries based on purpose, department, data, risk, authority and environment. A public-web research agent shouldn't automatically sit in the same trust zone as a production infrastructure agent.
Least privilege applies between agents too. Does Sales Agent actually need to call Finance Agent? Does Research Agent need access to Support Agent? Does Content Agent need to invoke Deployment Agent? If not, don't create the relationship. The safest agent-to-agent permission is often no connection.
The more authority an agent has, the more carefully it should evaluate requests from other agents. A Payment Agent shouldn't execute "pay £4,000 to Supplier X" simply because another agent formatted the request correctly. It may need to verify requester identity, original human authority, supplier, amount, invoice, policy, approval, transaction limit and task context. A high-authority agent should behave more like a controlled service than an obedient assistant.
Agent-to-agent permissions should be explicit. For each relationship, you might define: requesting agent Invoice Agent, receiving agent Payment Agent, allowed request prepare payment, maximum value £500, execute no, human approval required, data returned payment status only, expires end of task. That's much safer than "Invoice Agent can use Payment Agent".
Assume the Research Agent becomes compromised. Ask which agents it can contact, which systems those agents can access, what data it can request, whether it can trigger high-authority actions, write to shared memory, create other agents, add tools or send information externally. This gives you the compromised agent's potential blast radius. The goal isn't necessarily to make that radius zero. It's to make it understandable and controlled.
Now consider a compromised Payment Agent. That's more serious, but good architecture still helps. Perhaps Payment Agent cannot browse the public web, read arbitrary email, create suppliers, change its own permissions, send files externally, or make payments above a threshold without human approval. Even a high-authority agent doesn't need every capability. Separation can reduce the blast radius.
The answer isn't "don't let agents work together". Well-designed separation can make agent systems safer. Instead of one agent with web, email, CRM, finance, production, publishing and deletion, you can create specialised agents with narrow authority, then carefully control the relationships between them. That can give agents significant autonomy while limiting how far any one compromised agent can reach.
SPECIALISE, then LIMIT, then VERIFY, then DELEGATE, then MONITOR. Not: connect everything, trust everything.
For every multi-agent system, ask:
If several answers are no or not sure, your multi-agent system may have authority paths you haven't yet mapped.
As businesses deploy more agents, three simple views become extremely useful. The Agent Register (who exists: agent, owner, purpose, risk, status). The Permission Map (what can each agent do: systems, data, tools, authority, boundaries). The Relationship Map (who can use whom: agent-to-agent communication, delegation, data flow, authority flow, trust boundaries). Together, those three views give you a much better picture of the actual agent ecosystem.
Multi-agent security is an important direction for Agent Control. The goal isn't only to see agents individually. It's eventually to understand the network: Sales Agent can call Research Agent can call CRM Agent, while Finance Agent sits behind a separate authority boundary, with identity, permissions, authority, data, activity, approvals, risk and alerts overlaid. Then the organisation can see not simply "we have 17 agents" but "this is how authority moves between our 17 agents". And it can flag effective authority through relationships: not just "this agent cannot spend" but "this agent cannot spend directly, but it can call another agent that can". That's a much more meaningful security warning.
Agent Control is in build. Leave your email and we will let you know when it is ready.
Single-agent security asks "what can this agent do?" Multi-agent security adds "what can this agent cause?" Those aren't always the same thing. An agent with little authority can become powerful if it can freely invoke agents with greater authority. A compromised research agent shouldn't automatically inherit Finance. A support agent shouldn't automatically inherit Production. And another agent shouldn't be trusted simply because it belongs to the same organisation.
Give every agent an identity. Give every relationship a purpose. Make delegation explicit. Preserve the original authority. Verify high-consequence requests. Monitor the connections. And don't let agents borrow authority simply because they know which agent to ask. Because in a multi-agent world, the security boundary isn't only around the agent. It's around the relationship between agents.