TL;DR: The core issue is that agentic systems break the assumption that identity, context, and execution stay in a single, reviewable flow, and Agent Gateway extends AI governance from LLM and MCP traffic into agent-to-agent communication, giving enterprises policy enforcement, observability, and audit logging across the full AI data path, according to Kong.
At a glance
What this is: Kong’s Agent Gateway extends AI governance into agent-to-agent traffic, with policy, observability, and logging across the full AI data path.
Why it matters: It matters because multi-agent systems create new identity and authorisation boundaries that existing API and LLM controls do not fully cover, especially for NHI, agentic AI, and lifecycle governance.
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
👉 Read Kong’s release on Agent Gateway for agent-to-agent AI governance
Context
Agent-to-agent communication changes the governance problem from a single request and response path to a dynamic network of delegated actions, tool calls, and event-driven exchanges. That matters for AI gateway security because identity, context, and execution are now distributed across multiple actors rather than anchored to one controlled transaction.
The practical gap is not just visibility. When agents can negotiate, hand off tasks, and consume data across APIs, MCP servers, and event streams, existing IAM and API controls may protect the edge but still miss the movement inside the workflow. Kong’s release is positioned against that gap, which is now a common concern in agentic AI governance.
For teams building production agentic systems, the central question is how to govern communication between non-human actors without creating blind spots, custom proxies, or disconnected point solutions. The issue is increasingly one of enterprise identity governance, not just API management.
Key questions
Q: How should security teams govern agent-to-agent communication in production?
A: Security teams should treat agent-to-agent communication as a separate governance layer, not just another API call. That means binding each agent to a durable identity, defining which peers it can communicate with, logging every handoff, and inspecting content in transit so delegated actions cannot propagate without control.
Q: Why do multi-agent systems create new identity governance risks?
A: Multi-agent systems create new identity governance risks because authority is no longer confined to a single actor or request. Once one agent can delegate to another, the effective blast radius expands through the chain, and existing IAM controls may miss how far context and privilege can travel.
Q: What breaks when AI governance stops at LLM traffic?
A: Governance stops being effective when it covers only model prompts and responses because agents also exchange tool calls, delegated tasks, and event-driven context. That leaves blind spots in authorisation, logging, and policy enforcement exactly where the most consequential actions can occur.
Q: Who is accountable when an AI agent passes unsafe instructions to another agent?
A: Accountability should rest with the programme that allowed the delegation path, the policy that permitted the exchange, and the owner of the runtime identity that executed it. If the organisation cannot reconstruct that chain, it does not have a defensible control model for agentic AI.
How it works in practice
Agent-to-agent communication and the full AI data path
Agent-to-agent communication, often described as A2A, lets one agent discover, negotiate with, and delegate work to another agent without human mediation. In a production stack, that sits alongside LLM calls, MCP tool access, APIs, and event streams. The governance challenge is that each hop can carry new context and new authority, so the control point must understand not just a single request but the chain of delegated intent. That is why AI gateway design is shifting from model protection toward path governance across multiple runtime surfaces.
Practical implication: map every agent handoff and treat each hop as a separate authorisation boundary.
Agent identity, authentication, and audit logging
Agent identity in multi-agent systems is not the same as user identity. An agent needs to be identified as a runtime actor, authenticated as that actor, and traced across its interactions so that policy and forensic records remain coherent. Without that, access decisions become detached from the actor making them, and audit logs lose the ability to reconstruct who or what triggered downstream action. Real governance therefore depends on stable agent identity, transaction-level attribution, and logs that preserve enough context to support compliance and incident response.
Practical implication: bind every agent action to a durable identity record and retain end-to-end audit evidence.
Real-time inspection for prompt injection and policy violations
Real-time traffic inspection matters because prompt injection is no longer only a model input problem. In agentic systems, malicious instructions can arrive through inter-agent messages, tool outputs, or shared context and then propagate through the workflow before a human sees them. Inspection at the gateway layer can detect policy violations in transit, but only if it evaluates the content being exchanged, the destination agent, and the permitted scope of the interaction. That turns the gateway into a boundary control for delegated AI behaviour rather than a simple traffic filter.
Practical implication: inspect agent messages in flight and block unsafe delegation before it spreads.
NHI Mgmt Group analysis
Agent-to-agent governance is becoming the missing middle of AI identity control. LLM gateways protected a linear model interaction, but agentic systems now move context through delegated workflows that can traverse tools, APIs, and event streams. That creates a governance layer that is neither classic IAM nor pure API security. Practitioners need to treat A2A as a distinct control surface because the authority to act is no longer concentrated in one request.
Identity blast radius is the right concept for multi-agent systems. Once one agent can influence another, the impact of a compromised or over-entitled actor expands beyond its own privileges into the next hop in the chain. That is why policy, observability, and audit need to follow the delegation path, not just the originating agent. The implication is that entitlements must be evaluated by reachable downstream effect, not by the first actor alone.
Agent identity & authentication is the governance prerequisite, not a nice-to-have. If an agent cannot be bound to a durable identity and distinguished from every other runtime actor, then logging, policy enforcement, and cost attribution all become ambiguous. This is the same structural problem NHIs created for service accounts, but agentic systems amplify it because the actor can select tools and initiate follow-on actions dynamically. Practitioners should not assume human-style controls will survive this shift.
Runtime delegation boundaries: The control failure here is not just missing policy, but assuming delegation stays reviewable once it enters autonomous, multi-hop execution. That assumption breaks when agents hand off context faster than humans can observe or certify it. The implication is that governance programmes must stop treating delegated AI action as a single transaction and start treating it as a chain of independently meaningful identity events.
The market is moving toward platform-level AI governance, but the control problem remains cross-domain. A2A, MCP, APIs, and event management now converge into one operational question: who or what can cause action, on what data, and under what recorded authority. That is why the next generation of identity governance will blend NHI policy, agent runtime controls, and lifecycle accountability. Teams that keep these domains separate will miss the compounded risk.
From our research:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- As agent governance matures, teams should also look at OWASP NHI Top 10 for the control patterns that sit alongside gateway policy.
What this signals
Runtime delegation boundaries: Multi-agent programmes will increasingly fail at the handoff points, not at the model edge. Teams that can already trace agent identity, tool access, and downstream action will be able to separate controlled delegation from uncontrolled sprawl before production incidents force the issue.
The most practical near-term signal is whether your telemetry can answer a simple question: which agent caused which other agent to act? If you cannot answer that today, your AI governance programme is still operating below the threshold where agentic workflows become auditable, containable, and reviewable.
With 80% of organisations already reporting agents acting beyond intended scope, per AI Agents: The New Attack Surface report, the governance window is closing quickly. The next step is not more enthusiasm for agentic automation, but tighter control over delegation, identity binding, and inspection.
For practitioners
- Inventory every agent delegation path Document which agents can call which tools, which peers they can delegate to, and which data sources they can reach. Treat each permitted hop as a distinct boundary that requires policy, identity, and logging.
- Bind agent actions to durable identities Require every agent participating in production workflows to authenticate as a stable runtime actor so downstream logs, access decisions, and investigations can be attributed without ambiguity.
- Inspect agent traffic in flight Place policy enforcement where agent messages, tool outputs, and delegated prompts are exchanged so prompt injection and unauthorised instructions can be blocked before propagation.
- Measure the downstream blast radius of each agent Review whether one compromised or over-entitled agent can trigger other agents, tools, or event streams to act beyond intended scope. Use that analysis to prioritise the highest-risk chains first.
Key takeaways
- Agent-to-agent communication creates a governance problem that classic LLM gateways and API controls do not fully solve.
- The key evidence is the delegation chain itself, where identity, context, and authority can spread across multiple autonomous hops.
- Practitioners need durable agent identity, in-flight inspection, and full-path auditability before multi-agent production use expands further.
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 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2A-03 | Covers agent-to-agent communication, tool misuse, and delegated AI action. |
| NIST AI RMF | Addresses governance for autonomous AI behaviour and accountability. | |
| NIST CSF 2.0 | PR.AC-4 | Access control and identity enforcement apply directly to agent identities. |
Treat agents as governed identities and review their access paths against least-privilege expectations.
Key terms
- Agent-to-agent communication: Agent-to-agent communication is the exchange of tasks, context, and instructions between two software agents without a human intermediary. In identity terms, it creates a governance boundary between non-human actors that must be authenticated, authorised, and logged like any other sensitive execution path.
- AI gateway: An AI gateway is a control layer that sits between AI workloads and the systems they use, enforcing policy, observation, and routing decisions. For agentic systems, it becomes part of identity governance because it can constrain which agents act, what data they access, and how those actions are recorded.
- Identity blast radius: Identity blast radius is the scope of damage that can result when one identity is compromised, over-entitled, or misused. In multi-agent systems, the term extends beyond the first actor to the downstream agents, tools, and data sources that can be triggered through delegation.
- Runtime delegation boundary: A runtime delegation boundary is the point at which one identity hands authority, context, or work to another identity during execution. In agentic AI, these boundaries are dynamic and can change mid-session, which is why they need policy and audit controls rather than static assumptions.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.
This post draws on content published by Kong: Introducing Kong Agent Gateway, the complete AI gateway for agent-to-agent communication. Read the original.
Published by the NHIMG editorial team on 2026-04-14.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org