SOC 2 for AI coding agents: guardrails for code and data access (on Kubernetes)

An AI coding agent that can push code straight into a production Kubernetes cluster is a single point of catastrophic failure.

SOC 2 auditors treat this risk as a failure to enforce security, confidentiality, and processing integrity. Teams often expose a service‑account token to the agent, store it in a CI secret store, and let the agent invoke kubectl or the Kubernetes API directly. The token is long‑lived, scoped to the entire cluster, and never rotated. Because the request bypasses any gateway, every command the agent runs executes with full cluster privileges, and no central system records what was changed, who approved it, or whether sensitive data was exposed. If the agent is compromised, an attacker can enumerate pods, read secrets, and alter workloads without leaving a trace.

Even when organizations adopt a least‑privilege service account for the agent, the fundamental problem remains: the request still travels straight to the Kubernetes API server. The API server authenticates the token, but it does not provide a place to enforce runtime policies such as command‑level approval, inline masking of secret values in API responses, or session replay. Auditors looking for SOC 2 evidence will find a gap – the control environment can prove identity, but it cannot prove what the agent actually did, nor can it demonstrate that sensitive data was protected during the interaction.

SOC 2 requirements for AI coding agents

SOC 2 focuses on five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. For AI coding agents that interact with Kubernetes, the most relevant criteria are:

• Security: Restrict access to the minimum necessary and log every privileged action for review.
• Confidentiality: Protect secrets returned by the API from unauthorized exposure.
• Processing integrity: Ensure that only authorized code changes are applied and detect any deviation.

Auditors expect concrete evidence that these controls are enforced at the point where the request is made, not only at the identity provider. They look for immutable logs of each session, records of any just‑in‑time approvals, and proof that sensitive fields were masked before they could be captured in logs.

Why the data path must host the controls

Identity federation and scoped service accounts constitute the setup layer. They decide who the request is and whether it may start, but they cannot, on their own, guarantee that the request will be inspected, approved, or recorded. The only place to enforce the controls required by SOC 2 is the data path – the network hop that carries the request from the agent to the Kubernetes API.

When a gateway sits in that hop, it becomes the sole authority that can:

• Record every API call and response for immutable audit.
• Mask secret fields in responses before they reach logging systems.
• Require a human approval step for high‑risk operations such as deleting a pod or applying privileged manifests.
• Block commands that match a denylist, preventing accidental or malicious destructive actions.
• Replay sessions for forensic analysis.

hoop.dev as the SOC 2‑compatible gateway

hoop.dev sits in the data path between AI coding agents and the Kubernetes API server. It validates OIDC or SAML tokens, extracts group membership, and then applies policy checks on every request. Because hoop.dev is the only component that sees the raw request and response, it can generate the evidence required for SOC 2.

Specifically, hoop.dev:

• Generates evidence for SOC 2 by logging each session with user identity, timestamp, and the exact API payload.
• Masks sensitive fields such as secret data, ensuring that logs and downstream monitoring tools never store raw secret values.
• Enforces just‑in‑time approval workflows for privileged actions, so a security officer can sign off before the change is applied.
• Blocks disallowed commands in real time, reducing the blast radius of a compromised agent.
• Provides replay capability, allowing auditors to reconstruct exactly what the agent did during a given window.

All of these outcomes exist only because hoop.dev resides in the data path. Removing hoop.dev would return the environment to the insecure baseline described earlier, where no audit, masking, or approval occurs.

To get started, deploy the gateway using the standard getting‑started guide. The documentation walks through configuring OIDC authentication, registering a Kubernetes connection, and defining policy rules that align with SOC 2 criteria. For deeper insight into how hoop.dev implements masking, approvals, and session recording, explore the learn section.

FAQ

Does hoop.dev replace Kubernetes RBAC?

No. RBAC remains the primary mechanism for determining which identities can perform which actions. hoop.dev augments RBAC by adding runtime inspection, approval, and audit at the gateway level.

Can I use hoop.dev with existing CI pipelines?

Yes. The gateway works with any client that speaks the Kubernetes wire protocol, including kubectl invoked from CI jobs. The CI job authenticates via OIDC, and hoop.dev enforces the same policies you would apply to a human operator.

What happens to logs that contain secret data?

hoop.dev masks secret fields before they are written to log storage, so the raw secret never appears in audit logs. This satisfies the confidentiality requirement of SOC 2 while still providing enough context for forensic analysis.

Explore the source code and contribute to the project on GitHub.