AI connectivity is becoming the control plane for agentic traffic

At a glance

What this is: This is Kong’s view that agentic AI is creating a new connectivity layer where APIs, tokens, and guardrails must be governed together.

Why it matters: It matters because IAM, NHI, and platform teams will need to govern machine-scale access paths that no longer behave like traditional human-driven application traffic.

👉 Read Kong's analysis of AI connectivity and the agentic traffic layer

Context

AI connectivity is the governance problem that appears when systems stop talking only through human-built applications and start moving through agents, tokens, and machine-to-machine interfaces. In that model, identity is no longer just about who logs in, but which non-human or autonomous actor can discover, call, route, and consume enterprise interfaces at runtime.

Kong’s article frames this shift as a traffic-layer problem rather than a single-product problem. For IAM, NHI, and platform teams, the question is whether current controls can still govern access, observability, and blast radius when the primary consumers of APIs are no longer people but software actors operating at machine speed.

The primary subject is the expanding control surface around AI traffic, not a new authentication scheme. That makes the article typical of an early market thesis piece: broad in framing, strong on architecture direction, and useful mainly as a signal of where governance pressure is moving.

Key questions

Q: How should security teams govern AI agent access to enterprise APIs?

A: Treat AI agent access as a machine identity problem, not a user-experience problem. Place policy, logging, and routing controls at the traffic layer, define narrow permissions for each tool path, and require auditability for every agent-to-service transaction. The goal is to constrain what an agent can do at runtime, not just authenticate it once at the start.

Q: Why do AI agents require different governance than human API consumers?

A: AI agents can discover, sequence, and repeat actions at machine speed, which makes their access patterns more dynamic than human-driven requests. Human-centric approvals and review cycles are too slow for that model. Governance has to shift toward scoped runtime access, telemetry, and containment so an agent cannot expand its reach faster than the control framework can observe it.

Q: What breaks when AI traffic is managed only through downstream services?

A: Controls fragment when each service tries to enforce its own policy, because the system loses a single view of identity, context, and blast radius. That increases inconsistency, latency, and audit gaps. A traffic-layer approach centralises decisioning so access, routing, and observability stay aligned across the whole path.

Q: How can teams tell whether their AI connectivity model is mature enough?

A: Look for three signals: you can trace every agent path, you can bound the tools each path can reach, and you can stop or isolate traffic without breaking the wider platform. If those three capabilities are missing, the organisation is still experimenting with AI access rather than governing it.

Technical breakdown

AI gateways and the traffic-layer control plane

Kong’s core architectural argument is that AI traffic needs a control layer similar to the API gateway era, but tuned for prompts, tokens, model calls, and agent sessions. In practical terms, the gateway sits between AI consumers and enterprise systems to enforce routing, authentication, rate limiting, auditability, and policy decisions in one place. The logic is not that AI is special in a philosophical sense, but that its traffic is more heterogeneous and more continuous than traditional application traffic. The control plane therefore becomes a governance boundary for machine-scale interactions.

Practical implication: treat the traffic layer as an identity enforcement point for AI workloads and map policy, logging, and access decisions there, not only in downstream services.

MCP, tokens, and machine-to-machine identity

The article highlights MCP as an emerging protocol for connecting models to tools and data sources. That matters because MCP sessions do not behave like conventional user sessions. A model or agent can chain requests across tools, carry context between calls, and generate token traffic that is partly instruction, partly data movement, and partly execution. For identity teams, the technical issue is not just authentication at the edge. It is understanding which actor is being represented, which permissions are inherited, and how much context can move before the request becomes a governance issue rather than a simple API call.

Practical implication: classify MCP-connected workloads as governed non-human access paths and require explicit policy for tool exposure, logging, and session boundaries.

Hypervolumes and blast-radius control

Kong argues that AI traffic will move at hypervolume scale, eventually reaching quadrillions of requests and token events. When throughput rises that quickly, classic point controls become less effective because latency, policy enforcement, and failure containment all have to coexist at line speed. The security lesson is that scale changes the risk model: one weak policy or misrouted agent session can create disproportionate impact because the system is designed for rapid, repeated execution. In that environment, guardrails are less about blocking every request and more about limiting what a bad flow can touch before it spreads.

Practical implication: design for containment by default, including scoped permissions, routing controls, and telemetry that can isolate agent-driven traffic before it amplifies.

