Cross-Agent Trust Exploitation

Cross-Agent Trust Exploitation occurs when an attacker compromises or manipulates one AI agent and abuses the implicit trust relationships between agents to influence other agents, invoke privileged capabilities, access restricted information, or propagate malicious instructions across a multi-agent environment.

Enterprise AI architectures are increasingly evolving from individual assistants into interconnected systems of specialized agents that communicate, delegate tasks, exchange context, invoke tools, and make decisions on behalf of one another.

These architectures introduce a significant security problem: agent-to-agent trust.

A receiving agent may assume that a request originating from another authorized agent is legitimate. If that trust is not independently verified, compromising one agent can provide an attacker with a path into other agents and capabilities that were never directly exposed to the attacker.

For example, an attacker may manipulate a low-privileged research agent through indirect prompt injection. That agent could subsequently send instructions to an operations agent capable of accessing internal APIs or modifying enterprise resources.

If the operations agent trusts the originating agent without independently validating the request’s authorization, scope, and intent, the attacker may effectively move laterally through the AI environment.

Cross-Agent Trust Exploitation therefore creates an AI-native form of trusted relationship abuse and lateral movement.

The security boundary cannot simply be:

“This request came from another trusted agent.”

Each agent and downstream tool must independently determine whether the requested action is authorized.

The attack begins when an adversary gains influence over an AI agent.

That influence may originate from direct prompt injection, indirect prompt injection, poisoned RAG content, compromised memory, malicious external content, agent identity impersonation, or another attack vector.

The attacker then identifies other agents, tools, APIs, or workflows trusted by the compromised agent.

Instead of directly attacking those systems, the adversary causes the compromised agent to issue legitimate-looking requests on the attacker’s behalf.

Potential attack patterns include:

• Agent-to-agent instruction injection
• Unauthorized task delegation
• Agent identity spoofing
• Context manipulation
• Delegated privilege abuse
• Cross-agent prompt propagation
• Tool invocation through another agent
• Authorization inheritance
• Compromised agent memory propagation
• Malicious task-chain creation
• Higher-privileged agent invocation
• Cross-agent data retrieval

The central vulnerability occurs when trust in the originating agent substitutes for independent authorization of the requested action.

1. Initial Agent Compromise
The attacker gains influence over an accessible AI agent.

2. Trust Relationship Discovery
The attacker identifies agents, tools, services, APIs, or workflows that accept requests from the compromised agent.

3. Malicious Task Creation
The compromised agent is manipulated into generating a malicious or unauthorized downstream request.

4. Agent-to-Agent Delegation
The request is transmitted to another trusted agent.

5. Trust Boundary Failure
The receiving agent accepts the request based primarily on the identity or trusted status of the originating agent.

6. Privileged Capability Invocation
The downstream agent accesses capabilities unavailable to the original attacker or compromised agent.

7. Lateral Movement
Additional agents, tools, APIs, data stores, or enterprise systems may become reachable.

8. Enterprise Impact
The attacker performs unauthorized actions, retrieves sensitive information, manipulates workflows, or expands control across the agent ecosystem.

Attack path:

Attacker → Compromised Agent → Trusted Agent Relationship → Higher-Privilege Agent → Tool/API → Enterprise Resource

• Multi-agent AI architectures
• Enterprise AI agents
• Agent orchestration platforms
• Agent-to-agent communication systems
• MCP-enabled environments
• AI workflow automation
• Coding agents
• Research agents
• Operations agents
• Security agents
• Cloud administration agents
• Customer service agents
• RAG-enabled agents
• Tool-enabled LLM applications
• Enterprise APIs
• Agent memory systems
• Shared context stores

Multi-agent AI architectures can transform the compromise of a single low-privileged agent into a broader enterprise security event.

A compromised agent may become a trusted intermediary through which an attacker accesses capabilities they could not reach directly.

Potential consequences include:

• Unauthorized access to enterprise data
• Privileged tool execution
• Cloud infrastructure modification
• Identity and permission changes
• Unauthorized communications
• Sensitive data disclosure
• Manipulation of business processes
• Compromise of downstream agents
• Persistent poisoned context
• Cross-system lateral movement
• Expansion from AI compromise into traditional enterprise infrastructure

The business risk increases significantly when organizations deploy specialized agents with different privilege levels but allow those agents to implicitly trust requests from one another.

For Redbot, the critical testing question is:

If we compromise the least-trusted agent in your environment, how far can we travel through the agents that trust it?

That is a strong Attack the Stack™ test because the attack begins in the AI layer but can ultimately reach identity, APIs, applications, data, cloud infrastructure, and other enterprise systems.

Redbot testing should begin by mapping the complete agent trust architecture.

Identify:

• Which agents communicate with one another
• Which agents can delegate tasks
• Which identities agents use
• Which tools each agent can invoke
• Which APIs are reachable
• Whether permissions differ between agents
• Whether agents inherit authorization
• Whether downstream agents independently authorize requests

Then attempt controlled compromise of a lower-privileged agent.

Test whether that agent can:

• Request actions from higher-privileged agents
• Access tools indirectly through another agent
• Retrieve information outside its own permissions
• Inject instructions into downstream agent context
• Modify delegated task parameters
• Impersonate another agent
• Manipulate agent identity metadata
• Propagate poisoned context
• Trigger recursive delegation
• Invoke MCP tools through another agent
• Cause downstream agents to retain malicious instructions
• Circumvent user-level authorization through agent delegation

A particularly important test is:

Can Agent A perform an action through Agent B that Agent A would be prohibited from performing directly?

If yes, the multi-agent architecture may contain a cross-agent privilege or trust-boundary vulnerability.

Testing should also determine whether authorization follows the original user identity through the complete execution chain.

Monitor for:

• Unexpected agent-to-agent communication
• New or unusual delegation chains
• Requests outside an agent’s normal function
• Low-privileged agents invoking high-privileged agents
• Agent identity inconsistencies
• Abnormal tool invocation
• Repeated cross-agent requests
• Sudden changes in delegation behavior
• Unauthorized API activity
• Sensitive data crossing agent boundaries
• Agent requests originating after external content retrieval
• Unusual MCP capability invocation
• Recursive or excessive delegation
• Downstream actions inconsistent with the initiating user’s privileges
• Agent activity without attributable initiating identity

Logging should preserve the complete execution chain:

User → Agent A → Agent B → Agent C → Tool → API → Data

Security teams should be able to reconstruct who initiated an action, which agents participated, which authorization decisions occurred, and which enterprise resources were ultimately accessed.

MITRE ATT&CK T1199 — Trusted Relationship Relevant where an attacker abuses established trust relationships between components to extend access. T1078 — Valid Accounts Potentially applicable where compromised or legitimate agent identities are used to access downstream systems. T1098 — Account Manipulation May apply where agent identity or permissions are modified to maintain or expand access. T1021 — Remote Services May be relevant where agent-to-agent interactions or downstream execution traverse exposed services. MITRE ATLAS Cross-Agent Trust Exploitation should additionally be evaluated against applicable ATLAS techniques involving AI system manipulation, prompt-based compromise, and abuse of AI-enabled system relationships.

OWASP Relevant OWASP GenAI security concepts include: LLM01 — Prompt Injection Prompt injection may provide the initial mechanism used to compromise an agent and influence downstream behavior. LLM06 — Excessive Agency Excessive permissions, functionality, and autonomy can increase the impact of cross-agent exploitation. OWASP Agentic AI Security Agent identity, authorization, tool access, delegation, excessive autonomy, and trust boundaries are directly relevant to multi-agent security architectures.