Standing access and AI agents on Kubernetes
Many teams believe that just-in-time access automatically eliminates the threat posed by AI‑driven automation, but the reality is more nuanced. Most production clusters still expose a handful of service accounts that carry broad RBAC roles – often cluster‑admin or edit – to every CI/CD pipeline, monitoring daemon, or internal chatbot. An AI‑powered agent that can invoke kubectl with those credentials can read secrets, create pods, or delete workloads without any human oversight. Because the connection goes straight from the agent to the API server, there is no record of which command was issued, no way to redact sensitive fields from the response, and no checkpoint to stop a destructive operation before it runs.
Why just-in-time access alone isn’t enough
Just-in-time access attempts to tighten the model by issuing short‑lived OIDC tokens for each request. The agent authenticates to the identity provider, receives a token that encodes the user’s group membership, and then presents that token to the Kubernetes API. This approach does solve the credential‑sprawl problem: static keys are no longer stored in pipelines, and the token expires quickly.
However, the request still travels directly to the API server. The gateway that would enforce policy, mask secret values in kubectl get secret output, or require a human approver for kubectl delete pod never sees the traffic. Consequently, the following gaps remain:
- There is no command‑level audit that ties a specific AI‑generated request to an engineer’s identity.
- Inline data masking cannot be applied, so a compromised agent could exfiltrate database passwords that appear in pod specs or secret objects.
- Risk‑based approvals (for example, requiring a security analyst to approve a pod‑creation that runs privileged containers) cannot be enforced because the API server trusts the token outright.
In short, just-in-time access improves credential hygiene but does not provide the enforcement surface needed to control AI‑driven actions.
The gateway approach that unifies control
Enter a Layer 7 access gateway that sits between the identity provider and the Kubernetes API. By placing the gateway in the data path, every request, whether issued by a human, a CI job, or an autonomous AI agent, must pass through a single, policy‑driven proxy before reaching the cluster. This proxy is hoop.dev.
hoop.dev performs three critical functions that close the gaps described above:
- Just‑in‑time enforcement. The gateway validates the OIDC token, checks the requester’s group membership, and then decides whether the operation can proceed immediately, needs a human approver, or must be blocked.
- Inline masking and command‑level audit. When a request returns a secret or a configuration object, hoop.dev can redact sensitive fields before they reach the caller, and it records the exact command and response in a session log.
- Session recording and replay. Every interaction is captured, enabling post‑mortem analysis of what an AI agent attempted, what was approved, and what was blocked.
Because the gateway owns the credentials used to talk to the cluster, the downstream agent never sees them. This “agent‑never‑sees‑the‑credential” property eliminates the possibility of credential leakage from compromised containers.