Kong Agent Gateway expands governance across agent-to-agent traffic

At a glance

What this is: This is a product release about Kong extending AI governance from model and tool traffic into agent-to-agent communication, with the key finding that multi-agent architectures create visibility and policy gaps that linear gateway models do not cover.

Why it matters: It matters because IAM, PAM, and AI governance teams now have to control agent identity, delegation, data movement, and auditability across a wider execution path, not just at model or API boundaries.

Context

Kong Agent Gateway addresses a governance gap in agentic AI architectures, where agents do not simply call a model and stop. They call tools, delegate tasks to other agents, and exchange event streams, which breaks the assumption that AI traffic can be reviewed as one linear interaction.

For identity and access teams, the issue is not only AI observability but also who or what is allowed to initiate agent-to-agent communication, what data can move between agents, and whether every exchange is auditable. Once agentic systems operate without a human in the loop, gateway policy becomes part of identity governance rather than a networking afterthought.

Key questions

Q: How should security teams govern Agent2Agent communication in production?

A: Treat every agent as a governed non-human identity, not just a service integration. Require ownership, scoped authentication, traceable task IDs, and lifecycle offboarding before the first production workflow goes live. If an agent can discover peers and request access at runtime, it belongs inside identity governance and audit processes.

Q: Why do agentic AI workloads increase governance risk compared with normal model calls?

A: Agentic workloads can chain decisions, retry automatically, and expand context across multiple calls. That means one session can do the work of many prompts while using the same credential path. If identity, budgets, and approvals are not bound to the session, the workload can drift beyond its intended scope very quickly.

Q: What are the signs that agentic AI governance is too focused on the agent and not the system?

A: Common signs include strong controls around individual identities but weak oversight of orchestration, action chaining, and inter-agent trust. If teams can describe each agent yet cannot explain how autonomous decisions are approved, audited, and contained across the system, governance is too narrow.

Q: What should teams do when agents can delegate work without human approval?

A: Teams should place controls at the delegation boundary and require explicit policy for which agents may call, hand off to, or consume output from other agents. Without that governance, approval-free delegation turns routine orchestration into uncontrolled downstream action.

How it works in practice

Why agent-to-agent traffic changes AI gateway design

Agent-to-agent communication, or A2A, is different from classic LLM traffic because the security boundary is no longer a single request and response. One agent can discover another, negotiate a task, and pass context onward without a human approval step. That creates a distributed trust model where policy must follow the conversation, not just the model call. In practice, this means gateways need to inspect both the participants and the message content, because the risk is not only unauthorized access but also uncontrolled delegation and policy drift across the chain.

Practical implication: treat A2A as a separate governance layer and not as an extension of model-only controls.

How identity and observability work across the full AI data path

Kong frames the full AI data path as the combination of APIs, events, LLM calls, MCP access, and A2A communication. The architectural point is that governance fails when these surfaces are managed as isolated silos, because agentic systems move across them in one workflow. Identity enforcement therefore has to attach to each interaction type, while observability has to correlate them into a single audit trail. Without that join, teams may see a model prompt here, a tool call there, and an event elsewhere, but still miss the actual decision path taken by the agent.

Practical implication: correlate identity, policy, and audit data across APIs, events, MCP, and A2A in one control plane.

Why real-time inspection matters for prompt injection and rogue behaviour

The article ties real-time traffic inspection to detection of prompt injection attempts, policy violations, and anomalous behaviour before they propagate. That matters because agent-to-agent exchanges can amplify bad instructions much faster than a single user prompt can. If an agent consumes malicious content and then delegates it onward, the problem becomes recursive rather than isolated. The technical challenge is not just filtering inputs but catching harmful intent embedded in machine-to-machine exchanges before it is re-executed across downstream agents.

Practical implication: inspect agent messages in flight when policy violations can cascade through delegated workflows.

NHI Mgmt Group analysis

