Agentic internet infrastructure exposes new MCP governance gaps

At a glance

What this is: This is a Kong analysis of how the agentic internet depends on MCP-enabled infrastructure, and its key finding is that agent capability now rises or falls on how securely tools, data, and observability are wired together.

Why it matters: It matters because IAM, NHI, and AI governance teams now have to treat agent runtime access, tool exposure, and telemetry as one control surface rather than separate program tracks.

By the numbers:

• 90% say their companies are actively adopting AI agents.
• 95% of generative AI initiatives go nowhere, according to a report published by MIT.

👉 Read Kong's analysis of infrastructure for the agentic internet and MCP governance

Context

MCP has become a practical control point for agentic AI because it connects models to the third-party tools, services, and data that make agent behaviour useful. That shift matters for identity governance because the agent is no longer just consuming content. It is acting through governed access paths that need visibility, limits, and security boundaries.

The problem is not simply that more AI exists. The problem is that the operational surface now includes runtime tool discovery, access tiers, server exposure, and telemetry across both LLMs and connected systems. For IAM and NHI teams, this is a governance problem first and an integration problem second.

Kong frames this as infrastructure for the agentic internet, and that is a useful lens. The core question is no longer whether agents can connect to systems, but whether the identity and access model can keep those connections bounded, auditable, and recoverable.

Key questions

Q: How should teams govern AI agents that use MCP tools in production?

A: Teams should govern MCP-enabled agents as runtime identities, not as ordinary API clients. That means defining which tools each agent may reach, assigning clear ownership for every exposed server, and logging actual tool use alongside policy. If an organisation cannot explain the full agent-to-tool path, it does not yet have production-grade governance.

Q: Why do AI agents complicate existing IAM and API controls?

A: AI agents complicate IAM and API controls because they can choose tools dynamically and chain actions across a session. Static entitlements were built for more predictable request patterns. Once access becomes runtime-directed, teams need controls that can follow behaviour, not just approve endpoints or roles.

Q: What breaks when MCP servers are exposed without strong governance?

A: What breaks is the ability to bound and explain agent behaviour. Without governance, teams lose control over which agents can discover tools, which limits apply, and whether the resulting activity is auditable. That creates a gap between what the platform can do and what the security team can prove.

Q: How do security teams know if agent observability is actually working?

A: Observability is working only when teams can tie together token activity, tool calls, and latency for a specific agent session. If those signals are disconnected, the logs may show traffic but not governance. The test is whether investigators can reconstruct the path of a meaningful agent action from start to finish.

Technical breakdown

MCP tools as the runtime access layer for agents

Model Context Protocol, or MCP, gives agents a standard way to discover and consume tools, services, and data sources at runtime. In practice, that means an agent can move from language generation to tool use without a human stitching every integration together. The architectural shift is important: access is no longer only a backend permission problem, it is a live interaction between the model, the tool server, and the governance boundary around both. Once that happens, tool exposure becomes part of identity design, not just application plumbing.

Practical implication: treat every MCP server as an access-bearing surface and inventory it with the same discipline you use for privileged APIs.

MCP governance, security, and observability are one control plane

Kong’s article groups MCP governance, MCP security, and MCP observability together because these controls fail if they are managed in isolation. Governance sets tiers of access and consumption limits. Security standardises how consuming clients reach servers. Observability shows which agents, tools, and models are actually being used, plus latency and token activity. For identity teams, the important point is that authorisation without telemetry is incomplete, and telemetry without access control does not reduce risk. The useful unit is the governed runtime path.

Practical implication: align approval, policy, and logging around the same MCP path so you can answer who accessed what, through which agent, and why.

Why agent infrastructure behaves differently from traditional APIs

Traditional API governance assumes the client and the calling pattern are relatively stable. Agentic systems are different because the model may choose tools dynamically, chain actions, and alter the sequence of requests as it works through a task. That does not automatically make the system autonomous, but it does make the runtime less predictable than ordinary service-to-service traffic. The consequence is that static entitlement design and coarse API monitoring no longer give full assurance. Identity governance has to understand the agent’s operational path, not just the endpoint list.

Practical implication: review whether your current API controls can explain dynamic agent behaviour before you let agents reach internal or customer data.

NHI Mgmt Group analysis

Agentic AI turns tool access into an identity problem, not just an integration problem. The article is right to centre MCP because the moment an agent can discover and consume tools at runtime, identity governance moves inside the action path. That changes how practitioners think about scope, accountability, and recoverability. The practical conclusion is that agent access must be governed as a live identity relationship, not a static integration list.

