Do you need approval workflows that require approvals before an MCP server can execute commands on a Kubernetes cluster?
Most teams grant engineers and automation agents direct kubectl exec or port‑forward privileges to the cluster. The usual pattern is a static service‑account token stored in CI pipelines, or a long‑lived kubeconfig checked into a repository. Anyone who possesses that token can connect to any pod that the service account can reach, run arbitrary commands, and read or modify data without a second set of checks. The convenience is real, but the risk is hidden: a compromised CI secret instantly becomes a foothold inside the cluster, and there is no record of who ran what, nor any chance to stop a dangerous command before it hits the pod.
Adding an approval step sounds simple: require a manager to click “allow” before the connection is opened. In practice, most environments stop at the request stage. The request still travels straight to the Kubernetes API server, the pod receives the command, and the system logs only the raw API call. No gate intercepts the traffic, no inline masking of sensitive responses, and no replay‑able session record. The approval becomes a paperwork exercise rather than an enforceable control.
The missing piece is a data‑path component that can see every request, enforce a policy, and produce immutable evidence. The component must sit between the identity that initiates the request and the Kubernetes control plane, so it can block, approve, or record the interaction before the target pod ever sees the command.
Why approval workflows matter for MCP servers
MCP (Model‑Control‑Program) servers often host code generation or data‑processing logic that can affect downstream services. A single mis‑executed command can corrupt a database, leak secrets, or trigger a cascade of failures. Requiring an explicit, auditable approval adds a human decision point that forces the requester to justify intent, and it gives the organization a clear trail for post‑incident analysis.
How hoop.dev enforces approval workflows on Kubernetes
hoop.dev inserts a Layer 7 gateway between the user (or automated agent) and the Kubernetes API. The gateway runs a network‑resident agent that speaks the native Kubernetes protocol, while the central service validates each request against policy.
- Just‑in‑time identity check: The request is authenticated via OIDC or SAML. hoop.dev reads the token, extracts group membership, and determines whether the caller is eligible for an approval flow.
- Policy‑driven approval: If the policy requires approval for the requested operation, such as exec into a pod running an MCP server, hoop.dev pauses the request and routes it to an approver. The approver’s decision is recorded before the command is allowed to proceed.
- Inline command guardrails: Once approved, hoop.dev can still block specific sub‑commands that match a deny list, preventing accidental destructive actions.
- Session recording: Every byte of the interactive session is captured by the gateway, stored outside the target pod, and made replayable for audit or forensic review.
- Real‑time response masking: Sensitive fields returned by the MCP server, such as API keys or personal data, can be redacted on the fly, ensuring that only authorized eyes see the raw values.
Because hoop.dev is the only point where traffic passes, all enforcement outcomes exist solely because the gateway sits in the data path. If the gateway were removed, the request would flow directly to the Kubernetes API with no approval, no masking, and no recording.
Setting up approval workflows for MCP servers
The practical steps are documented in the official getting‑started guide. In short, you deploy the hoop.dev gateway (Docker Compose or Kubernetes), register the Kubernetes cluster as a connection, and define a policy that marks exec into MCP pods as “approval required.” The policy language lives in the hoop.dev console; the gateway automatically enforces it for every request that matches the criteria.
All of the heavy lifting, credential storage, token verification, and policy evaluation, happens inside the gateway. Your engineers continue to use familiar tools like kubectl or the MCP client; they simply point them at the hoop.dev endpoint instead of the raw cluster address.
Key enforcement outcomes you gain
- Requests that lack approved consent are blocked before reaching the pod.
- Every approved session is recorded and can be replayed on demand.
- Sensitive response data is masked in real time, protecting downstream compliance scopes.
- Approvers have a clear audit trail that shows who approved what, when, and why.
Getting started
Begin with the getting‑started guide to spin up the gateway and connect your Kubernetes cluster. The guide walks you through registering the cluster, creating an approval policy for MCP exec calls, and testing the flow with a sample request. For deeper details on policy syntax, masking options, and session replay, explore the learn section of the documentation.
When you are ready to inspect the source code, contribute, or fork the project, visit the open‑source repository on GitHub: hoop.dev on GitHub.
FAQ
Can I require approval for only specific MCP services?
Yes. Policies can target a namespace, a label, or a specific pod name, letting you scope approvals to the most critical services while leaving low‑risk workloads unrestricted.
What happens if an approver is unavailable?
hoop.dev supports escalation paths and time‑based auto‑denial. If no approval is recorded within the configured window, the request is rejected, preventing indefinite waiting.
Does the gateway introduce latency?
The gateway operates at the protocol layer and adds only the time needed for policy evaluation and optional approval. In most environments the added latency is measured in milliseconds, far outweighed by the security benefit.