Agent-to-agent governance is the missing control plane for multi-agent AI. The governance model that works for one LLM request and one response does not survive delegation chains, event-driven agents, and tool-calling loops. Once an agent can hand work to another agent, policy enforcement has to move from the edge of the model to the path between autonomous actors. Practitioners should read this as a governance shift, not a gateway feature.

The key assumption collapse is that access is reviewable after execution. Access review processes were designed for privilege that persists long enough to be observed, certified, or revoked. That assumption fails when agents negotiate and consume context dynamically across short-lived sessions and chained interactions. The implication is not just more monitoring, but a rethink of where authorisation decisions are made in agentic workflows.

Agent identity now becomes a governance primitive, not a metadata label. Kong's focus on authenticating every agent reflects a broader market move toward treating AI actors as first-class identities with scope, policy, and audit requirements. That aligns with OWASP-NHI thinking for machine identity, while also pushing into agent-specific controls where delegation and message content matter. Practitioners should expect governance programmes to converge on identity, observability, and policy as one control layer.

The market is moving from model governance to interaction governance. The most important shift in agentic AI is no longer which model is used, but how many systems it can reach, what it can hand off, and what gets logged along the way. That reweights procurement and architecture discussions toward control coverage across APIs, MCP, events, and A2A rather than isolated AI gatekeeping. Teams should evaluate platforms on path coverage, not just prompt protection.

Full-stack AI governance will increasingly determine production readiness. The article points to a category direction where AI gateways, agent management, and audit layers converge. That trend validates the idea that agentic AI cannot be governed with point controls around a single protocol. Practitioners should expect identity architecture, compliance evidence, and runtime inspection to be assessed together when agentic workloads move into production.

What this signals

Agent-to-agent governance is becoming a programme-level requirement, not a feature request. Once agents can discover, negotiate, and transact with other agents, the control problem moves beyond model access and into the orchestration layer. Programmes that still separate API governance, model governance, and audit logging will miss the actual decision path that matters.

Identity enforcement has to follow the workflow, not just the endpoint. The practical shift for teams is to govern agent identity, delegation, and message content as one chain of accountability. That is the boundary where agentic sprawl turns into an operational risk, especially when the same workflow spans tools, events, and other agents.

For practitioners

• Define policy for agent-to-agent communication Document which agents may initiate, receive, or delegate tasks to other agents, and tie that policy to business workflow boundaries rather than just protocol endpoints.
• Require authenticated agent identity Bind every agent interaction to a verifiable identity so delegated tasks, tool calls, and downstream actions can be attributed to a specific machine actor.
• Correlate logs across the full AI data path Join API, event, MCP, LLM, and A2A records into one audit trail so investigators can reconstruct the sequence that led to a policy decision or data movement.
• Inspect messages in flight for policy violations Use real-time inspection on inter-agent traffic to detect prompt injection, unauthorized data sharing, and anomalous delegation before the content propagates further.
• Treat cost allocation as an identity control Track token and resource consumption per agent identity so you can spot sprawl, misuse, and unowned workloads before spend becomes ungoverned.

Key takeaways

• Agent-to-agent traffic expands the AI governance problem from single interactions to multi-step delegation chains across multiple systems.
• The key failure mode is loss of visibility, because policy and audit controls built for linear model calls do not fully cover agentic workflows.
• Practitioners need identity-bound policy, full-path logging, and in-flight inspection before agentic systems move deeper into production.

Key terms

• A2A — Agent-to-Agent Protocol: An emerging communication standard enabling AI agents to authenticate and communicate securely with each other. A2A introduces new NHI challenges as each agent-to-agent interaction requires verified identities, scoped permissions, and auditable communication channels.
• AI Data Path: The AI data path is the route information takes as it moves into, through, and out of an AI system. It includes prompts, retrieved context, model inputs, outputs, logs, and downstream actions. Security teams use it to identify where sensitive data can be exposed, altered, or misused.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Delegation Boundary: A delegation boundary is the line that separates what a person, service account, or agent may do directly from what it may do on behalf of someone else. It matters because runtime access should follow the delegated relationship, not expand into broad inherited privilege.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.