AI coding agents that push code directly into clusters can bypass every human checkpoint, making effective access reviews virtually impossible.
Today many teams grant these agents a static service‑account token that has cluster‑admin scope. The token lives in a CI secret, is copied into pipelines, and is used by the agent to apply manifests, run helm charts, or execute kubectl commands. Because the token never changes, any compromise of the CI system instantly grants an attacker unrestricted access to every namespace. Auditors can see a single credential in the secret store, but they cannot tell which commands were run, who approved them, or whether sensitive data was exposed.
This reality renders the access reviews process almost meaningless. Reviewers can only verify that a token exists and that its role is appropriate on paper. The actual traffic that reaches the Kubernetes API server bypasses any gate that could log, mask, or require a human decision. The request still lands directly on the control plane, leaving the audit trail empty, masking absent, and approval impossible.
Why access reviews matter for AI coding agents
Access reviews are intended to answer three questions: who accessed what, why they accessed it, and whether the access complied with policy. When an AI agent runs with a long‑lived credential, the answer to the first question is easy – the service account name – but the second and third questions are lost. Without a point of inspection, you cannot enforce least‑privilege at the command level, you cannot require a manager to approve a risky rollout, and you cannot redact secrets that appear in API responses.
In practice, this leads to two dangerous patterns. First, engineers add new permissions to the service account to fix a broken pipeline, gradually expanding its blast radius. Second, the agent’s output may contain database passwords or internal URLs that are never scrubbed, creating compliance gaps. Both patterns defeat the purpose of periodic access reviews because the evidence needed to evaluate risk simply does not exist.
How hoop.dev strengthens access reviews on Kubernetes
hoop.dev solves the problem by becoming the mandatory data path between any identity – human or AI – and the Kubernetes API. When a request is made, hoop.dev inspects the wire‑protocol payload, records the entire session, and can apply inline masking to any fields that match a policy. It also enforces just‑in‑time approval: a high‑risk command such as creating a ClusterRoleBinding is paused until an authorized reviewer clicks approve. Because the gateway owns the credential, the AI agent never sees the underlying token, eliminating credential leakage.
Every interaction that passes through hoop.dev is automatically tied to the caller’s identity. The audit log includes the user or service account, the exact kubectl command, the timestamp, and the decision outcome (allowed, masked, or blocked). This log is the evidence that makes access reviews concrete: reviewers can now see which AI‑generated changes were made, who approved them, and whether any sensitive data was exposed.
Because hoop.dev sits in the data path, it is the only place where enforcement can happen. Setup steps such as configuring OIDC, assigning least‑privilege roles, and deploying the network‑resident agent are necessary to identify the caller, but they do not provide the protection on their own. The gateway is the active component that records, masks, and gates each request.
Teams can start with the getting started guide to spin up the gateway in a Docker compose environment, then point their CI pipelines at the hoop.dev endpoint instead of the raw API server. The learn section contains detailed policy examples for Kubernetes, including how to mask secret fields and require approval for privileged resources.
Practical steps for tighter access reviews
- Replace static service‑account tokens with short‑lived identities that are validated by hoop.dev on each request.
- Define masking rules for annotation fields that may contain API keys.
- Configure approval workflows for any operation that creates or modifies RBAC objects.
- Enable session replay so auditors can watch exactly what the AI agent did during a pipeline run.
- Integrate the audit stream with your SIEM to correlate AI‑driven changes with other security events.
FAQ
- Can I still use my existing CI pipelines? Yes. The only change is that the pipeline points to the hoop.dev endpoint instead of the raw Kubernetes API server.
- Does hoop.dev store my Kubernetes credentials? The gateway holds the credential in memory and never exposes it to the caller, eliminating credential sprawl.
- What happens if an AI agent tries to run a disallowed command? hoop.dev blocks the command, logs the attempt, and can trigger an alert for review.
By moving the enforcement point to the gateway, organizations regain the visibility and control needed for meaningful access reviews. The combination of session recording, inline masking, and just‑in‑time approval turns a blind spot into a searchable audit trail.
Explore the source code and contribute on GitHub.
