Notifications
Clear all
Topic starter
24/06/2026 8:31 pm
TL;DR: MCP gives AI assistants a standard way to reach tools, resources, and prompts, but the real governance question is how to expose internal capabilities without creating new token, tool, and data access paths, according to Kong. The control challenge is not the protocol itself, but the identity and authorization model wrapped around every server and client interaction.
NHIMG editorial — based on content published by Kong: A Developer's Guide to MCP Servers: Bridging AI's Knowledge Gaps
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Place validation in front of execution Run generated content through deterministic validators before it can trigger deployment, publish content, or call downstream APIs.
What's in the full article
Kong's full blog post covers the implementation detail this post intentionally leaves for the source:
- Step-by-step TypeScript project setup for a Cloudflare Workers MCP server
- Full code examples for registering tools, resources, and validation handlers
- Durable Object transport configuration for persistent MCP session state
- MDC syntax validation logic with stack-based parsing and line-level error reporting
👉 Read Kong's guide to building an MCP server for AI assistants →
MCP servers for AI assistants: what IAM teams need to govern?
Explore further
25/06/2026 5:19 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP servers and AI token governance in the agentic era
