Securing Model Context Protocol (MCP) on OpenShift: Enterprise Architecture for AI Agents

The rise of autonomous agentic systems across enterprise IT represents a paradigm shift: foundation models (LLMs) no longer just generate textual summaries; they directly interact with production environments by executing functions (tool calling), querying enterprise databases, triggering GitOps deployments, or reconfiguring infrastructure resources.

Historically, connecting LLMs to external systems relied on custom REST wrappers, ad-hoc Python glue code, and proprietary SDKs—creating massive security blind spots, maintenance overhead, and vendor lock-in.

The Model Context Protocol (MCP), an open standard spearheaded by the industry, standardizes how AI agents communicate with context sources and execution tools. However, in regulated enterprise environments (banking, healthcare, defense, critical manufacturing), connecting autonomous agents to internal APIs requires a bulletproof infrastructure governance model.

This guide explores how to design, containerize, and enforce a Zero-Trust Model Context Protocol (MCP) architecture on Red Hat OpenShift and OpenShift AI (RHOAI).

---

1. Why Model Context Protocol (MCP) is the Industry Standard for Agentic Systems

MCP establishes a clear client-server abstraction between the host application (LLM Agent / Llama Stack runtime), the MCP client, and the specialized MCP servers:

• Resources: Passive, read-only data streams (e.g., application logs, database schemas, Prometheus metrics).
• Tools: Executable functions with controlled side effects (e.g., SQL queries, ArgoCD application rollbacks, Jira ticket updates).
• Prompts: Parameterized, server-managed prompt templates enriched with backend context.

┌─────────────────────────────────────────────────────────────────────────────┐
│                   AI Agent / Llama Stack / MCP Client                       │
│                     (Pod on OpenShift AI / RHOAI)                           │
└──────────────────────────────────────┬──────────────────────────────────────┘
                                       │
            Secure Transport (mTLS / HTTP SSE / JSON-RPC 2.0)
                                       │
┌──────────────────────────────────────▼──────────────────────────────────────┐
│                     MCP Gateway & Ingress Controller                        │
│              (OpenShift Service Mesh / Istio + Envoy Filter)                │
└──────────────┬───────────────────────┬───────────────────────┬──────────────┘
               │                       │                       │
               ▼                       ▼                       ▼
    ┌──────────────────────┐┌──────────────────────┐┌──────────────────────┐
    │ MCP Server: OpenShift││ MCP Server: Database ││  MCP Server: GitOps  │
    │  API & Cluster Ops   ││    (PostgreSQL)      ││   (ArgoCD / Tekton)  │
    └──────────────────────┘└──────────────────────┘└──────────────────────┘

While local desktop environments often utilize stdio process communication, enterprise cloud-native deployments require HTTP with Server-Sent Events (SSE) or gRPC/WebSocket transports secured within a Kubernetes Service Mesh.

---

2. Critical Security Vectors in Enterprise MCP Deployments

Integrating autonomous agents with backend tools exposes systems to vulnerabilities outlined in the OWASP Top 10 for LLM Applications:

1. Indirect Prompt Injection: Unsanitized data fetched via an MCP Resource injects malicious instructions into the LLM context, coercing the agent to invoke destructive Tools.
2. Privilege Escalation & Confused Deputy: An agent equipped with an overly permissive cluster ServiceAccount executes administrative tasks that the initiating user lacks permission to perform.
3. Sensitive Data Exfiltration: Infrastructure secrets or PII are inadvertently leaked through tool parameter payloads or unmonitored external network connections.
4. Denial of Service & Unbounded Tool Loops: Recursive execution loops overload downstream databases and microservices.

---

3. Production Zero-Trust Architecture on Red Hat OpenShift

To mitigate these threats, an enterprise MCP deployment must be anchored across four infrastructure pillars:

A. Network Isolation & mTLS (OpenShift Service Mesh)

Each MCP server runs in an isolated namespace, strictly constrained by Kubernetes NetworkPolicies and enrolled into OpenShift Service Mesh (Istio) with mandatory mutual TLS (mTLS) and Envoy sidecar proxies.

B. Identity Propagation & Token Exchange (OAuth2 / OIDC)

The agent never uses static root credentials. An identity gateway (Keycloak / Red Hat Single Sign-On) performs RFC 8693 Token Exchange, downscoping the authorization token passed to the MCP server to reflect only the permissions of the authenticated end-user.

C. eBPF Runtime Security (Red Hat Advanced Cluster Security - RHACS)

