Agentic internet infrastructure exposes new MCP governance gaps

At a glance

What this is: Kong’s article argues that the agentic internet is creating MCP governance gaps because AI agents now rely on both models and tool ecosystems, pushing security, access, and observability into one runtime control problem.

Why it matters: This matters because IAM, API security, and AI governance teams need to decide how agents discover tools, how access is limited, and how MCP activity is observed before those patterns become embedded in production.

Context

Agentic AI is a model of software that can select tools and act across a session, which means identity governance now has to account for runtime decisions as well as static permissions. In Kong’s framing, the key gap is not model quality alone but the MCP tool layer that makes agents useful and governable in enterprise environments.

That shifts the security problem from isolated API protection to the governance of an agent runtime that spans prompts, model calls, third-party services, and data access. For IAM and platform teams, the question becomes how to govern discovery, scope, and visibility when the same agent can move between tools without a human in the loop.

Key questions

Q: What breaks when AI agents discover tools at runtime instead of using hardcoded lists?

A: Hardcoded lists assume the tool set is stable enough to be embedded in code. That breaks when services change frequently, environments differ, or new tools appear without redeploying the agent. Runtime discovery shifts the trust boundary to the registry, so misclassified or overexposed tools can be selected immediately.

Q: Why do MCP and agentic AI complicate IAM governance?

A: Because IAM controls are usually built around stable identities, known purposes, and review cycles that assume access remains legible long enough to inspect. MCP agents can operate continuously, chain actions, and change their effective scope faster than those cycles were designed to handle, so governance has to move from static approval to lifecycle validation.

Q: What are the signs that agent tool access is becoming overprivileged?

A: Warning signs include broad tool lists, direct connections to internal systems without a broker, and authorization checks that happen only at login or launch. If the agent can continue to accumulate effective privilege as it moves through tasks, the control boundary is too loose and the governance model is already behind the runtime behaviour.

Q: How should teams decide between API governance and MCP governance for agents?

A: Use API governance for the backend service boundary and MCP governance for the agent-facing tool boundary. The two overlap, but they solve different problems: one secures the service surface, the other constrains how agents discover and consume that surface.

Technical breakdown

How MCP changes the control plane for AI agents

Model Context Protocol, or MCP, standardises how AI agents connect to tools, services, and data sources. In practice, that means the access problem moves from a single API call to a governed tool ecosystem where agents can discover capabilities and invoke them in real time. The architecture matters because each MCP server becomes part of the trust boundary, not just a backend integration. Once agents can combine tools dynamically, security has to govern the connection between identity, context, and execution rather than treating each call as an isolated transaction.

Practical implication: inventory MCP servers as governed access surfaces, not ordinary integrations.

Why observability has to cover models and tools together

The article’s core operational point is that AI telemetry is no longer useful if it stops at the model layer. Agentic systems generate signals across prompts, model calls, token usage, tool selection, latency, and downstream service consumption, so isolated logging misses the actual decision path. Observability therefore becomes a governance control, not just an operations feature. Without correlated traces across LLMs and MCP tools, teams cannot tell which agent used what, when it happened, or whether the access path matched policy.

Practical implication: correlate AI gateway telemetry with MCP activity before relying on any agent audit trail.

What governance means when agents can autonomously assemble workflows

The article describes agents that can chain LLM reasoning with MCP tools to complete tasks, which raises the governance burden on authorization boundaries. Even when the tooling is standardised, the risk is that the agent can assemble a workflow at runtime that no one explicitly reviewed beforehand. That makes access tiers, limits, and discovery rules central controls. The more an organisation lets agents choose tools in the moment, the more governance shifts from approving a single action to constraining a sequence of actions that emerges during execution.

Practical implication: define discovery and usage limits before agents are allowed to assemble multi-step workflows.

NHI Mgmt Group analysis

