AI agents do not work alone anymore.
One agent researches. Another retrieves enterprise data. Another evaluates the information. Another calls an API. Another changes a record or triggers a workflow.
That creates a new security problem.
An organization may secure every agent individually and still lose control when identity, authority, sensitive data, context, and instructions move between them.
Consider a simple chain:
User → Agent A → Agent B → Agent C → Enterprise Data or Action
Agent A may start with permission to work only with a specific customer, geography, dataset, or business process.
But what happens when it delegates part of the task to Agent B?
Does Agent B inherit the user’s scope?
Does it receive Agent A’s broader permissions?
Can it pass those permissions to Agent C?
Can one agent disclose sensitive context to another agent that should never see it?
Can a compromised agent make a trusted peer perform an action it could not perform itself?
And when something goes wrong, can the security team reconstruct who requested the task, which agents participated, what authority moved between them, what data they touched, and which agent actually took the final action?
These questions define AI agent-to-agent security.
Multi-agent security is not simply about securing every agent. Organizations also need to secure the identity, trust, authority, data, context, and actions that move between agents.
Agent-to-Agent Security: Key Takeaways
• Individual agent security does not secure the whole workflow. Risk can emerge when agents delegate tasks, transfer context, inherit permissions, exchange data, or invoke one another.
• Authentication answers only part of the question. Teams also need to understand what authority one agent can delegate to another and whether that authority matches the original user’s intent.
• Authority should narrow as agents delegate. A downstream agent should not gain broader permissions simply because an upstream agent can reach them.
• Context creates data risk. Agents can expose sensitive information to peers through prompts, memory, messages, retrieved documents, tool output, and shared task state.
• Multi-agent systems cross trust domains. Enterprise agents may communicate with vendor agents, SaaS agents, partner systems, APIs, and autonomous services that follow different policies.
• BigID brings data context to agent identity and access. BigID connects AI identities, machine identities, permissions, sensitive data, activity, ownership, policy, and remediation so teams can govern the access behind multi-agent workflows.
What Is AI Agent-to-Agent Security?
AI agent-to-agent security is the practice of protecting the identity, authentication, authorization, delegation, communication, data, context, and actions exchanged when AI agents interact with other AI agents.
It applies when one agent:
- Discovers another agent
- Delegates a task
- Passes instructions or context
- Shares data
- Requests another agent’s capability
- Receives results from another agent
- Invokes an agent in another platform or trust domain
- Allows another agent to call tools or APIs
- Chains additional agents into the workflow
Agent-to-agent communication expands the security boundary beyond the individual AI system.
The organization now needs to answer six distinct questions:
Who is this agent?
Why should another agent trust it?
What authority can it delegate?
What data may cross the boundary?
What actions can the receiving agent perform?
What context should move with the task?
That creates a practical multi-agent security model:
Agent Identity + Trust + Delegation + Data + Context + Action
Govern AI Identity From the Data Out
Know which agents exist, what they inherit, and what sensitive data they can reach
Connect AI agents, copilots, service accounts, machine identities, permissions, ownership, activity, and sensitive-data exposure across enterprise AI workflows.
Why Multi-Agent Systems Change the Security Model
A single-agent architecture already creates new identity and access questions.
A multi-agent architecture multiplies them.
Imagine an enterprise workflow where:
- A user asks an orchestrator agent to prepare a customer renewal analysis.
- The orchestrator asks a research agent to collect public information.
- It asks a data agent to retrieve CRM, support, usage, and contract records.
- It asks a financial agent to calculate renewal economics.
- It asks an action agent to update the CRM and create follow-up tasks.
Each agent may use a different:
- Identity
- Service account
- API
- Permission set
- Cloud role
- OAuth grant
- Data source
- Vendor
- Model
- Policy boundary
Securing the orchestrator alone does not secure that workflow.
Neither does confirming that every participating agent has valid credentials.
The organization also needs to understand how trust and authority change at every handoff.
The Multi-Agent Security Path
Multi-Agent Security
Every handoff creates a new trust and authorization decision
Secure the workflow from the original user through every delegated agent and final data or action.
User
Defines intent and starting authority
Agent A
Interprets the task and delegates work
Agent B
Receives context, scope, and authority
Agent C
May introduce another identity or privilege set
Data + Action
Retrieve, share, update, execute, or trigger
Every arrow should preserve identity, restrict authority, protect data, and create evidence.
Agent-to-Agent Authentication Is Not Agent-to-Agent Authorization
Authentication establishes identity.
Authorization determines what that identity may do.
That distinction matters more in multi-agent systems because a trusted agent can still make an inappropriate request.
The current Agent2Agent Protocol, originally developed by Google and now part of the Linux Foundation ecosystem, supports interoperable communication among agents.
A2A treats agents as enterprise applications and relies on established web security practices for authentication. Each A2A server remains responsible for authorizing requests according to the authenticated identity, requested capability, data-access policy, scopes, and its own authorization model.
Its security guidance calls for authentication of requests, server-side authorization, least privilege, data privacy controls, and enterprise observability.
But a protocol cannot determine an organization’s business authorization policy by itself.
The receiving agent still needs to decide:
- Do I trust the calling agent?
- Which principal does it represent?
- What task did the original user approve?
- Which scope may the calling agent delegate?
- Which data may I return?
- Which actions may I perform?
- Can I delegate again?
Successful authentication proves that an agent presented acceptable credentials. It does not prove that every request from that agent deserves authorization.
The current A2A specification also recognizes the risk created by agent chains. It warns that in-band credential exchange can expose credentials to multiple agents participating in the chain and recommends binding credentials to the agent that originated the authorization request.
The longer the agent chain, the more important it becomes to preserve who requested the authority, who received it, and where that authority can travel.
Three Different Security Decisions
Identity alone does not determine authority
Who are you?
Verify the identity of the agent making the request.
What may you do?
Determine which data, capability, resource, or action the agent may access.
What may you pass on?
Control which authority and context the agent may transfer to another agent.
A trusted agent can still make an unauthorized request. An authorized agent can still delegate too much.
The Delegation Problem: Who Owns the Authority?
Delegation sits at the center of multi-agent security.
An agent often performs a task on behalf of someone else.
That creates a chain of principals:
User → Agent A → Agent B → Tool or Data
Security teams need to preserve enough context to understand both the immediate caller and the original authority behind the task.
Otherwise, downstream agents can gain privileges the original user never held or never intended to delegate.
Delegation Should Reduce Authority, Not Expand It
Suppose a regional sales leader asks an agent to analyze North American customers.
Agent A receives access appropriate to that purpose.
Agent A delegates part of the analysis to Agent B.
Agent B uses a global service account with access to every customer record.
Technically, Agent B has permission.
Operationally, the delegation has escaped its intended boundary.
Delegation Risk
Authority should stay bounded as the task moves
User
North America accounts
Agent A
Preserves user scope
Agent B
Uses global service account
Global Data
Authority expanded
The permission exists. The delegation still violates the intended boundary.
This distinction creates one of the most important principles for multi-agent access control:
Downstream authority should remain equal to or narrower than the authority legitimately delegated upstream.
The Confused Deputy Problem Comes Back With AI Agents
Multi-agent systems can create a modern form of the confused deputy problem.
A low-privilege agent may lack access to sensitive information.
But it may know another agent that has that access.
If the privileged agent trusts requests simply because they come from a recognized peer, the less-privileged agent may use the more-privileged agent as a path to resources it could not reach directly.
The workflow can look like:
Low-Privilege Agent → Trusted High-Privilege Agent → Sensitive Data
The privileged agent becomes the deputy.
Strong multi-agent authorization should evaluate:
- Who originated the request
- Which agent delegated it
- The intended business purpose
- The delegated scope
- The requested resource
- The sensitivity of the data
- The requested action
Identity alone cannot answer those questions.
Agent Context Can Leak Sensitive Data
Agents exchange more than commands.
They may exchange:
- Prompts
- Conversation history
- Retrieved documents
- Tool output
- Customer records
- Summaries
- Memory
- Structured data
- Files
- Credentials or secrets
- Intermediate reasoning artifacts exposed by the application
That makes agent-to-agent communication a data-security boundary.
Agent A may legitimately access sensitive information while performing its task.
Agent B may not need that information.
Passing Agent A’s entire working context to Agent B can silently expand sensitive-data exposure even when both agents operate as intended.
Delegating a task should not automatically mean delegating all of the context that produced it.
Organizations should minimize the information sent between agents according to purpose.
What Data Should One Agent Be Allowed to Send Another?
The answer depends on:
- Data sensitivity
- Business purpose
- The receiving agent’s identity
- The receiving agent’s owner
- Its permissions
- Its processing environment
- Its vendor or trust domain
- Applicable policies
- Regulatory requirements
- Retention behavior
- Downstream tools and agents
For example, a research agent may need a company name.
It may not need the customer’s payment information, employee PII, contract terms, credentials, or confidential support history.
Sensitive data discovery and classification give organizations the context to make these decisions according to the information involved rather than the agent name alone.
Cross-Domain Agent Security Raises the Stakes
Multi-agent workflows increasingly cross organizational and vendor boundaries.
An internal enterprise agent may invoke:
- A SaaS provider’s agent
- A cloud-provider agent
- A partner agent
- A marketplace agent
- An external research service
- An industry-specific AI service
The agents may not share the same:
- Identity provider
- Credential system
- Security policy
- Data classification scheme
- Audit model
- Retention rules
- Trust assumptions
A 2026 Internet-Draft on cross-domain agent-to-agent trust addresses this emerging problem by outlining requirements for agent identity, authentication, authorization, delegation, credential handling, revocation, and auditability.
The document remains a work in progress rather than an Internet standard, but the security problem it describes matters now.
Agent interoperability without interoperable trust can create a fast path for authority and sensitive data to move across security boundaries.
What Is the Agent2Agent Protocol?
Agent2Agent, or A2A, provides an open protocol that allows independent AI agents to discover capabilities, exchange information, collaborate on tasks, and communicate across different frameworks and vendors.
Google originally developed the protocol and later contributed it to the Linux Foundation ecosystem.
A2A and Model Context Protocol, or MCP, solve different interoperability problems:
| Protocol | Primary Connection | Security Focus |
|---|---|---|
| A2A | Agent to agent | Agent identity, authentication, authorization, task exchange, communication, delegation |
| MCP | AI application or agent to tools and data sources | Tool access, resources, connectors, permissions, data exposure |
A multi-agent workflow can use both.
An agent may use A2A to delegate work to another agent, while the receiving agent uses MCP or another integration layer to access enterprise systems.
That creates a connected security path:
Agent → Agent → Tool → Data → Action
Security teams need visibility across the complete chain.
Agent Discovery Creates Another Trust Decision
Multi-agent systems need ways to find agents and understand what they can do.
Agent registries, catalogs, capability descriptions, and mechanisms such as A2A Agent Cards can support discovery.
But discovery creates security questions of its own:
- Who registered the agent?
- Can teams verify its identity?
- Who owns it?
- Can an attacker impersonate it?
- Did its capabilities change?
- Which authentication schemes does it use?
- Which data domains can it access?
- Should enterprise agents trust it automatically?
An agent’s presence in a directory should not automatically establish unlimited trust.
Discovery identifies a potential collaborator.
Authentication confirms an identity.
Authorization determines what that identity may request.
Governance determines whether the organization should permit the relationship at all.
Prompt Injection Can Propagate Across Agents
Prompt injection becomes more complicated in multi-agent systems because one compromised interaction can influence downstream agents.
Consider:
Malicious Document → Agent A → Agent B → Action Agent
Agent A retrieves a malicious document.
The document contains instructions that alter Agent A’s task.
Agent A passes manipulated instructions or context to Agent B.
Agent B treats Agent A as a trusted peer.
Agent B then invokes an action agent.
The initial injection has now crossed multiple trust boundaries.
This means organizations should not automatically treat inter-agent content as trusted simply because another approved agent generated it.
A trusted sender does not guarantee trustworthy context.
AI Agent-to-Agent Security Risks
Several risks become particularly important in multi-agent environments.
Unscoped Privilege Delegation
One agent passes broader authority to another agent than the delegated task requires.
Confused Deputy Attacks
A lower-privilege agent uses a more-privileged agent to access data or perform an action outside the original scope.
Identity Loss
Downstream systems can see the immediate agent but lose the identity of the original user, application, or workflow that initiated the request.
Context Leakage
An agent shares sensitive information, conversation history, retrieved data, or memory with another agent that does not need it.
Cross-Domain Trust Failure
Agents from different organizations or platforms trust one another without sufficient identity, authorization, policy, or data controls.
Agent Impersonation
An attacker registers, spoofs, or compromises an agent and attempts to gain trust from legitimate peers.
Delegation Loops and Agent Sprawl
Agents repeatedly delegate work, creating chains that become difficult to inventory, trace, limit, or terminate.
Insecure Inter-Agent Communication
Weak message authentication, integrity controls, replay protection, or transport controls can expose agent communication to manipulation.
Authority Expansion Through Service Accounts
A downstream agent uses an application or service account whose permissions exceed the authority of the user or upstream agent.
Action Without Traceability
Multiple agents contribute to a decision, but logs show only the identity that executed the final action.
Individual Agent Security vs. Multi-Agent Security
| Security Question | Single Agent | Multi-Agent System |
|---|---|---|
| Identity | Which agent is acting? | Which agents participated, and who originated the task? |
| Access | What can this agent reach? | What authority propagates when agents delegate? |
| Data | What sensitive data can the agent access? | What data can one agent expose to another? |
| Trust | Should the organization trust this agent? | Why should agents trust each other across every handoff? |
| Action | What can this agent do? | Which agent made the decision and which agent executed it? |
| Audit | Can teams trace the agent’s activity? | Can teams reconstruct the full delegation and decision chain? |
Individual agent identities are necessary. They are not sufficient for multi-agent security.
OWASP Is Moving Agent Security Toward Runtime Control
The OWASP Agent Control Standard, published in September 2026, reflects an important market shift.
OWASP argues that enterprises need agents that teams can inspect, trace, instrument, and control at runtime.
Organizations need visibility into:
- What agents are
- What they can access
- What they did
- Why they acted
- How teams can apply policy at runtime
That moves agent security beyond pre-deployment approval.
Multi-agent systems change continuously as agents gain new tools, peers, permissions, data sources, models, and business responsibilities.
Agent security cannot stop at registration or deployment. Controls need to follow agents as their identities, access, peers, tools, data, and authority change at runtime.
Identity Risk Needs Data Context
Know what every agent can reach before authority moves downstream
Connect agents, service accounts, machine identities, APIs, permissions, access paths, sensitive data, ownership, and activity to identify where AI access exceeds legitimate business need.
How to Secure Agent-to-Agent Communication
1. Inventory Every Agent
Identify agents, copilots, assistants, orchestrators, autonomous workflows, AI-enabled applications, and third-party agents.
Record:
- Owner
- Business purpose
- Environment
- Connected agents
- Machine identities
- Service accounts
- Data access
- Tools
- Permitted actions
AI Identity Governance provides the foundation for understanding which AI-powered identities operate across the enterprise.
2. Authenticate Every Agent Boundary
Do not rely on network location or prior interaction as proof of identity.
Validate identities at agent-to-agent boundaries and use appropriate enterprise authentication controls.
3. Authorize the Task, Not Just the Agent
A trusted agent should not receive unlimited permission to request every capability.
Evaluate:
- The requested skill
- The task
- The original principal
- The delegated scope
- The target data
- The requested action
4. Keep Delegated Authority Bounded
When Agent A delegates to Agent B, do not automatically transfer Agent A’s complete permission set.
Grant only the authority Agent B needs for the delegated task.
5. Preserve the Principal Chain
Maintain enough identity context to trace a workflow back through the delegation chain.
Teams should be able to answer:
Who initiated this?
Which agents handled it?
Which identity accessed the data?
Which agent made the decision?
Which agent executed the action?
6. Minimize Inter-Agent Data Sharing
Pass only the context another agent needs.
Do not automatically forward full prompts, conversation histories, customer records, retrieved documents, or sensitive metadata.
7. Connect Agent Access to Data Sensitivity
The same permission can create very different risk depending on the information behind it.
Discover and classify sensitive data, then connect it with AI identities, machine identities, and effective permissions.
8. Apply Least Privilege to AI and Machine Identities
Agents commonly act through service accounts, APIs, applications, cloud roles, OAuth grants, and other machine identities.
Machine Identity Security helps organizations understand the machine-driven access behind AI workflows.
9. Treat Agent Messages as Untrusted Input
A trusted peer can still send compromised, manipulated, incorrect, or malicious context.
Apply input, prompt, data, and policy controls to inter-agent communication.
10. Restrict Agent Actions
Separate read, write, execute, approve, delete, send, publish, and administrative authority.
Require human approval for consequential actions where appropriate.
11. Monitor Agent Activity
Permissions describe potential behavior.
Activity shows actual behavior.
Data Activity Monitoring can add context around how sensitive information gets accessed, moved, shared, modified, downloaded, or deleted.
12. Build Revocation and Remediation Into the System
Teams need ways to:
- Disable an agent
- Remove a peer relationship
- Revoke credentials
- Reduce permissions
- Block a data source
- Restrict a tool
- Quarantine risky data
- Assign remediation
- Investigate affected data
Remediation workflows help move identity and data risk findings into corrective action.
The Multi-Agent Trust Test
Agent-to-Agent Security Readiness Checklist
Multi-Agent Security Readiness
Can your security team answer these questions?
✓ Which AI agents can communicate with other agents?
✓ Who owns each agent?
✓ Can we verify agent identities across every handoff?
✓ Can we trace the original human, application, or workflow behind a delegated task?
✓ Which permissions can one agent delegate to another?
✓ Can downstream agents gain broader authority than the original requester?
✓ Which sensitive data can agents exchange?
✓ Do we minimize context during agent handoffs?
✓ Which machine identities and service accounts support agent workflows?
✓ Can a lower-privilege agent invoke a more-privileged agent?
✓ Which agent interactions cross vendor or trust-domain boundaries?
✓ Can one compromised agent manipulate a trusted peer?
✓ Which actions require human confirmation?
✓ Can we trace data access across the complete agent chain?
✓ Can we revoke an agent or delegated permission quickly?
✓ Can we prove what happened after an incident?
How BigID Approaches Agent-to-Agent Security
BigID approaches multi-agent security from the identity and data behind every interaction.
Agent authentication matters.
But organizations also need to understand which AI identities participate in the workflow, which machine identities carry their access, what permissions they inherit, what sensitive data they can reach, how that data moves, and where authority exceeds legitimate business purpose.
BigID helps organizations:
- Discover and govern AI identities: Inventory agents, copilots, AI applications, autonomous workflows, owners, inherited permissions, activity, and lifecycle context.
- Govern AI access: Connect agents and AI systems to the sensitive enterprise data, applications, APIs, service accounts, and permissions behind their access.
- Secure machine identities: Identify service accounts, applications, APIs, workloads, tokens, and other machine identities that AI systems use to access enterprise resources.
- Add sensitive-data context: Identify personal, regulated, confidential, proprietary, credential, financial, health, and business-critical information behind agent access.
- Identify excessive access: Find broad, stale, inherited, unnecessary, or high-risk permissions that can expand the blast radius of delegated agent authority.
- Strengthen least privilege: Prioritize access reduction using identity, permission, sensitivity, exposure, ownership, and business context.
- Add activity context: Understand how identities access, move, share, modify, download, or delete sensitive information.
- Connect identity with AI governance: Link AI assets with data, lineage, ownership, access, policy, risk, monitoring, and governance evidence.
- Drive remediation: Reduce access, enforce policy, assign owners, and coordinate corrective action when agent access creates exposure.
BigID’s role is not to replace the authentication protocol that allows agents to communicate. BigID adds the data-aware identity, access, exposure, activity, governance, and remediation context organizations need to understand whether those agent relationships create risk.
That distinction becomes increasingly important as multi-agent workflows cross more applications, APIs, cloud platforms, data stores, identities, and trust domains.
Agent-to-agent security should preserve more than connectivity. It should preserve intent, authority, accountability, and control all the way to the data.
Connect the Dots Across Data & AI
Govern Every Agent That Can Reach Sensitive Data
See how BigID connects AI identities, machine identities, permissions, sensitive data, activity, ownership, exposure, policy, and remediation across enterprise agent workflows.
AI Agent-to-Agent Security FAQs
What is AI agent-to-agent security?
AI agent-to-agent security protects the identity, trust, authentication, authorization, delegation, communication, sensitive data, context, and actions exchanged when AI agents interact with other AI agents.
What is multi-agent security?
Multi-agent security protects systems in which multiple AI agents collaborate, delegate tasks, exchange information, access resources, and take actions. It extends security beyond individual agents to the relationships, trust boundaries, permissions, data flows, and delegation chains between them.
Why is agent-to-agent security important?
Agent-to-agent interactions can transfer sensitive information, permissions, instructions, and authority across several AI systems. Without strong controls, downstream agents may gain excessive access, expose data, misuse trusted peers, or perform actions beyond the original user’s intent.
What is agent-to-agent authentication?
Agent-to-agent authentication verifies the identity of an AI agent that requests communication or services from another agent. Authentication establishes who the caller is, while authorization determines which capabilities, data, or actions that agent may use.
What is agent-to-agent authorization?
Agent-to-agent authorization determines what an authenticated agent may request or do. It can consider the agent’s identity, original principal, delegated scope, requested task, target data, available skills, permissions, policy, and business purpose.
What is AI agent delegation?
AI agent delegation occurs when one agent assigns part or all of a task to another agent. Secure delegation should preserve the original task context while limiting the downstream agent to only the authority and data it requires.
Why should delegated permissions become narrower?
A downstream agent should not receive more authority than the original user or delegating agent intended to provide. Narrowing delegated scope reduces excessive access and limits the impact if an agent becomes compromised or manipulated.
What is the confused deputy problem in AI agents?
The confused deputy problem occurs when a lower-privilege agent convinces or manipulates a more-privileged agent into accessing data or performing an action that the lower-privilege agent could not perform directly.
What data risks exist between AI agents?
Agents can expose sensitive data through prompts, retrieved documents, messages, memory, tool output, structured payloads, files, APIs, and shared task context. Organizations should minimize inter-agent data sharing and apply policy according to sensitivity and purpose.
How does prompt injection affect multi-agent systems?
Prompt injection can enter one agent through untrusted content and then propagate through agent messages, delegated tasks, shared context, or tool output. Downstream agents should not treat content as safe simply because another trusted agent supplied it.
What is the Agent2Agent protocol?
Agent2Agent, or A2A, is an open protocol for communication and collaboration between independent AI agents. It supports agent discovery, task exchange, authentication patterns, authorization, interoperability, and enterprise communication across different agent frameworks and vendors.
What is the difference between A2A and MCP?
A2A primarily supports communication and collaboration between agents. MCP primarily connects AI applications and agents with tools, resources, and data sources. A multi-agent workflow can use both protocols.
How should organizations secure multi-agent AI systems?
Organizations should inventory agents, authenticate agent boundaries, authorize specific tasks, limit delegated authority, preserve principal context, minimize data sharing, apply least privilege, govern machine identities, restrict actions, monitor activity, maintain audit trails, and support rapid revocation and remediation.
How does BigID support agent-to-agent security?
BigID connects AI identities, machine identities, service accounts, permissions, sensitive data, activity, ownership, exposure, policy, and business context. This helps organizations identify excessive agent access, strengthen least privilege, govern AI identity risk, monitor sensitive data usage, and drive remediation across multi-agent environments.
Author
