Many assume that a machine‑learning model serving platform can simply run on an EKS cluster using a shared service account, and that this is sufficient for security. In reality, that approach gives the server a human‑like identity that is hard to audit and often over‑privileged. The real problem is the lack of a true non-human identity that can be scoped, recorded and revoked without touching the underlying workload.
Current practice: shared service accounts and static credentials
Today most teams deploy MCP (model‑control‑plane) servers on EKS by creating a single Kubernetes ServiceAccount that holds long‑lived AWS credentials. The same ServiceAccount is used by every model instance, every experiment runner, and even occasional admin scripts. Because the credentials never change, anyone who can reach the pod can issue API calls to the Kubernetes control plane as if they were a human operator. There is no per‑request audit, no justification for each kubectl command, and no way to hide sensitive fields in API responses. The result is a broad attack surface and an audit trail that only shows the ServiceAccount name, not the actual actor.
Why non-human identity alone is not enough
Switching to a dedicated IAM role for the MCP server is a step forward. The role can be assumed only by the pod, and it can be limited to the exact EKS permissions the model needs. This satisfies the "non-human identity" requirement: the server now presents a machine identity that can be managed like any other service account. However, the request still travels directly from the pod to the Kubernetes API server. No gateway inspects the traffic, no command‑level approval is required, and no session is recorded. If a compromised container starts issuing destructive kubectl commands, the cluster sees a legitimate request from a valid role and cannot distinguish intent.
hoop.dev as the data‑path enforcement layer
hoop.dev solves the missing piece by sitting in the data path between the MCP server and the EKS API. The architecture has three clear layers.
Setup – defining who may act
The first layer is the identity setup. An IAM role is created for the hoop.dev agent itself (Role X). A second, dedicated IAM role (Role Y) is configured on the EKS connection. The agent assumes Role Y when it needs to talk to the cluster. Role Y is mapped to a Kubernetes ClusterRoleBinding that grants only the permissions required by the model server. This setup decides who the request is and whether it may start, but it does not enforce any runtime policy.
The data path – the only place enforcement can happen
hoop.dev runs a network‑resident agent inside the same VPC as the EKS control plane. All traffic from the MCP server to the Kubernetes API is forced through this agent. Because the gateway sits on the wire, it can inspect each protocol message before it reaches the API server. This placement makes the gateway the sole point where guardrails can be applied.
Enforcement outcomes – what hoop.dev provides
- hoop.dev records every kubectl or exec session, providing a replayable log that auditors can review.
- hoop.dev can mask sensitive fields in API responses, such as secret names or token values, before they reach the model server.
- hoop.dev can require just‑in‑time approval for risky commands, routing them to a human reviewer before execution.
- hoop.dev can block disallowed commands outright, preventing accidental or malicious changes to cluster state.
Each of these outcomes exists only because hoop.dev occupies the data path. Without the gateway, the IAM role alone would grant unrestricted access.
Putting it together: a step‑by‑step mental model
1. Define a dedicated IAM role for the MCP server (Role Y) with the minimal set of EKS permissions.