When every request through CrewAI leaves a tamper‑proof trail, auditors can verify that access controls, data handling, and change management all meet SOC 2 expectations without chasing missing logs.
In practice, many AI‑driven services rely on static service accounts or long‑lived keys that are shared across pipelines. Engineers push code, bots trigger jobs, and the underlying infrastructure is accessed directly. The result is a black box: the audit team cannot see who ran which command, what data was returned, or whether any privileged operation received approval.
Without a unified record, SOC 2 auditors typically request ad‑hoc screenshots, manual sign‑offs, or point‑in‑time snapshots, making verification hard.
The first step toward compliance is to acknowledge that identity and credential management alone are insufficient. Even with OIDC or SAML tokens that define who can start a session, the request still travels straight to the target database, Kubernetes cluster, or SSH host. No gate intercepts the traffic, no policy logs the exact query, and no inline mask protects sensitive fields. The environment remains vulnerable to accidental data exposure and lacks the evidence needed for the Trust Services Criteria.
Continuous SOC 2 evidence with hoop.dev
hoop.dev provides the missing data path that sits between CrewAI agents and the resources they need to reach. By acting as a Layer 7 gateway, hoop.dev can inspect every protocol‑level request, enforce just‑in‑time approvals, mask confidential columns, and record the full session for later replay. Because the gateway is the only point where traffic flows, hoop.dev guarantees capture of all enforcement outcomes.
Setup: identity‑driven access
Engineers and automated agents authenticate to hoop.dev via an OIDC or SAML provider such as Okta or Azure AD. The identity token conveys the user’s groups and attributes, which hoop.dev uses to decide whether a session may start. This step defines *who* is making the request but does not yet enforce any policy on the data that will cross the wire.
The data path: hoop.dev as the gateway
Once authentication succeeds, the connection is handed to hoop.dev’s proxy agent that lives inside the same network as the target system. All traffic, SQL statements, kubectl commands, SSH shells, passes through this proxy. Because hoop.dev is the sole conduit, it can apply real‑time checks before the request reaches the backend.
Enforcement outcomes that satisfy SOC 2
- Session recording. hoop.dev records every byte that flows in both directions and stores the logs externally, giving auditors evidence of who did what and when.
- Just‑in‑time approval. For high‑risk commands such as dropping a table or modifying a Kubernetes namespace, hoop.dev can pause the request and route it to a designated approver. hoop.dev logs the approval decision alongside the original request, fulfilling the SOC 2 requirement for privileged‑access review.
- Inline data masking. When a query returns columns that contain personally identifiable information, hoop.dev can redact those fields on the fly. hoop.dev records the masking action, proving that sensitive data never left the controlled environment unprotected.
- Command blocking. Dangerous patterns, like “rm -rf /” over SSH, can be rejected before execution. hoop.dev stores the block event with the originating identity, demonstrating proactive risk mitigation.
hoop.dev generates each of these outcomes because the gateway is the only place where the request can be observed and altered. Removing hoop.dev would revert the system to a direct connection with no audit trail, no masking, and no approval workflow.
Mapping evidence to SOC 2 criteria
SOC 2’s Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy all call for documented controls and verifiable logs. hoop.dev directly supplies the artifacts auditors look for:
- CC6.1 – Logical access controls. The OIDC token verification performed by hoop.dev shows that only authorized identities can initiate a session.
- CC6.2 – Change management. Approval logs for schema changes or deployment commands prove that changes were reviewed before execution.
- CC6.3 – Monitoring and logging. Continuous session recordings give a complete, tamper‑evident view of all activity on the protected resources.
- CC6.4 – Confidentiality. Inline masking ensures that any data classified as confidential is never exposed in clear text to downstream consumers.
Because hoop.dev produces these records automatically, the evidence accrues continuously rather than being assembled manually after an audit window. This aligns with the “continuous compliance” mindset that modern SOC 2 audits increasingly expect.
Getting started with hoop.dev for CrewAI
Begin by following the getting‑started guide to deploy the gateway in your environment. The quick‑start uses Docker Compose and configures OIDC authentication out of the box. Next, register each CrewAI target, PostgreSQL, Kubernetes, SSH, so that hoop.dev holds the credentials and can proxy the traffic. Finally, enable the desired guardrails (session recording, masking, approval policies) from the feature documentation. The open‑source repository contains the full deployment manifests and example policies.
FAQ
Does hoop.dev replace my existing IAM policies?
No. hoop.dev relies on the identity token you already issue from your IdP. It adds a layer of enforcement on top of those policies, but it does not modify your IAM configuration.
How long are the session recordings kept?
Retention is configurable in the deployment settings. The key point for SOC 2 is that the logs are stored outside the target host and can be retained for the period required by your audit schedule.
Can I use hoop.dev with multiple cloud providers?
Yes. hoop.dev supports a wide range of connectors, including databases, Kubernetes clusters, and SSH hosts across AWS, Azure, and GCP. Each connection is proxied independently, allowing a unified audit trail.
Explore the open‑source code on GitHub to see how the gateway is built and to contribute enhancements that further strengthen your SOC 2 evidence collection.
