Tool‑using agents that act on production systems without proper oversight expose your organization to audit failure.
SOC 2 auditors expect concrete evidence that every privileged operation is traceable, that access is granted only for the minimum time needed, and that sensitive data never leaves the environment unprotected. The evidence package typically includes session recordings, request‑and‑approval logs, identity verification records, and any data‑masking decisions applied during the interaction.
When an automated script, CI job, or AI‑assisted assistant connects directly to a database, Kubernetes cluster, or SSH host, the organization often relies on the script’s own logging. Those logs are scattered, lack tamper evidence, and rarely capture the exact commands that were run. Moreover, the script’s credentials are often stored in long‑lived secrets, making it impossible to prove that a particular user authorized the action at the moment it occurred.
To satisfy SOC 2, the control model must address three gaps:
- Identity provenance: The system must prove which human or service identity initiated the request.
- Just‑in‑time authorization: Access should be granted for a single session and must be approved when the operation is risky.
- Full‑session audit: Every command and response must be recorded in a tamper‑evident manner for later review.
Those requirements can be met only when the enforcement point sits on the data path, not in the surrounding identity provider or in the agent’s own process. The identity provider (Okta, Azure AD, Google Workspace, etc.) can verify who the caller is, but it cannot inspect the payload of a PostgreSQL query or the keystrokes of an SSH session. Likewise, a CI runner can hold a short‑lived token, yet it cannot block a dangerous command before it reaches the target.
SOC 2 audit evidence generated by hoop.dev
hoop.dev is a Layer 7 gateway that lives between identities and infrastructure. Because it proxies the traffic, hoop.dev can apply the controls required by SOC 2 directly on the connection. The gateway records each session, stores the raw command stream, and timestamps every line of output. When a request matches a policy that requires human review, such as a DROP DATABASE command or a privileged Kubernetes exec, hoop.dev pauses the flow and routes the request to an approver. The approval decision, the approver’s identity, and the time of the decision are all persisted alongside the session record.
In addition to logging, hoop.dev can mask fields that contain personally identifiable information or secret keys. The masking decision is recorded so that auditors can see that the data was protected without exposing the original values. Because the gateway holds the target credentials, the downstream system never sees the user’s secret, eliminating credential leakage from the audit trail.