How can you be sure that every request an AI‑driven MCP server makes to your EKS cluster is captured for later review via audit logging? Today many teams run MCP services directly on EKS pods and let the service communicate with the Kubernetes API using a static service‑account token. The token is mounted into the pod, the service issues kubectl or API calls, and the cluster obeys them without any record of who triggered the action or what data was returned. Because the request flows straight from the container to the API server, there is no central point where a guardrail can inspect the payload, enforce masking, or write an audit entry. The result is a blind spot: a powerful AI component can read or modify resources without any trace, making compliance and forensics extremely difficult.
Why audit logging is essential for MCP servers on EKS
Regulatory frameworks and internal policies often require a complete, immutable trail of every privileged operation. In the context of an MCP server, that means capturing who asked the model to list pods, create namespaces, or modify secrets, and storing the exact request and response. Without such a trail, a security investigation cannot reconstruct the sequence of events that led to a breach, and post‑mortem analysis becomes speculative. Moreover, audit logs enable anomaly detection – repeated read of sensitive secrets or unexpected cluster‑wide scans can be flagged in near real time.
How hoop.dev inserts the audit logging data path
The missing piece is a data‑path gateway that sits between the MCP server and the Kubernetes API. hoop.dev fulfills that role. It receives the identity token from the pod, validates it against the configured OIDC provider, and then forwards the request to the API server only after applying policy checks. Because the gateway is the only place the traffic passes, hoop.dev can record each request and response, attach the authenticated user identity, and store the record as part of the audit trail.
hoop.dev also enriches the log with contextual metadata such as the EKS cluster name, the IAM role assumed by the gateway agent, and the exact timestamp. This makes the audit trail searchable and useful for compliance reporting.
High‑level implementation steps
1. Set up identity and least‑privilege roles. Configure an IAM role for the hoop.dev agent (Role X) and a dedicated IAM role that the agent will assume when talking to EKS (Role Y). Role Y is mapped to a Kubernetes ClusterRoleBinding that grants only the permissions required for the MCP workload. This setup decides who the request is and whether it may start, but it does not enforce any logging on its own.
2. Deploy the hoop.dev gateway. Use the official Docker Compose quick‑start or the Kubernetes deployment guide. The gateway runs a network‑resident agent that holds the EKS IAM role credentials, so the MCP server never sees them. For detailed deployment instructions, see the getting‑started guide.