MCP governance only works when access limits and telemetry are designed together. The article shows why separate views of policy and observability break down once agents start using tools dynamically. Access tiers without usage telemetry do not tell you whether an agent behaved within bounds. Telemetry without access limits only documents exposure after the fact. Practitioners should treat governed runtime paths as the unit of control.

Dynamic agent behaviour exposes the limits of API-era trust assumptions. Traditional API security assumes stable clients and fairly predictable call patterns, but agents can choose tools, sequence actions, and follow different paths to complete the same task. That means the old assumption of fixed request flow no longer holds cleanly. The implication is that identity programmes must re-evaluate whether their control model can interpret runtime decision-making.

Prompt-to-tool chains create a new identity blast radius around connected systems. Once LLMs and MCP tools operate together, a weak decision at the prompt layer can extend into real access across multiple services. That is especially important when businesses expose third-party data and internal systems through the same agent path. Practitioners need to recognise that the blast radius is now shaped by tool connectivity, not only by model quality.

Runtime tool discovery: the important governance question is no longer which tools exist, but which tools an agent can reach, under what limits, and with what audit trail. That is a governance posture shift that affects NHI, API, and AI teams at once. It is also where most organisations will discover they have incomplete ownership of the agent stack. The practical conclusion is to define ownership before agents reach production-scale data or actions.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 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.
• For a broader view of the risk surface, see OWASP NHI Top 10 and the governance implications of autonomous tool use.

What this signals

Runtime governance will become the differentiator between agent experimentation and agent operations. The article points toward a future where every meaningful agent deployment needs a traceable tool path, not just a model endpoint. That means IAM and platform teams should plan for ownership models that cover agents, tool servers, and telemetry together, especially where internal APIs are exposed through MCP.

With 80% of organisations already reporting AI agents acting beyond intended scope, the immediate question is not whether agent governance will be needed, but whether current access models can survive first contact with production behaviour. Teams that separate AI oversight from identity governance will keep finding gaps after the fact.

MCP will push more security scrutiny onto the connective tissue between systems. The practical challenge is no longer only model safety, but how the agent reaches data, how that access is limited, and how it is reconstructed later. For teams building an operating model, NHI Lifecycle Management Guide is a useful starting point for thinking about discovery, access, and offboarding as one lifecycle.

For practitioners

• Map every MCP server as an identity-bearing resource Document which agents can discover each server, what data or functions it exposes, and which team owns its policy and logging. Treat the server inventory as part of your access governance baseline, not as architecture collateral.
• Align policy, approval, and telemetry on the same runtime path Make sure access tiers, request logging, and usage analytics describe the same agent-to-tool interaction. If those three views do not reconcile, you do not have a trustworthy governance record for agent behaviour.
• Review whether dynamic tool selection breaks your current entitlement model Test whether an agent can change tool use mid-session without a corresponding governance event. If the answer is yes, your current access model is still assuming a static client, not an agentic runtime.
• Place observability requirements on both LLMs and connected tools Track token use, tool calls, and latency together so you can see when an agent is drifting, over-consuming, or using services unexpectedly. This is the minimum evidence set for investigating agent behaviour after deployment.

Key takeaways

• Agentic AI makes tool access part of the identity problem, because runtime choices now govern how models reach data and services.
• Kong’s article shows that governance, security, and observability must be treated as one control plane for MCP-enabled agents, not separate afterthoughts.
• If a team cannot explain the agent-to-tool path, it cannot reliably prove that agent access stayed within policy.

Key terms

• MCP Gateway: An MCP Gateway is the control point that governs how AI agents discover, reach, and consume tools exposed through Model Context Protocol. In practice, it is where access limits, security enforcement, and observability come together for runtime agent interactions.
• Agent-to-tool path: The agent-to-tool path is the full chain an AI agent follows from decision to tool invocation to resulting action. For governance teams, it is the unit that must be authorised, logged, and reviewed because the risk sits in the live path, not just the endpoint inventory.
• Runtime observability: Runtime observability is the ability to see what an agent is doing while it is doing it, including tool calls, token use, and timing. It is stronger than simple logging because it helps teams reconstruct behaviour and detect drift across a live AI workflow.

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 responsible for identity security strategy or governance maturity in your organisation, it is worth exploring.

This post draws on content published by Kong: From Browser to Prompt: Building Infra for the Agentic Internet. Read the original.