SOC 2 for AI agents: controlling access for audit-ready operations (on Kubernetes)

Many assume that simply assigning an AI agent a service account automatically satisfies SOC 2 audit requirements. In reality, without a controlled gateway the agent’s actions remain invisible to auditors, and any accidental data exposure or unauthorized command can go unchecked.

Why the default approach falls short of SOC 2 evidence

Today most teams deploy AI agents directly into a Kubernetes cluster. The agents use a static service‑account token that grants broad read‑write permissions across namespaces. The connection to the Kubernetes API server is a standard HTTPS request; the API server trusts the token and executes commands without an intervening control point. This model has three critical gaps for a SOC 2 audit:

• No immutable log of what the agent did. The API server writes audit events, but they are mixed with human activity and often lack the granularity needed to prove that a particular agent performed a specific command.
• No real‑time data protection. If the agent queries a secret‑containing ConfigMap, the raw value is returned to the agent and can be cached or exfiltrated.
• No approval workflow for risky operations. Deleting a namespace or scaling a deployment can happen automatically, leaving no evidence of a human review.

These gaps mean that when an auditor asks for "who did what, when, and why," the organization can only provide vague server logs that do not tie the activity to an individual identity or a documented policy decision.

Adding the missing pieces without changing the identity model

Introducing a non‑human identity that is scoped to the minimum set of permissions is the first step. The service account is still the source of the request, and the identity provider (OIDC, SAML, etc.) confirms that the request originates from an authorized AI process. This satisfies the "who" part of SOC 2, but it does not address the "how" and "why". The request still travels straight to the Kubernetes API server, bypassing any gate that could record, mask, or require approval.

In other words, the setup stage decides *who* can start a connection, but it does not enforce *what* the connection may do. Without a dedicated data‑path control, the audit trail remains incomplete, sensitive data can leak, and destructive commands can execute unchecked.

hoop.dev as the data‑path enforcement layer

hoop.dev inserts a Layer 7 gateway between the AI agent and the Kubernetes API. The agent authenticates to hoop.dev using the same OIDC token, and hoop.dev validates the token against the identity provider. Once the identity is verified, hoop.dev becomes the sole point that forwards traffic to the API server. Because all traffic passes through hoop.dev, it can apply the controls required for a SOC 2 evidence package:

• Session recording. hoop.dev records every request and response, storing a replay‑able log that maps each API call to the originating service account.
• Inline data masking. When a response contains a secret, hoop.dev can redact the value before it reaches the agent, ensuring that the agent never sees raw credentials.
• Just‑in‑time approvals. For high‑risk verbs such as delete, scale, or apply, hoop.dev can pause the request and require a human reviewer to approve it before forwarding.
• Command‑level audit. Each API call is logged with the request payload, the decision taken (allowed, masked, or blocked), and the identity that initiated it, providing the granularity auditors demand.

All of these outcomes exist only because hoop.dev sits in the data path. The identity provider alone cannot block a command, and the Kubernetes API server cannot retroactively mask data that has already been sent to the agent.

Mapping hoop.dev controls to SOC 2 criteria

SOC 2 focuses on five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. The controls offered by hoop.dev directly support three of them:

• Security. By requiring just‑in‑time approvals for privileged actions, hoop.dev reduces the attack surface and provides evidence of controlled access.
• Confidentiality. Inline masking ensures that sensitive data never leaves the gateway in clear text, satisfying confidentiality requirements.
• Processing Integrity. The immutable session log proves that every operation was executed exactly as authorized, supporting integrity assertions.

For Availability, organizations typically rely on Kubernetes’ own resilience features. For Privacy, the same masking and audit logs demonstrate that personal data is handled according to policy. When an auditor requests proof, the organization can hand over the hoop.dev logs, approval records, and masking policies as concrete artifacts.

Getting started

Deploying hoop.dev is straightforward. The quick‑start guide walks you through a Docker Compose deployment that includes OIDC authentication, a network‑resident agent, and default guardrails. Once the gateway is running, register your Kubernetes cluster as a connection, define the minimal service‑account scope, and enable the desired guardrails (recording, masking, approvals). Detailed steps are available in the getting‑started documentation and the broader learn section for deeper policy examples.

FAQ

Does hoop.dev replace the Kubernetes audit log?

No. hoop.dev complements the native audit log by providing a separate, replay‑able stream that is scoped to the AI agent’s identity and includes masking and approval decisions. The two logs together give a fuller picture for auditors.

Can I use hoop.dev with existing service‑account tokens?

Yes. hoop.dev validates the token against your identity provider, then proxies the request. The token’s permissions remain unchanged; hoop.dev simply adds the enforcement layer.

Is the recorded session data stored securely?

hoop.dev stores session data in a location you configure. The platform does not prescribe a specific storage backend, allowing you to choose a solution that meets your organization’s security and retention policies.

By placing a controlled gateway between AI agents and Kubernetes, organizations can produce the concrete, audit‑ready artifacts SOC 2 auditors look for: immutable command logs, masked secret responses, and documented human approvals. This approach turns a vague “service account with permissions” into a transparent, policy‑driven workflow that satisfies the evidence requirements of SOC 2.

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