Many assume that an MCP server on EKS can be left to run unchecked once it’s deployed, because the cluster’s IAM role already limits who can call the service. In reality the service can still be invoked by any pod or user that gains network reach, and there is no built‑in gate to require approval workflows before a risky operation.
Today most teams provision a static IAM role for the EKS agent, grant that role broad permissions, and let developers invoke the MCP endpoint directly with their usual kubectl or SDK clients. The connection bypasses any review step, and every request is logged only by the Kubernetes audit layer, which does not capture the exact payload or the business context of the call. When a privileged command slips through, the damage is discovered only after the fact, if at all.
Why approval workflows matter for MCP servers on EKS
Approval workflows provide a deliberate pause before a potentially destructive action reaches the MCP server. They let a security officer or a peer reviewer confirm intent, verify that the request complies with policy, and add an audit record that ties the decision to a specific identity. Without this gate, any compromised credential can be used to launch arbitrary code, exfiltrate data, or modify critical configurations.
The missing piece is a control surface that sits on the request path, not somewhere else in the stack. The setup – OIDC authentication, IAM role for the agent, and RBAC inside the cluster – decides who may start a session, but it does not enforce anything about what the session may do. The request still travels straight to the MCP server, unmediated, with no chance to inject a review step.
How hoop.dev implements approval workflows on EKS
hoop.dev acts as a Layer 7 gateway that intercepts every request destined for the MCP server. The gateway runs an agent inside the VPC, assumes the dedicated IAM role configured for EKS access, and presents the user’s OIDC token to verify identity. Once the user is authenticated, hoop.dev evaluates the request against a policy that requires approval for certain operations.
If the policy matches, hoop.dev pauses the request and routes it to an approval workflow. A designated reviewer receives a concise summary – who is requesting, what command is being issued, and the target resource. The reviewer can approve, deny, or add a comment. Only after an explicit approval does hoop.dev forward the request to the MCP server.
Because hoop.dev sits in the data path, it also records each session and retains the audit trail outside the agent process, enabling replay and forensic analysis. In addition to approval, hoop.dev can mask sensitive fields in the MCP response, block commands that match a deny list, and enforce just‑in‑time access by granting the underlying IAM role only for the duration of an approved session. All of these enforcement outcomes exist because the gateway is the only place where traffic can be inspected and altered before it reaches the target.
Key components of the solution
- Setup: Users authenticate via OIDC/SAML; the hoop.dev agent assumes the EKS IAM role that maps to a Kubernetes RBAC binding. This determines who may start a session.
- The data path: hoop.dev sits between the user and the MCP server, inspecting each request at the protocol layer.
- Enforcement outcomes: hoop.dev enforces approval workflows, records the session, masks data, and revokes the IAM role when the session ends.
To try this pattern, start with the getting‑started guide that walks through deploying the gateway, configuring the EKS role, and defining an approval policy. The learn section provides deeper examples of policy language and workflow customization.
FAQ
Q: Does hoop.dev replace Kubernetes RBAC?
A: No. RBAC still governs what the assumed IAM role can do inside the cluster. hoop.dev adds a gate before the request reaches the cluster, ensuring that only approved actions are allowed.
Q: Can I use the same approval workflow for other services?
A: Yes. The policy engine is generic; you define the target resource and the conditions that trigger an approval step, and hoop.dev will enforce it for any supported connector.
Q: Where are the session recordings stored?
A: Recordings are kept by hoop.dev as part of its session audit trail, separate from the agent that runs the connection.
Ready to see the code in action? Explore the source repository on GitHub and contribute your own policy extensions.