NHI Mgmt Group analysis

AI connectivity is becoming an identity governance problem, not just an infrastructure problem. The article is strongest when it describes the traffic layer as the place where security, observability, and policy meet. That framing matters because the same access decision can now be exercised by APIs, models, and agents in different combinations. Practitioners should read this as a signal that governance boundaries are shifting upward into the control plane.

The most durable concept here is identity blast radius. As tokens and agent sessions become the primary unit of work, the governance challenge is no longer only who has access but how far an access path can spread before it is constrained. That is a better lens than treating AI traffic as just another application workload. Practitioners should use blast-radius thinking when deciding where to place policy enforcement and telemetry.

APIs for people and APIs for agents are not governed the same way. Human users tolerate slower, approval-heavy flows, while agents demand low-latency execution and can chain calls continuously. That changes the economics of control and makes stale entitlement models less useful. Practitioners should expect agent access design to converge on scoped, observable, and transaction-specific permissions.

The article supports a broader shift from static access models to runtime governance. Kong’s thesis is that connectivity itself becomes the security surface when agents consume services at machine speed. That aligns with how NHI programmes are already evolving around policy enforcement, telemetry, and lifecycle accountability. Practitioners should treat AI connectivity as a governance domain that must be owned, not an integration detail to be bolted on later.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 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.
• For the wider governance pattern, see OWASP Agentic Applications Top 10 for the control failures that emerge when agent traffic is not contained.

What this signals

Identity blast radius is now the right operating metric for AI connectivity. Once tokens, prompts, and MCP sessions become the primary movement layer, the practical question is not whether traffic is authenticated, but how far a single actor can spread before policy intervenes. Teams should evaluate whether their current routing and audit model can still contain a fast-moving agent path. For a useful governance baseline, anchor the programme in the NHI Lifecycle Management Guide.

The market is converging on a control-plane model for AI traffic because point solutions cannot keep up with multi-model, multi-protocol, machine-speed access. That means identity teams should expect more scrutiny on policy placement, session visibility, and tool exposure. The earlier organisations can unify those controls, the less likely they are to discover blind spots after agents are already in production.

If your programme still treats AI access as an application integration issue, the risk is that accountability will remain fragmented across platform, security, and data teams. The stronger posture is to treat agent access as governed machine identity with measurable scope. For standards alignment, use the NIST AI Risk Management Framework alongside your NHI control set.

For practitioners

• Map AI traffic to a governed control plane Identify where prompts, tokens, MCP sessions, and model calls enter or leave the environment, then place policy enforcement and audit logging at those choke points so access is governed before it reaches downstream systems.
• Define blast-radius limits for agent-driven access Set explicit routing and permission constraints for agent sessions so a compromised workflow cannot fan out across multiple systems without containment or review.
• Separate human and machine access patterns Do not reuse approval flows built for people when designing access for agents. Use shorter-lived, narrower, and more observable entitlements for machine-to-machine interactions.
• Inventory MCP-connected tool exposure Catalogue which tools, data sources, and services are reachable through MCP or similar connections, then determine whether each connection is necessary, logged, and bounded by policy.

Key takeaways

• AI connectivity turns the traffic layer into an identity governance boundary for agents, tokens, and APIs.
• Hypervolume traffic changes the security problem from isolated access checks to blast-radius containment and runtime observability.
• Enterprises should govern AI access where traffic moves, because downstream-only controls will not keep pace with agent-driven execution.

Key terms

• AI connectivity: AI connectivity is the layer that moves prompts, tokens, model calls, and agent actions between systems. It combines routing, access control, observability, and policy enforcement so machine-driven interactions can be governed consistently rather than handled as isolated integrations.
• Mcp session: An MCP session is a structured interaction between an AI application and external tools or resources through the Model Context Protocol. It can carry context across multiple calls, which makes access scope, logging, and tool exposure central governance concerns.
• Identity blast radius: Identity blast radius is the amount of damage one authenticated actor can cause before controls contain the activity. In AI and NHI environments, it is shaped by scope, routing, observability, and how quickly access can be limited when behaviour changes.
• Traffic-layer control plane: A traffic-layer control plane is the governance point where requests are routed, inspected, and constrained before they reach services. For AI systems, it is where identity, policy, and telemetry can be aligned across APIs, tokens, and agent workflows.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: The Age of AI Connectivity. Read the original.