MCP servers and AI token governance in the agentic era

At a glance

What this is: This is a developer guide to building MCP servers, with the key finding that standardized AI tool access only works safely when identity, authorization, and validation are engineered around it.

Why it matters: It matters because MCP creates a new integration layer between AI systems and enterprise resources, which forces IAM, NHI, and security teams to govern tool access, session boundaries, and exposed secrets together.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Kong's guide to building an MCP server for AI assistants

Context

MCP is an application-layer protocol for connecting AI clients to external tools and data. In identity terms, that means the AI client is no longer just consuming answers, it is initiating access paths into documentation, APIs, validation services, and internal systems that need explicit control.

The governance gap is that most enterprise controls were designed for human sessions or static machine integrations, not for AI clients that can discover tools, request resources, and call functions on demand. For IAM, this turns the protocol conversation into an authorization and lifecycle problem across NHI, agentic AI, and service boundaries.

Kong’s guide is framed as a developer walkthrough, but the broader security question is how to make MCP useful without turning every exposed tool into an uncontrolled enterprise extension point. The starting position is typical for teams experimenting with agentic workflows, which makes the governance lessons broadly relevant.

Key questions

Q: How should security teams govern AI clients that can call internal tools through MCP?

A: Start by treating each MCP tool as a delegated access path with its own owner, approval, and audit requirements. Limit the tool catalogue to the smallest useful set, require explicit authorization for state-changing actions, and log every invocation. The goal is to make AI tool use reviewable and revocable like any other enterprise entitlement.

Q: Why do MCP servers create new risks for NHI governance?

A: MCP turns AI-facing integrations into persistent, callable access paths, which means secrets, resources, and tools all become part of the non-human identity surface. If those interfaces are not bound to lifecycle controls, teams lose visibility into who or what is using enterprise capabilities and when.

Q: What should teams check before allowing AI-generated content to reach production?

A: Require deterministic validation for structure, syntax, and allowed components before any AI-generated output can be published or executed. If the output can change configuration, user experience, or downstream workflow state, the system needs a server-side rejection path for malformed or unauthorized content.

Q: How do organisations keep MCP session state from becoming an access-control blind spot?

A: Persist only the minimum state required, tie it to a known client identity, and make it fully auditable. If the session can carry context across multiple requests, then ownership, logging, and expiry must be designed as part of the transport rather than added later.

Technical breakdown

MCP servers as a standardized tool layer for AI clients

MCP defines a common way for AI clients to talk to remote servers that expose resources, tools, and prompts. Resources are readable objects such as documentation or API responses. Tools are callable actions that can fetch data, validate content, or trigger workflows. Prompts are reusable instructions that shape how the client works. The value of the protocol is interoperability, but the security consequence is that AI systems gain a normalised access path into enterprise capabilities that were previously scattered across bespoke integrations.

Practical implication: treat every exposed MCP capability as an identity-controlled interface, not as a harmless helper function.

Session state, durable objects, and persistent MCP transport

The guide shows two important implementation patterns. First, a stateless handler can serve simple requests. Second, a persistent transport backed by Durable Object storage can preserve session state across interactions, including sampling and elicitation features. That matters because session state changes the control surface: the server is no longer only authorizing isolated calls, it is maintaining context across requests. In security terms, persistence expands the window in which tool use, state, and permissions can be correlated or abused.

Practical implication: bind persistent session state to explicit identity and audit controls before enabling any long-lived MCP transport.

Syntax validation as a trust boundary for generated content

The MDC validator example is more than a content utility. It illustrates that AI-generated output needs deterministic verification before it is accepted by downstream systems. The tool checks nesting, tag balance, and line-level syntax errors, which is a classic pattern for reducing prompt-to-production drift. In practice, this is the difference between letting the model improvise and forcing the output through a control point that can reject malformed or unsafe structures before they become publishable artefacts or executable configuration.

Practical implication: require server-side validation for any AI-generated content that can affect production configuration or user-facing state.

NHI Mgmt Group analysis

MCP turns AI integration into an identity design problem, not just a developer convenience problem. The protocol standardises access to tools and resources, which means the control question shifts from integration feasibility to authorization scope. Once an AI client can call external functions, the enterprise must decide whether it is exposing read-only assistance, bounded execution, or something much closer to delegated operational authority. Practitioners should treat MCP as an identity boundary that needs explicit policy, audit, and lifecycle ownership.

Tool exposure without governance creates a widened identity blast radius. Every tool registered through an MCP server is a potential path from model output into enterprise state, and every resource is a possible data leakage point. That makes the named concept here an identity blast radius: the amount of enterprise capability reachable from one AI-facing integration point. The practical implication is that tool catalog design becomes a security control, not just an engineering choice.

