In multi-agent ai security, the core risk is not just failure, but the silent laundering of authority. When agents delegate tasks without carrying the original intent, a stranger's command can masquerade as a trusted directive, bypassing the safeguards designed to protect privileged actions.
Most organisations assume that if an agent is authenticated, it is safe to execute its requests. This assumption breaks down the moment one agent hands a task to another. The receiving agent sees a valid token from a colleague, not the original human intent behind the request. It processes the instruction as if it originated from a trusted source, even if the chain of custody is opaque.
This is the central vulnerability in modern multi-agent architectures. The system treats inter-agent messages as internal commands rather than external inputs. Consequently, a malicious actor who compromises a low-privilege agent can inject a payload that travels up the delegation chain. By the time the request reaches a high-privilege tool, the original context has been stripped away. The tool sees only a valid request from a peer, not the potentially hostile origin.
We must rethink how trust propagates through these networks. Security cannot rely on the identity of the immediate sender alone. We need to preserve the provenance of the original request throughout the entire workflow. Without this, we are building systems where authority is easily laundered, and boundaries are easily crossed. The goal is to ensure that every action can be traced back to the specific permission granted by the primary user.
How multi-agent workflows are wired
Current multi-agent systems are often designed for efficiency rather than auditability. An orchestrator agent receives a high-level goal and breaks it down into sub-tasks. It then assigns these sub-tasks to specialised worker agents. The workers execute their parts and return results to the orchestrator. This pattern simplifies development but obscures the line of authority.
The communication between these agents typically happens over internal APIs or message queues. These channels are often treated as secure by default because they are part of the same deployment. However, this internal trust model is fragile. If one agent is compromised, the attacker gains a foothold inside the trusted perimeter. They can then issue commands to other agents as if they were legitimate colleagues.
The problem is compounded by the lack of standardised protocols for passing context. Different frameworks handle state and permission differently. Some agents carry the full history of the conversation. Others only see the immediate task description. This inconsistency creates blind spots where critical information, such as the original user's intent, is lost. When context is lost, so is the ability to verify whether the current action is appropriate.
We see this clearly when looking at the over-privileged autonomous agents risks. An agent might have broad permissions to read data, but those permissions should not automatically apply to every sub-task it delegates. The delegation mechanism must enforce stricter constraints than the original grant. Otherwise, the system expands its own attack surface with every new agent added to the workflow.
Authority laundering through delegation
Authority laundering occurs when a request loses its original constraints during handoff. Consider a user who asks an agent to summarise a specific document. The agent has permission to read that document. It then delegates the summarisation task to another agent. The receiving agent might have permission to write to a database, but not to read the original document.
If the delegation chain does not carry the original permission scope, the second agent might infer that it can access the document because the first agent could. This inference is dangerous. It assumes that trust is transitive. In security, trust is rarely transitive. Just because Agent A trusts Agent B does not mean Agent B should have the same rights as Agent A.
The attacker exploits this gap by injecting a subtle modification into the delegated task. They might change the output destination or alter the data filtering criteria. The receiving agent executes the task using its own permissions, unaware that the original user did not intend for the data to be exported. The action appears valid because the agent is authenticated and the task is coherent.
This is why we must ask who are you actually defending against. We are not just defending against external hackers. We are defending against the unintended consequences of our own architecture. If the system allows an agent to expand its own capabilities through delegation, it becomes a vector for privilege escalation. The laundering process turns a simple query into a complex, untraceable operation that bypasses initial safeguards.
Why agent identity is not enough
Identity verification is the first line of defence, but it is insufficient for multi-agent systems. Knowing that Agent X is sending a message to Agent Y does not tell us what Agent X was allowed to do. It does not tell us who asked Agent X to do it. It does not tell us whether the current request is within the bounds of the original authorisation.
Many systems rely on static roles or capabilities assigned to agents. These roles are often broad to reduce complexity. An agent might have a "data_processor" role that allows it to read and write to a specific bucket. When this agent delegates a task, it passes its own identity. The receiving agent sees a "data_processor" and grants access based on that role.
This approach ignores the principle of least privilege. The original user might have only intended for the data to be read, not written. The delegation should carry the specific permission for "read-only access to this file," not the general "data_processor" role. Without this granularity, the receiving agent has no way to know that the write operation is out of bounds.
Identity is a static credential. Intent is a dynamic state. Multi-agent systems must track the dynamic state of the request. They must distinguish between an agent acting on its own behalf and an agent acting as a proxy for a user. Confusing these two states leads to systemic vulnerabilities where agents can inadvertently or maliciously exceed their authorised scope.
Carrying the original principal along
The solution lies in preserving the provenance of the request. Every message passed between agents should include a chain of custody. This chain records who initiated the task, what permissions were granted, and what constraints were applied at each step. This is not just for logging. It is for enforcement.
When an agent receives a delegated task, it must inspect the provenance chain. It checks whether the original user had permission for the action being performed. It checks whether the intermediate agents had permission to delegate this specific task. If any link in the chain is missing or invalid, the agent should reject the request.
This approach requires a standardised format for carrying context. The format must be tamper-evident. It should include digital signatures from each agent in the chain to prevent forgery. It should also include a clear statement of the original user's intent. This ensures that the final action aligns with what the user actually asked for.
We have discussed similar concepts in the permission you granted once. The principle remains the same: permissions are not infinite. They are bounded by the original grant. When an agent acts on behalf of another, it must operate within those same boundaries. It cannot create new permissions out of thin air. The provenance chain enforces these boundaries by making the original grant visible at every step.
Capability tokens instead of trust
Rather than relying on agent identity, we should use capability tokens. A capability token is a cryptographically signed object that grants permission to perform a specific action on a specific resource. It is not tied to the agent's identity. It is tied to the action itself.
When an agent delegates a task, it does not pass its own credentials. It passes a capability token that represents the right to perform the delegated action. The receiving agent can verify the token without needing to trust the sender. The token proves that the action is authorised, regardless of who is executing it.
This model decouples identity from permission. An agent can be untrusted, but the token can still be valid. This is crucial for security. It means that even if an agent is compromised, the attacker cannot use it to generate new permissions. They can only use the tokens that were already issued. This limits the blast radius of any compromise.
Capability tokens also simplify audit trails. Each token represents a discrete permission grant. We can track exactly which tokens were used and when. This makes it easier to detect anomalous behaviour. If an agent uses a token in a way that was not intended, the system can flag it. The token itself carries the constraints, so there is no ambiguity about what was allowed.
Designing the boundary between agents
The boundary between agents is not a firewall. It is a policy enforcement point. Every message that crosses this boundary must be evaluated against the provenance chain and the capability tokens. This evaluation must be strict. It must reject any request that lacks clear provenance or valid capabilities.
Designers must avoid the temptation to make these checks lightweight. Performance is important, but security cannot be an afterthought. The overhead of verifying provenance is small compared to the cost of a data breach. The system must be built to handle this verification efficiently.
We must also consider the user experience. Users need to understand what permissions their agents are using. They need to be able to revoke permissions for specific tasks. The system should provide clear visibility into the delegation chain. This allows users to audit the behaviour of their agents and correct any misconfigurations.
The goal is to create a system where trust is earned, not assumed. Every agent must prove its right to act at every step. This requires a shift in mindset. We must stop treating inter-agent communication as internal and start treating it as external. By doing so, we build systems that are resilient to delegation attacks and transparent in their operations.
Questions people ask
How do ai agents communicate securely in multi-agent systems?
Agents communicate securely by treating every message as untrusted input. They use signed capability tokens to prove authorisation for specific actions. They also maintain a provenance chain that records the original user intent. This ensures that even if an agent is compromised, the attacker cannot expand their permissions.
Are multi agent systems secure without explicit provenance?
No, they are not. Without explicit provenance, a system cannot distinguish between a legitimate request and a laundered one. An attacker can inject a command that looks valid but violates the original user's constraints. Provenance provides the context needed to enforce the principle of least privilege across delegation chains.
What is agent to agent protocol for secure communication?
A secure agent-to-agent protocol includes standardised fields for provenance and capabilities. It requires digital signatures to prevent tampering. It also defines how permissions are passed and verified during delegation. This protocol ensures that every agent can validate the authority of the request before executing it.
Close
The complexity of multi-agent systems is not a bug. It is a feature that enables powerful automation. But that complexity also creates opportunities for authority to be laundered. When agents talk to each other, they must carry the weight of the original request. They must not assume that trust is inherited.
We must build systems that prioritise provenance over identity. We must use capability tokens to enforce strict boundaries. We must treat every inter-agent message as a potential attack vector. This is not about paranoia. It is about engineering rigor.
The future of AI security lies in transparency. We need to see who asked for what, and why. We need to ensure that every action can be traced back to a valid permission. Only then can we build multi-agent systems that are both powerful and safe. The cost of ignoring this is too high. The risk of silent privilege escalation is real. We must address it now.