LB1726 MCP Demo and MCP Server Management

MCP enables fine-grained tool access control with full audit trails. The just recently released MCP Security Specification mandates a "progressive, least-privilege scope model" where servers start with "minimal initial scope set…​ containing only low-risk discovery/read operations" and use "incremental elevation via targeted…​ challenges when privileged operations are first attempted." However not many MCP Servers implement these features today.

The MCP core protocol does not define how to authenticate users or services. When an AI application connects to an MCP server, there’s no standard mechanism to verify identity or establish trust.

When an AI agent calls a tool on behalf of a user, how does the backend system know who the original user is? This is critical for audit trails and for enforcing per-user permissions. Currently, each deployment must solve this problem independently.

In shared environments where multiple users interact with the same MCP servers, how do you ensure one user’s AI cannot access another user’s resources? Without careful configuration, an AI agent could potentially read data or perform actions it shouldn’t have access to.

By default, most MCP servers expose all their tools — including potentially destructive operations like pods_delete, resources_delete, or delete_file. An AI agent (or a malicious prompt) could invoke these tools without any guardrails.

Many MCP servers were originally designed for desktop use cases where the user has full control over their local environment. Enterprise deployments require more restrictive defaults, but this isn’t the norm.

MCP itself doesn’t define role-based access control. There’s no standard way to say "this agent can read pods but not delete them" at the protocol level. Organizations must implement access control through external mechanisms.

Without additional tooling, it’s difficult to monitor what tools are being called, by whom, how often, and with what parameters. This makes troubleshooting and capacity planning challenging.

Compliance frameworks often require detailed logs of all actions taken by automated systems. MCP doesn’t mandate any particular logging format or mechanism, leaving organizations to build their own audit infrastructure.

There’s no standard mechanism to prevent runaway AI agents from overwhelming backend systems with tool calls. An agent stuck in a loop could generate thousands of API calls in seconds.

MCP servers vary widely in implementation quality, error handling, and security posture. Some are production-ready; others are experimental prototypes. There’s no certification or quality standard.

How do you know an MCP server container image hasn’t been tampered with? Supply chain security for MCP servers is not yet well-defined.

Organizations may have dozens of MCP servers deployed across different teams. There’s no standard way to discover, catalog, or manage these servers centrally.

Pass API tokens to MCP servers so they can authenticate with backend services. For example, the Gitea MCP Server in this lab has been configured with a personal access token for each lab user that determines what repositories and actions are available - although this token is global for the Gitea MCP Server. In the lab environment each student has their own MCP Server configured with a token for just their Gitea user.

MCP servers running in Kubernetes can use service accounts with specific role bindings. The OpenShift MCP Server, for instance, respects Kubernetes RBAC — it can only perform actions that its service account is authorized for. In this lab the OpenShift MCP server for each user only has access to the user’s namespace(s).

Emerging work on OAuth 2.0 and OpenID Connect integration will enable federated identity and token exchange, allowing user identity to flow through the entire MCP call chain.

ToolHive can expose Prometheus metrics on MCP server activity, including connection counts, request rates, tool invocation counts, and error rates. These metrics integrate with existing Kubernetes monitoring infrastructure.

Using Kubernetes ServiceMonitor resources, organizations can automatically collect MCP telemetry into their observability platform and create dashboards, alerts, and SLOs.

MCP servers and proxies can emit structured logs capturing every tool invocation with full parameter details, enabling comprehensive audit trails.

A catalog of approved MCP servers within an organization. Developers can discover available servers, and administrators can control which servers are sanctioned for use. Module 4 of this lab provides hands-on experience deploying and using an MCP Registry.

An MCP gateway layer can enforce organizational policies before requests reach individual servers. This provides a single point for access control, rate limiting, and logging.

The registry can track container image signatures and verification status, ensuring only approved and verified MCP server images are deployed.

MCP supports multiple transport mechanisms. The three most common are:

When a host connects to an MCP server, it calls tools/list to discover available capabilities. The server returns a list of tools with their names, descriptions, and parameter schemas. This enables AI applications to understand what each tool does without hardcoded knowledge.

MCP uses JSON-RPC 2.0 for message encoding. Each tool call is a JSON-RPC request; the response contains the tool’s output or an error.

In Kubernetes environments, ToolHive provides a proxy layer that converts between transport protocols. Many MCP servers are written to use stdio (standard input/output), which doesn’t work directly in container environments. ToolHive automatically wraps these servers with an HTTP interface, making them accessible to network-based clients.