They often treat it as messaging infrastructure instead of delegated identity. If one agent can assign work to another, that handoff is a governance decision with access implications. IAM teams should require the same level of review for agent peers that they would require for privileged service accounts or other non-human identities.
Why This Matters for Security Teams
Agent-to-agent collaboration looks like simple orchestration, but it is really delegated authority in motion. When one agent can ask another to search data, open tickets, run code, or call APIs, the handoff becomes an identity event with access implications. That is why treating agent communication as plain messaging is a category error. The security question is not just who sent the message, but what authority was implicitly transferred.
This is where traditional IAM assumptions start to fail. Static roles were built for predictable human job functions, not autonomous software that can chain tools, re-plan tasks, and negotiate with peers in real time. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime controls, not trust by design. NHIMG research on the OWASP NHI Top 10 reinforces that agentic systems need identity-aware governance at each trust boundary. In practice, many security teams encounter delegated privilege after an agent has already used another agent to widen access, rather than through intentional design review.
How It Works in Practice
Agent-to-agent collaboration should be governed as delegated workload identity, not as an open internal chat channel. Each agent needs a verifiable identity, a bounded scope, and a policy decision at the moment it attempts a handoff. Best practice is evolving, but current guidance suggests using workload identity primitives such as OIDC-backed tokens or SPIFFE-style identities to prove what the agent is, then evaluating whether the receiving agent may accept the task.
That means IAM teams should define the following controls:
- Require explicit authorization for agent-to-agent delegation, including task type, data class, and destination system.
- Use just-in-time, short-lived credentials for each collaboration step instead of reusable secrets.
- Apply policy-as-code at request time so the decision reflects live context, not a pre-approved relationship.
- Log the delegation chain so incident responders can reconstruct which agent expanded the blast radius.
This matters because agent peers can be chained across tools in ways that humans rarely anticipate. The practical model is closer to runtime trust evaluation than messaging ACLs. The CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix both support threat modeling around chained actions, while NHIMG’s AI LLM hijack breach coverage shows how quickly one compromised workflow can influence another. These controls tend to break down in loosely governed multi-agent pipelines because peer trust is inferred from transport reachability instead of verified delegated authority.
Common Variations and Edge Cases
Tighter control over agent collaboration often increases latency and policy overhead, so organisations have to balance autonomy against containment. That tradeoff becomes visible when teams support multiple agent classes, such as one agent that drafts actions and another that executes them. Current guidance suggests treating these as different trust tiers rather than equal peers.
There is no universal standard for this yet, but several edge cases recur:
- Shared group identities blur accountability when multiple agents appear under the same service account.
- Long-lived secrets in shared toolchains make peer delegation effectively permanent, which defeats least privilege.
- Cross-domain collaboration, especially across SaaS and cloud boundaries, can create hidden trust paths that IAM cannot see from one tenant alone.
NHIMG’s 2024 Non-Human Identity Security Report found that only 19.6% of security professionals express strong confidence in their organisation’s ability to securely manage non-human workload identities, which is a useful indicator of how immature these delegation models still are. In these edge cases, the right response is usually to narrow the agent’s authority, separate execution from planning, and require human approval for high-impact peer handoffs. That guidance breaks down when agents are allowed to self-orchestrate across highly privileged internal APIs without per-task review because the delegation path becomes too dynamic to audit after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent-to-agent delegation creates runtime trust and abuse paths covered by agentic AI risks. |
| CSA MAESTRO | T1 | MAESTRO addresses threat modeling for autonomous agent collaboration and chained actions. |
| NIST AI RMF | GOVERN | AI RMF governance is relevant because delegated agent actions need accountability and oversight. |
Treat agent handoffs as privileged actions and enforce request-time authorization for every delegation.
