What evidence do I need to hand an auditor to prove SOC 2 compliance for my internal platform, Devin? Most teams answer that they will pull logs from the database, show a list of users, and hope the auditor trusts the process. In practice, the reality is far messier.
Understanding the audit gap for Devin
Today many organizations run Devin with a handful of shared service accounts. Engineers embed static passwords in scripts, CI pipelines reuse the same credential across environments, and the only record of who ran what lives in the application’s own log files. Those logs are often rotated, lack timestamps that tie actions to a verified identity, and contain raw data that may include personally identifiable information. When a SOC 2 auditor asks for “evidence of who accessed the system, what they did, and whether any sensitive data was exposed,” the response is typically a collection of fragmented files that cannot be independently verified.
Because the gateway that sits between the user and Devin is missing, there is no single point where policy can be enforced. The request flows directly from the client to the backend, bypassing any control plane that could block a dangerous command, require an approval, or mask a credit‑card number in a response. The result is a blind spot: the organization cannot demonstrate that every session was observed, that privileged actions were approved, or that sensitive fields were protected.
What SOC 2 really asks for
SOC 2’s Trust Services Criteria for security, availability, and confidentiality require concrete, immutable evidence. Auditors look for:
- Identity‑bound logs that show exactly which user performed each operation.
- Proof that any access to sensitive data was either masked or approved in real time.
- Replayable session records that can be examined if a breach is suspected.
- Audit trails that cannot be altered without detection.
Even if Devin’s internal logging meets some of these items, the lack of a centralized enforcement layer means the organization cannot guarantee that the logs are complete, that they were generated at the point of access, or that they exclude protected data. The precondition we need to satisfy is a mechanism that sits on the data path, captures every request, and applies the required controls before the request reaches Devin.
How hoop.dev creates the audit trail
hoop.dev is a Layer 7 gateway that sits between identities and Devin. The gateway receives the user’s OIDC token, validates it, and then proxies the connection to Devin’s service endpoint. Because hoop.dev is the only point where traffic passes, it can enforce the controls that SOC 2 demands.
In the setup phase, the organization defines non‑human identities, OIDC groups, and least‑privilege roles that determine who may start a session. Those decisions decide who the request is, but they do not enforce anything on their own.
When a session is initiated, hoop.dev becomes the data path. At that moment it records the identity, the command, and the exact timestamp. The gateway records each request in a tamper‑evident log, allowing auditors to later verify who did what.
hoop.dev also applies inline masking. If a response from Devin contains a credit‑card number, the gateway redacts the sensitive fields before the data reaches the client. This satisfies the confidentiality criterion without requiring changes to Devin’s own code.
For high‑risk operations, such as dropping a production database or changing IAM policies, hoop.dev can pause the request and route it to a human approver. The approver’s decision is logged, and the request proceeds only after explicit approval. This just‑in‑time workflow provides the “approval evidence” that SOC 2 auditors expect.
Every session that passes through hoop.dev is recorded as a replayable stream. If a security incident is reported, the team can replay the exact sequence of commands, see the masked responses, and verify that no unauthorized data left the system. Because the recording happens at the gateway, the agent that runs inside the network never sees the raw credentials, preserving the “credential‑never‑exposed” guarantee.
Session recording and replay
hoop.dev records each byte of the protocol exchange, timestamps it, and stores it in a tamper‑evident log. Auditors can request a playback of any session, and the replay will show exactly what the user typed and what the backend returned, with sensitive fields already masked.
Inline masking for confidential fields
When a query returns rows that contain personal data, hoop.dev applies pattern‑based redaction before the data leaves the gateway. The masking policy is defined once and enforced on every response, guaranteeing that no raw PII appears in audit logs or client screens.
Just‑in‑time approvals for privileged actions
Before a destructive command reaches Devin, hoop.dev checks the policy associated with the user’s group. If the command is flagged as high‑risk, the gateway creates an approval ticket, notifies the designated approver, and logs the decision. The command is executed only after the approver grants permission, providing a clear audit trail of who authorized the action.
By placing these controls in the data path, hoop.dev satisfies the core evidence requirements of SOC 2 without requiring Devin to be rewritten. The organization can point auditors to a single source of truth: the gateway’s logs, approvals, and session recordings.
Getting started with hoop.dev
To begin, follow the getting‑started guide to deploy the gateway and register Devin as a protected connection. The learn section provides deeper explanations of session recording, masking policies, and approval workflows.
Explore the open‑source repository on GitHub to see the implementation details and contribute improvements: hoop.dev on GitHub.
FAQ
What kind of logs does hoop.dev generate for SOC 2?
hoop.dev produces identity‑bound request logs, approval decisions, and masked response records. Each entry includes a timestamp, the user’s verified identity, and the exact command issued.
Can I use hoop.dev with existing CI pipelines?
Yes. The gateway works with any client that can speak the target protocol, so CI jobs can route their database or SSH commands through hoop.dev without code changes.
How does hoop.dev ensure the audit trail cannot be altered?
Because the logs are written at the gateway, outside the application process, they are tamper‑evident and any attempt to modify them would be detectable during an audit.