RHACS monitors kernel system calls (syscalls) generated by MCP container runtimes in real time using eBPF probes. Any anomalous process fork, unexpected binary execution, or unauthorized outbound socket connection immediately triggers pod isolation (Process Baseline Enforcement).

D. Input/Output Guardrails (TrustyAI & Granite Guardian)

Before a tool argument is dispatched to an MCP server—and before the response is returned to the LLM context—a guardrail filter validates payload safety, masks PII, and detects prompt injection attempts.

---

4. Production Kubernetes Manifests: Deploying a Hardened MCP Server

Below is the declarative Kubernetes deployment for an isolated PostgreSQL MCP server running on OpenShift:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mcp-server-postgres
  namespace: ai-agents-prod
  labels:
    app.kubernetes.io/name: mcp-server-postgres
    app.kubernetes.io/part-of: agentic-platform
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mcp-server-postgres
  template:
    metadata:
      labels:
        app: mcp-server-postgres
        sidecar.istio.io/inject: "true"
    spec:
      serviceAccountName: mcp-postgres-sa
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: mcp-server
        image: registry.internal.aperta.ch/ai/mcp-postgres-sse:1.2.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
          name: http-sse
        env:
        - name: MCP_TRANSPORT
          value: "sse"
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: pg-readonly-credentials
              key: connection_string
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop:
            - ALL
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "100m"
            memory: "128Mi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

Associated strict NetworkPolicy restricting all unauthorized outbound traffic:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: mcp-server-postgres-isolation
  namespace: ai-agents-prod
spec:
  podSelector:
    matchLabels:
      app: mcp-server-postgres
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/name: rhoai-llama-stack-agent
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: database-prod
    ports:
    - protocol: TCP
      port: 5432
  - to: # Restrict DNS lookups to internal cluster CoreDNS only
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

---

5. Architectural Comparison: Tool Calling Paradigms

Dimension	Custom REST APIs / Ad-hoc Plugins	Local Desktop MCP (stdio)	Cloud-Native MCP on OpenShift & RHOAI
Protocol Standardization	Low (custom JSON schemas per framework)	High (JSON-RPC 2.0 MCP standard)	Maximum (Standard MCP + Llama Stack enterprise distribution)
Network & Transport Security	Fragmented (often unencrypted HTTP internal endpoints)	None (runs as local workstation process)	Mandatory mTLS, Istio Service Mesh, Zero-Trust NetworkPolicies
Identity & Access Control	Static API tokens / Shared secrets	Local user environment variables	RFC 8693 Token Exchange, Kubernetes RBAC, RHACS Process Baselines
Scalability & Resiliency	Custom load balancing	Single-process only	Native Kubernetes scaling, horizontal pod autoscaling (HPA), automated health probes
Guardrails & Observability	Hand-coded sanitizers	Absent	TrustyAI guardrails, Granite Guardian evaluation, OpenTelemetry distributed tracing

---

6. Operational Best Practices for Platform & Security Engineers

1. Enforce SSE Transport over HTTPS: Disallow unencrypted stdio processes in server environments; use Server-Sent Events with TLS termination at the ingress controller.
2. Apply Read-Only DB Roles: Analytical MCP servers must connect using strictly scoped PostgreSQL roles (SELECT privileges only on dedicated reporting views).
3. Correlate Traces via OpenTelemetry: Propagate the traceparent header across LLM prompt evaluations, MCP client requests, and backend tool invocations.
4. Isolate Code Execution Engines: For MCP servers running dynamic code evaluation (e.g., Python code interpreters), isolate execution pods using Kata Containers or OpenShift Virtualization microVMs to prevent container breakout vulnerabilities.

---

Master Enterprise AI Agent Architectures with Aperta Scientia

Securing and operationalizing enterprise AI agents demands deep mastery of cloud-native Kubernetes infrastructure and modern LLMOps pipelines.

Aperta Scientia prepares engineering teams through comprehensive, industry-leading training programs:

• AS300 — AI Platform Engineer: The flagship 3-month curriculum covering Red Hat OpenShift AI (RHOAI), Model Context Protocol (MCP) integration, Llama Stack, high-throughput serving with vLLM, vector search with Milvus, and model governance with TrustyAI.
• AS200 — New DevOps Platform Engineer : The foundational program to design, secure, and automate resilient Red Hat OpenShift clusters, mastering GitOps (ArgoCD), Tekton CI/CD, runtime security with RHACS, and multi-cluster networking with RHACM.