How should security teams govern Agent2Agent communication in production?

Why This Matters for Security Teams

Agent2Agent communication is not just another service-to-service pattern. Once one agent can discover peers, request tools, or hand off work at runtime, security teams are governing a living identity fabric with autonomous behaviour, not a static integration map. That shifts the problem from simple authentication to ownership, authorisation, traceability, and offboarding across every agent workflow.

The risk is amplified by the same failure patterns seen across NHIs generally: excessive privilege, weak lifecycle controls, and poor visibility. NHI Management Group notes that 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and revocation processes in place, which is especially dangerous when an agent can chain requests across multiple systems. Current guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime governance rather than trust-by-default. In practice, many security teams encounter peer-to-peer agent abuse only after an agent has already made an unexpected tool call or exfiltrated data through a legitimate workflow.

How It Works in Practice

Production governance for Agent2Agent communication should start with workload identity, not shared secrets. Each agent needs a unique cryptographic identity and a bounded trust zone, so the platform can prove what the agent is and what task it is allowed to perform. In many environments, that means pairing short-lived tokens with policy evaluation at request time, rather than relying on static roles that assume a fixed access pattern. For agentic systems, static RBAC often breaks down because the agent’s behaviour is goal-driven and can change based on context.

Security teams should require:

• Scoped authentication for each agent, service, or workflow hop.
• Traceable task IDs that follow the request chain across agents and tools.
• JIT credentials or ephemeral tokens that expire when the task ends.
• Policy-as-code decisions evaluated in real time, not only at deployment.
• Offboarding hooks that revoke peer trust, keys, and delegated permissions immediately.

That model aligns with emerging practice described in NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize governance, observability, and risk-based controls for autonomous systems. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces that lifecycle management is not optional when identities can act without human intervention. These controls tend to break down when agents are allowed to self-register peers in loosely governed environments because the trust relationship expands faster than the audit model can follow.

Common Variations and Edge Cases

Tighter agent-to-agent controls often increase orchestration overhead, requiring organisations to balance runtime safety against latency, developer friction, and operational complexity. That tradeoff is real, especially in multi-agent pipelines where one workflow may span discovery, planning, tool use, and approval steps across several systems.

There is no universal standard for this yet, so teams should treat some practices as evolving guidance rather than settled doctrine. For example, intent-based authorisation is increasingly recommended, but the exact policy language, enforcement point, and audit granularity vary by platform. In regulated environments, a stronger stance is usually warranted: agent peers should be pre-approved, communication should be limited to named tasks, and any deviation should trigger step-up controls or human review.

Edge cases include agents that broker actions across vendors, agents embedded in CI/CD pipelines, and agents that inherit permissions from human sessions. Those scenarios create a wider blast radius because the agent may appear legitimate at every hop while still exceeding intended scope. For that reason, use the NIST Cybersecurity Framework 2.0 for control mapping and OWASP NHI Top 10 to pressure-test whether agent identities, secrets, and delegation paths are actually governed. The hardest failures appear when a supposedly internal agent is allowed to discover and trust new peers dynamically, because that turns one misconfiguration into a self-propagating trust problem.

Related resources from NHI Mgmt Group

• How should security teams govern shadow agents in production workflows?
• How should security teams govern Google Vertex AI access in production environments?
• How should security teams govern AI pilot identities before production?
• How should security teams govern non-human identities at scale?