MCP governance is becoming the missing layer between identity and AI execution: the article shows that model access alone does not govern agent behaviour if the tool layer is unconstrained. LLMs provide reasoning, but MCP determines what the agent can actually reach and combine at runtime. That makes the governance question about discoverability, scope, and traceability across a tool ecosystem, not about model choice alone. Practitioners should treat MCP as part of the identity plane for agentic systems.

Observability without tool-level correlation will understate agent risk: logs that only show prompts or token usage miss the real control decision, which is which tools were invoked and in what sequence. Kong’s framing reinforces a broader identity lesson: the control surface now includes usage patterns across models, agents, and connected services. That is where policy enforcement and forensic reconstruction will succeed or fail.

Runtime tool assembly creates a governance gap that static IAM never modeled: the article’s central implication is that agents can assemble capabilities on demand from a tool ecosystem that did not exist at provisioning time. Access tiers and limits therefore have to be applied to agent behaviour, not just to named endpoints. The practitioner takeaway is to govern the sequence, not merely the credential.

Agentic internet infrastructure is converging API management, AI governance, and identity control into one operating problem: the old boundary between API security and AI security is fading because MCP sits in the middle of both. That does not mean the controls are the same, but it does mean separate teams will miss the full risk picture if they do not coordinate around the same runtime surfaces. Security architecture now has to be designed for cross-layer accountability.

The named concept here is MCP governance gap: the gap between exposing tools to agents and being able to govern how those tools are discovered, limited, observed, and consumed. This is not a model-quality issue and not a traditional API issue on its own. It is the control gap that appears when AI agents become the orchestrators of enterprise access paths. Practitioners should recognise it as a new governance boundary.

What this signals

MCP governance has to be treated as runtime identity governance for agents: the article’s main lesson is that tool exposure, access limits, and observability now belong in the same control conversation. When an agent can combine tools dynamically, the question is no longer whether a service is reachable, but whether its use can be bounded and explained.

The control gap is not just visibility, it is sequencing: agents can assemble multi-step actions across prompts, models, and MCP tools faster than static reviews can keep up. That shifts the programme focus toward governed discovery, constrained execution paths, and telemetry that ties access back to actual agent behaviour.

For practitioners

• Define MCP server tiers and limits Classify each MCP server by sensitivity, allowed agent population, and permitted operations. Tie those tiers to explicit access ceilings so discovery does not become uncontrolled tool sprawl.
• Correlate model and tool telemetry Join LLM traces, token metrics, and MCP invocation logs in a single review path. Separate logs for models and tools will not show the full agent decision chain.
• Govern agent discovery rules Restrict which tools agents can discover and consume at runtime, especially where those tools expose customer data or high-impact operations. Discovery should be policy-driven, not implicit.
• Standardise security controls across MCP servers Apply the same authentication, validation, and policy checks to every MCP server rather than leaving protection to individual developers. That reduces uneven enforcement across the tool ecosystem.

Key takeaways

• Agentic AI infrastructure now couples models and MCP tools, so governance has to span access, limits, and observability across the full runtime path.
• The article shows that separate logging for prompts or tokens is not enough when agent decisions are made through tool discovery and invocation.
• Practitioners should govern what agents can discover, what they can consume, and how those actions are traced before the tool ecosystem grows further.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Agentic Internet: The agentic internet is a shift from human-driven browsing to prompt-driven execution, where AI agents complete tasks across websites and tools on behalf of users. It depends on autonomous decision-making, tool access, and stateful workflows, which means security, identity, and governance controls must evolve beyond traditional browser automation.
• MCP governance: MCP governance is the set of policies, controls, and oversight used to manage how AI agents use the Model Context Protocol to reach tools and data. It defines approved connections, authentication, authorization, logging, data handling, and change control so agent actions remain traceable, bounded, and aligned with security and compliance requirements.
• Agent observability: Agent observability is the collection and correlation of traces, logs, metrics, and evaluations across an AI agent’s execution path. It explains what happened during model calls, tool use, handoffs, and downstream effects, but it does not itself authorize, deny, or revoke access.

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.