In a fully auditable environment, soc 2 compliance means every reasoning trace that powers an AI-driven decision is accompanied by a tamper-proof record showing who initiated the request, when it happened, what data was accessed, and whether any sensitive fields were masked. An auditor can pull a single report and see approvals, command-level actions, and replayable sessions without chasing down scattered logs.
Today many organizations treat reasoning traces as an after‑thought. The logs live in application‑specific files, cloud storage buckets, or temporary caches. Access control decisions are often made by service accounts that have broad, standing permissions. When a regulator asks for evidence, teams scramble to piece together snippets from different systems, and the resulting audit trail is incomplete, unverified, and difficult to correlate with user identities.
SOC 2 evidence from reasoning traces
SOC 2 focuses on the Trust Services Criteria of security, availability, processing integrity, confidentiality, and privacy. For the processing‑integrity and confidentiality principles, auditors expect to see:
- Proof that every request to a protected system was made by an authenticated identity.
- Records of any human or automated approval that preceded a privileged operation.
- Logs that capture the exact command or query issued, along with the response payload.
- Evidence that sensitive fields (PII, credentials, secrets) were redacted before storage or transmission.
- Immutable, replayable sessions that can be reviewed in case of a breach investigation.
Reasoning traces generated by LLMs, rule engines, or data‑science pipelines can satisfy all of these requirements, if they are captured at the point where the request leaves the client and reaches the target system.
Why the data path matters
Identity providers (Okta, Azure AD, Google Workspace, etc.) determine who is making a request. They issue OIDC or SAML tokens that convey group membership and role information. This step is essential, but it does not enforce any policy on its own. The enforcement point must sit on the actual traffic flow, where the request is translated into a protocol‑specific command (SQL, SSH, HTTP, etc.). Only a gateway positioned in that data path can apply real‑time masking, block dangerous commands, and trigger just‑in‑time (JIT) approvals.
That gateway is hoop.dev. It proxies connections to databases, Kubernetes clusters, SSH hosts, and internal HTTP services. By sitting between the identity layer and the target, hoop.dev can record each session, mask fields on the fly, and require an approved workflow before a privileged operation proceeds. Those enforcement outcomes exist because hoop.dev is the only component that sees the full request and response payloads.
Generating SOC 2‑ready artifacts
When a user or an AI agent initiates a reasoning trace, hoop.dev performs three actions that map directly to SOC 2 evidence requirements:
- Session recording. hoop.dev records the traffic that passes through the gateway in a log that is designed to be immutable. The record includes the authenticated user ID, the exact timestamp, and the full command‑response exchange. Auditors can replay the session to verify that the operation behaved as expected.
- Inline data masking. Before any response leaves the target, hoop.dev applies field‑level redaction based on policies you define. The original value is never written to downstream storage, satisfying confidentiality controls without sacrificing observability.
- Just‑in‑time approval. For commands that match a high‑risk pattern (e.g., DROP DATABASE, privileged kubectl exec, or secret retrieval), hoop.dev pauses execution and routes the request to an approver. The approval decision, who approved, when, and why, is logged alongside the session.
These three artifacts together form a complete audit trail: who did what, when, and under what authority. Because the gateway holds the credential for the target system, the end‑user never sees secrets, and the audit log cannot be tampered with by the client.
Integrating with existing workflows
Adopting hoop.dev does not require rewriting your AI pipelines or changing the way you invoke psql, kubectl, or ssh. You simply point your client at the gateway’s address and let the existing OIDC token flow through. The gateway’s configuration defines which resources are protected, what masking rules apply, and which risk patterns trigger approvals. For teams that already use a CI/CD system, the same token can be exchanged for a short‑lived service account, ensuring that automated jobs also generate the same audit evidence as interactive users.
All of the setup steps, deploying the gateway, registering resources, and defining policies, are documented in the getting‑started guide. Once the gateway is running, you can explore the policy language and view sample audit reports in the learn section.
Retention and retrieval for auditors
hoop.dev stores session logs in a configurable backend (object storage, database, or log aggregation service). Retention policies can be aligned with your organization’s data‑governance rules, typically 12‑24 months for SOC 2 evidence. When an audit begins, you can export logs for a specific time window, filter by user or resource, and present the replayable recordings alongside the approval records. Because the logs are generated at the protocol layer, they contain the exact commands that were run, not just high‑level application events.
FAQ
Do I need to modify my existing AI or data‑science code?
No. hoop.dev works as a transparent proxy. Your code continues to call the target service (PostgreSQL, Kubernetes, etc.) using the same client libraries. The only change is the endpoint address, which points to the gateway instead of the direct host.
How does hoop.dev ensure the audit logs are tamper‑evident?
The gateway stores each session record in a storage system that preserves the logs without allowing modification. Because the gateway is the sole writer, any attempt to alter a log entry would require changing the storage system itself, which is out of scope for normal operations. This design satisfies SOC 2’s requirement for immutable audit evidence.
Can I use multiple identity providers with the same gateway?
Yes. hoop.dev supports any OIDC or SAML provider. You can configure separate client IDs for Okta, Azure AD, or Google Workspace, and the gateway will validate the token against the appropriate issuer before applying policies.
By routing reasoning traces through a Layer 7 gateway that records, masks, and approves every request, you create a single source of truth for SOC 2 auditors. The combination of session replay, inline redaction, and JIT approval gives you the concrete artifacts needed to demonstrate processing integrity and confidentiality across your AI‑driven workloads.
Explore the open‑source implementation and start building your SOC 2 evidence pipeline today.
