An offboarded contractor left a CI pipeline that still runs an AI‑driven code‑reviewer, exposing a gap in soc 2 compliance. The reviewer authenticates with a static service account and pushes changes directly to the on‑prem Git server. No one sees which model version generated a change, and the pipeline never asks for human approval before deploying a risky migration.
This is how many teams operate today: an AI agent holds a long‑lived credential, talks straight to internal resources, and bypasses any visibility or control layer. The result is a blind spot for auditors and a potential vector for accidental data loss.
Why the current state still falls short of soc 2
soc 2 demands that every access to a system be traceable, that privileged actions be approved, and that sensitive data be protected in‑flight. Even if an organization provisions the minimal IAM role for the agent, the request still reaches the target without a gate that can log the exact query, mask credit‑card numbers, or pause a destructive command for a manager’s sign‑off. In other words, the setup alone does not produce the continuous evidence auditors expect.
The missing piece is a data‑path enforcement point that can observe, control, and record each interaction before it hits the backend service.
Continuous evidence as a soc 2 control
soc 2’s Trust Services Criteria for security and confidentiality require an organization to retain logs of who accessed what, when, and why. It also expects evidence that data‑in‑transit is protected and that privileged commands are subject to approval workflows. Achieving this with AI agents means:
- Capturing every request and response generated by the agent.
- Masking sensitive fields (for example, SSNs or API keys) before they are stored in logs.
- Requiring a human reviewer to approve high‑impact operations such as schema changes.
- Storing the audit trail in a location that the agent itself cannot modify.
When these controls sit in the data path, the organization can demonstrate to auditors that evidence is collected automatically, continuously, and without manual effort.
Introducing hoop.dev as the data‑path gateway
hoop.dev is a layer‑7 gateway that sits between AI agents and the infrastructure they need to reach. The gateway runs a network‑resident agent inside the on‑prem environment and proxies connections to databases, Kubernetes clusters, SSH servers, or internal HTTP APIs. Because the gateway is the only point where traffic passes, it can enforce the controls listed above.
Setup: defining who the AI agent is
The first step is to provision an identity for the agent using OIDC or SAML. The identity provider issues a short‑lived token that hoop.dev validates on each connection attempt. This token encodes the agent’s group membership and any attribute‑based policies that determine which resources it may request. The setup phase decides who may start a session, but it does not enforce what the session can do.
The data path: where enforcement happens
Once the token is accepted, hoop.dev becomes the sole conduit for the agent’s traffic. At that point hoop.dev records each request, applies inline masking to any fields that match a sensitivity rule, and checks the command against a policy engine. If the command is deemed risky, such as a destructive SQL statement or a Kubernetes pod deletion, hoop.dev pauses the request and routes it to an approval workflow. Only after a designated approver signs off does the gateway forward the command to the target system.