Imagine an AI‑driven code‑generation service that runs as part of a CI pipeline. The service needs to apply Kubernetes manifests to an Amazon EKS cluster in order to spin up test environments for each pull request, and it authenticates using OIDC/SSO to the identity provider. The team, eager to keep the workflow simple, stores a long‑lived kubeconfig file in the pipeline’s secret store. That file contains a static token with cluster‑admin privileges, and every job in the pipeline reuses it.
Because the token is shared across all builds, any compromise of the CI runner instantly grants unrestricted cluster access. No individual run is tied to a human identity, no approval step exists, and the platform does not record what commands were executed. The result is a blind spot: malicious code could delete namespaces, exfiltrate data, or create persistent backdoors, and the security team would have no evidence of who or what performed the action.
Why OIDC/SSO alone does not protect AI agents in EKS
Integrating OIDC/SSO gives the pipeline a way to authenticate the AI agent with the identity provider. The agent receives a JWT that proves it belongs to a service‑account group, and the EKS API can map that group to a Kubernetes RBAC role. This step eliminates hard‑coded passwords, but it does not change the fact that the request travels directly from the CI runner to the Kubernetes API server.
When the request bypasses any enforcement point, several gaps remain:
- The API server sees a valid token but cannot tell whether the request originated from a legitimate build or a compromised runner.
- There is no just‑in‑time approval workflow; the token grants the same permissions every time.
- Command‑level audit is limited to the standard Kubernetes audit log, which does not capture the exact CLI arguments or the full interactive session.
- Sensitive response fields, such as secret values returned by kubectl get secret, are exposed to the agent without masking.
These weaknesses persist even though OIDC/SSO is in place, because the enforcement boundary is still the cluster itself.
Putting the gateway in the data path
The missing piece is a Layer 7 gateway that sits between the AI agent and the EKS control plane. By routing every kubectl or API request through a proxy, the organization gains a single, controllable enforcement surface. The gateway can inspect the wire‑protocol, apply policies, and record the full session before the request ever reaches the cluster.
In practice, the AI agent authenticates to the gateway with its OIDC/SSO token. The gateway validates the token against the identity provider, extracts group membership, and then decides whether the request is allowed, needs approval, or should be masked. Only after these checks does the gateway forward the request to the EKS API using its own short‑lived IAM role.
How hoop.dev enforces the controls
hoop.dev implements the gateway described above. It runs a network‑resident agent that assumes a dedicated IAM role for EKS access. The agent maps the session name to a Kubernetes RBAC binding, ensuring that the permissions granted are scoped to the specific request. Because hoop.dev sits in the data path, it can:
- Record every kubectl command and its output, creating a replayable session for forensic analysis.
- Apply inline masking to response fields that contain secrets, preventing the AI agent from seeing raw values.
- Require just‑in‑time approval for high‑risk operations such as kubectl delete namespace or cluster‑wide role bindings.
- Block disallowed commands before they reach the API server, reducing the blast radius of a compromised runner.
All of these outcomes exist only because hoop.dev is the enforcement point. If the gateway were removed, the OIDC/SSO token would flow directly to EKS and none of the above protections would apply.
Getting started
To adopt this model, begin with the standard getting‑started guide. The documentation walks you through deploying the hoop.dev gateway, configuring the EKS connection, and enabling OIDC/SSO for service accounts. The open‑source repository on GitHub contains the full set of manifests and examples you need to spin up the gateway in a test environment.
Once the gateway is running, register the EKS cluster as a connection, specify the IAM role that the agent should assume, and define the RBAC binding that maps session names to Kubernetes roles. After that, update your CI pipeline to point to the hoop.dev endpoint instead of the raw API server. The pipeline will continue to use the same OIDC/SSO flow, but now every request is inspected and recorded.
Further reading
For deeper insight into masking, guardrails, and session replay, see the learn section. It explains how hoop.dev’s native masking engine works, how to configure just‑in‑time approvals, and how to query recorded sessions for audits.
FAQ
- Do I need to change my existing Kubernetes RBAC policies? No. hoop.dev creates a temporary binding that maps the session identity to the existing role you select. Your cluster’s permanent policies remain untouched.
- Will the AI agent still see the same API response format? Yes, except that any fields marked as sensitive are masked in‑flight. The rest of the response is unchanged, preserving compatibility with downstream tooling.
- How does hoop.dev handle token expiration? The gateway validates the OIDC/SSO token on each request. If the token is expired or revoked, the request is denied before it reaches EKS.
Explore the source code and contribute on GitHub.