Persistent transport state weakens the assumption that AI interactions are ephemeral and easily reviewed. Traditional access review logic assumes there is a stable, observable entitlement to examine. MCP sessions backed by durable state complicate that assumption because context can survive across interactions and create a longer-lived behavioural footprint. For governance teams, the issue is not only what the client can access, but how long the access context persists and how reliably it can be reconstructed.

MCP adoption will converge API security and NHI governance into the same operating model. The guide shows AI clients, tools, and resources being composed into one workflow, which means API gateways, secret handling, and non-human identity controls can no longer be managed as separate disciplines. That convergence is already visible in agentic workflows, where the practical question is whether the organisation can inventory, constrain, and retire AI-facing access paths with the same rigor it applies to other machine identities. Practitioners should align MCP governance with broader NHI lifecycle controls.

Content validation is the overlooked control that separates experimentation from trustworthy deployment. The syntax validator example demonstrates a broader pattern for AI systems: if the model can generate something that affects production, there must be a deterministic gate that rejects malformed output before it reaches the destination. That applies equally to documentation, configuration, and tool-driven automation. Practitioners should make validation mandatory wherever AI output changes state or expands access.

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 control baseline, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding should be extended to AI-facing identities.

What this signals

Identity blast radius: MCP adoption will be judged less by how easily it connects AI to tools and more by how tightly the organisation can confine that access. With 92% of organisations saying governing AI agents is critical but only 44% having implemented any policies, the gap is no longer conceptual, it is operational, according to AI Agents: The New Attack Surface report.

Enterprises that already struggle to inventory NHI credentials will find MCP governance easier only if they reuse existing lifecycle controls, not invent a parallel model. The practical next step is to align AI tool exposure, secret handling, and audit logging to a single entitlement record, then review whether any exposed capability lacks an owner or expiry.

Teams should also watch for tool sprawl inside agent workflows, where a harmless documentation endpoint today becomes a state-changing integration tomorrow. The issue is not MCP alone but the speed at which AI-facing access expands once users trust the client to discover and invoke tools on their behalf.

For practitioners

• Inventory every MCP-exposed capability List each resource, tool, and prompt the server exposes, then classify whether it is read-only, state-changing, or privilege-bearing. Assign an owner to each capability and require approval before any tool that can alter production state is published.
• Bind session state to a named identity If you use persistent transport, ensure the session is tied to a durable identity record, with logging that lets you reconstruct which client accessed which tool and when. Do not rely on anonymous or implicit state for anything that can reach internal systems.
• Place validation in front of execution Run generated content through deterministic validators before it can trigger deployment, publish content, or call downstream APIs. Reject malformed structures at the server boundary rather than trying to correct them after the model has already acted.
• Treat exposed secrets as a separate control plane Keep API keys, tokens, and certificates out of prompts, tool outputs, and static resources. Use secret storage and short-lived credentials that are isolated from the MCP server runtime so tool access does not become secret exposure.
• Map MCP access into your NHI lifecycle process Apply provisioning, recertification, and offboarding to every AI-facing integration that can act on behalf of the organisation. When a tool or server is retired, revoke its credentials and remove the capability from the discovery surface at the same time.

Key takeaways

• MCP standardises AI access to tools and resources, which makes identity and authorization design central to safe deployment.
• The main governance risk is not the protocol itself but the blast radius created by exposed tools, persistent session state, and unmanaged secrets.
• Teams should inventory every AI-facing capability, validate generated output before execution, and fold MCP into existing NHI lifecycle controls.

Key terms

• Model Context Protocol: Model Context Protocol is an open standard that lets AI clients connect to remote tools, resources, and prompts through a consistent interface. In practice, it turns AI integration into a governed access path that must be bounded, logged, and lifecycle-managed like any other enterprise entitlement.
• MCP Server: An MCP server is the system that exposes resources, tools, and prompts to AI clients through the Model Context Protocol. Security teams should treat it as an identity-bearing integration point because it can mediate access to internal data, operational functions, and state-changing actions.
• Session State: Session state is the persisted context an MCP transport keeps between client requests. For identity governance, that matters because state can extend the lifetime of an access path, make actions harder to reconstruct, and increase the chance that permissions outlive their intended review window.
• Identity Blast Radius: Identity blast radius is the amount of enterprise capability reachable from one authenticated path, tool, or token. In AI integration work, it describes how far a single client, server, or secret can reach once it is allowed to discover and invoke external functions.

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: A Developer's Guide to MCP Servers: Bridging AI's Knowledge Gaps. Read the original.