Hi!

I've been building a 'production-ready' gateway for AI-assisted Kubernetes operations (Kubernetes-MCP-Guard) and I'd like to raise a security concern and propose a pattern that I think deserves standardization across MCP infrastructure servers.

The Problem: Consent Fatigue and TOCTOU-Style Gaps in Simple Approval Flows

Current approaches to human approval for AI-assisted mutations often fall into one of three patterns, each with its own gap:

1. Boolean prompts ("Do you want me to restart nginx-prod? yes/no") — the human approves based on a description the AI wrote, not the actual payload. A compromised or prompt-injected AI can describe one thing and send another. This creates a Time-of-Check to Time-of-Use (TOCTOU)-style gap.

2. UI takeover (for example, AWS Nova Act) — designed for browser UI automation. When applied to structured API mutations, the approved payload may not be cryptographically bound between the human's approval click and the actual API call. This is a useful contrast, but not a mutation approval protocol.

3. Stateful workflow engines (for example, Oracle Integration Cloud HITL, BPEL) — can address TOCTOU-style issues when designed with immutable plan storage and hash binding, but require adopting a heavyweight workflow platform. That is not always a good fit for teams running open-source Kubernetes tooling.

The existing --read-only flags and RBAC in kubernetes-mcp-server are excellent safeguards, but they do not solve the case where an AI-assisted workflow legitimately has write access, a human has approved a specific operation, and then the payload drifts before execution.

The Proposed Solution: Plans, Challenges, and Hashes

In Kubernetes-MCP-Guard I've implemented a pattern I'm calling Plan-Challenge-Execute. Here's how it works:

1. Plan Generation, Not Execution

The AI calls a planning/request tool such as request_apply_manifest or request_restart_deployment.

Instead of mutating the cluster, the server:

• Runs a server-side dry-run against the real Kubernetes API
• Runs the manifest through a policy validator that rejects privileged containers, hostPath, hostNetwork, dangerous capabilities, and similar risky patterns
• Computes a diff against the live cluster state
• Writes a pending plan JSON document with the dry-run result, policy findings, diff, requester identity, and proposed payload
• Returns a plan ID and a summary

No cluster mutation happens during this phase.

2. Out-of-Band Approval

The AI/client then requests approval for the plan.

In my implementation, the same apply_approved_plan(planId) tool is stateful: before approval it returns an approval URL; after approval it executes the approved plan. For a portable contract, this could also be modeled as a separate create_approval_challenge(planId) phase.

The gateway:

• Creates an ApprovalChallenge record with a SHA-256 digest of the pending plan file
• Sets a 15-minute TTL by default
• Binds the challenge to the requesting subject
• Returns an approval URL to the AI client

The human must open the URL in a browser session authenticated through the gateway's own out-of-band OAuth flow, independent of the AI client's session.

The browser renders the exact plan being approved:

• The proposed Kubernetes operation
• The diff against live cluster state
• The server-side dry-run result
• Policy validation findings
• Requester and target resource information

The human then clicks Approve or Reject.

3. Hash-Bound Execution Gate

The AI/client calls the execution tool again after approval.

Before mutating Kubernetes, the server:

1. Recomputes the SHA-256 digest of the pending plan file
2. Verifies that the digest matches the digest captured in the approval challenge
3. Verifies that the approval challenge is still valid, unexpired, and single-use
4. Verifies that the approving OAuth sub matches the requesting sub in same-subject mode
5. Re-runs the server-side dry-run so stale approvals are refused if cluster state has changed
6. Only then mutates Kubernetes

If the pending plan was tampered with between challenge creation and execution, the digest comparison fails and the operation is refused with an error such as approval_hash_mismatch.

The AI/client cannot cause a different stored payload to be executed without invalidating the approval.

Key Security Properties

Proof: SafetyE2E Coverage Against Real Keycloak + Kubernetes Paths

These properties are not just documented — they are covered by targeted SafetyE2E regression tests that run against a real Keycloak instance via Testcontainers and a real Kubernetes cluster:

The main branch includes SafetyE2E coverage for digest mismatch, modified pending plans, expired approvals, wrong-user approvals, already-applied plans, dangerous manifests, dry-run failure, and RBAC boundaries.

The suite exercises real gateway, MCP, and Kubernetes paths and uses real Keycloak JWTs for MCP bearer authentication. Browser approval OAuth is simulated at the callback/backchannel boundary in tests, with separate service-level coverage for real-JWT wrong-user rejection.

A GitHub Actions workflow (safety-e2e.yml) runs the suite against an ephemeral KinD cluster on demand.

Reference implementation and tests:

• Repository: https://github.com/mirusser/Kubernetes-MCP-Guard
• SafetyE2E tests: https://github.com/mirusser/Kubernetes-MCP-Guard/tree/main/tests/InfraGate.Safety.E2E.Tests
• On-demand SafetyE2E workflow: https://github.com/mirusser/Kubernetes-MCP-Guard/blob/main/.github/workflows/safety-e2e.yml

Why This Needs a Portable Standard

MCP already has useful primitives:

• Tool annotations such as readOnlyHint and destructiveHint
• Human-in-the-loop guidance
• Elicitation / URL mode for out-of-band sensitive interactions

Those are good foundations.

What MCP does not currently standardize is a portable mutation-approval profile:

• A planId
• An immutable digest of the proposed mutation
• An approval challenge
• Same-user or policy-defined identity binding
• TTL
• Single-use semantics
• Drift checking
• Execute-after-approval behavior

Servers must implement these details themselves today.

Your repository is one of the most visible Kubernetes/OpenShift MCP implementations, so it seems like a good place to incubate this pattern. Without a shared profile, infrastructure MCP servers may diverge:

• MCP clients will not know whether to expect a boolean needs_approval flag, a URL, a digest, or nothing
• Security auditors will have no shared language for verifying human-in-the-loop mutation safety
• Teams may rely on ad-hoc prompts or untrusted destructiveHint annotations for real cluster mutations

I'm proposing an optional MCP mutation-approval profile that defines a minimal contract for structured mutation approval:

1. A plan phase that returns a plan ID and digest, not a mutation
2. A challenge phase that creates a time-bounded, identity-bound approval ticket
3. An execute phase that verifies both the digest and the challenge before mutating

This does not require adoption of my implementation. It requires agreement on the interface contract so that MCP clients and security reviewers can reason about approval state portably.

Threat Model

This profile treats the mutation server or gateway as the trusted policy enforcement point.

The goal is to prevent the model, MCP client, or intermediate workflow from substituting, replaying, or executing a different payload after human review.

This profile is intended to protect against:

• Prompt-injected or compromised AI/client behavior
• Misleading natural-language summaries
• Payload substitution between planning, approval, and execution
• Replay of already-approved plans
• Wrong-user approval
• Stale approvals after cluster state changes
• Accidental double execution

This profile is not intended to prove correctness of a malicious server implementation. A malicious server could still render one plan and execute another. That is outside the trust boundary of this pattern.

The Ask

1. Is this TOCTOU-style concern recognized by the team? Have you considered it in your roadmap?
2. Would you be open to collaborating on this thread to formalize a propose → challenge → execute tool contract for this repository or as an MCP mutation-approval profile?
3. If yes, I'm happy to draft a more formal spec document for review.

For reference, the architecture rationale is documented here:

• https://github.com/mirusser/Kubernetes-MCP-Guard/blob/main/docs/why-separated-plan-from-challenge.md

Short version:

• https://github.com/mirusser/Kubernetes-MCP-Guard#the-three-security-gates

Thanks for the great work on this project.

— @mirusser