Are you sure your nested agents are generating the audit evidence auditors demand for soc 2?
Most organizations treat nested agents like invisible workers: a CI pipeline launches a short‑lived process, that process spins up an SSH or database client inside a private subnet, and the client authenticates with a static credential stored in a secret manager. The credential is often shared across dozens of pipelines, and the connection is made directly to the target database or server. Because the agent runs with the same privilege every time, there is no per‑user trace, no record of which pipeline triggered which query, and no way to prove that sensitive fields were protected during the session.
This reality violates the core SOC 2 principle that every access to a system must be traceable to an individual identity and that the organization must retain evidence of how that access was governed. In practice, teams try to patch the gap with ad‑hoc logging inside the pipeline or by rotating the shared secret on a schedule. Those approaches still leave the request path untouched: the pipeline still talks directly to the database, still bypasses any approval workflow, and still exposes raw data to the agent process. The audit trail is incomplete, and the evidence is fragmented.
What is needed is a control surface that sits on the actual data path, forces every request through a gate that can record who asked for what, enforce just‑in‑time permissions, and mask or block data that must not leave the session. The gate must be able to produce a continuous log that ties each query to an identity, captures any human approval, and stores the raw traffic for replay. Only then can an organization claim that it continuously generates the evidence required for soc 2 compliance.
Why the data path matters for soc 2 evidence
Setup components, OIDC providers, service accounts, role‑based policies, determine who may start a connection. They are essential for identity verification, but they cannot enforce what happens once the connection is open. If the enforcement point lives inside the agent or the application, a compromised agent can simply skip the check, delete logs, or alter responses. SOC 2 expects that the enforcement point is outside the controllable process, so that no privileged insider or compromised workload can erase evidence.
Placing the enforcement layer in the data path guarantees three outcomes:
- Session recording: hoop.dev captures every request and response, preserving a replayable audit trail.
- Inline masking: hoop.dev can redact sensitive columns or fields before they reach the downstream consumer, ensuring that protected data never appears in logs or on screen.
- Just‑in‑time approval: hoop.dev can pause a high‑risk command and require a human reviewer before it proceeds, creating a documented approval record.
Because hoop.dev is the only component that sees the traffic, those outcomes exist only because hoop.dev sits in the data path.
How hoop.dev integrates with nested agents
Nested agents authenticate to hoop.dev using the organization’s OIDC or SAML provider. The gateway validates the token, extracts group membership, and then decides whether the request is allowed to proceed. The actual target, PostgreSQL, MySQL, an SSH host, or a Kubernetes API, remains unchanged; hoop.dev simply proxies the wire‑level protocol.
When a pipeline asks for a database connection, hoop.dev checks the request against policy, records the identity, and forwards the traffic to the database. If the query matches a masking rule, hoop.dev rewrites the response on the fly. If the operation is classified as high‑risk, hoop.dev holds the request, notifies an approver, and only releases the traffic after a signed approval is recorded. The entire interaction is stored in an audit log retained for compliance review.
Because the gateway holds the credential used to talk to the backend, the nested agent never sees the secret. This eliminates the need for shared static passwords and reduces the blast radius of a credential leak.
Continuous soc 2 evidence
SOC 2 auditors look for three kinds of evidence: identity‑bound access logs, documented approvals for privileged actions, and proof that sensitive data was protected. hoop.dev supplies each of those automatically:
- Every session is timestamped, tied to the authenticated identity, and stored in an audit log retained for compliance review.
- Approval workflows are captured as part of the session record, complete with approver identity and decision timestamp.
- Inline masking ensures that any regulated data (PII, PHI, PCI) never leaves the gateway in clear text, and the mask‑action is recorded alongside the original payload.
Since the logs are generated for every interaction, the organization does not need to run a separate “audit window” before a SOC 2 examination. The evidence accrues continuously, making the audit process a matter of extracting the relevant log slices rather than reconstructing events from scattered sources.
For teams that want to get started quickly, the getting‑started guide walks through deploying the gateway, configuring OIDC, and registering a database target. The feature documentation provides deeper examples of masking rules, approval policies, and session replay.
FAQ
Do I still need to rotate database passwords?
Because hoop.dev holds the credential and never exposes it to the nested agent, rotating the password is still a best practice, but the rotation process does not affect the audit trail. Each rotation creates a new credential entry in the gateway, and sessions continue to be recorded against the identity that initiated them.
Can I retroactively apply masking to old sessions?
No. Masking happens in real time as the response passes through hoop.dev. However, the raw session data is retained, so you can re‑process old logs with a separate tool if you need to demonstrate that masking rules would have applied.
How does hoop.dev help with the “availability” criterion of SOC 2?
Since hoop.dev runs as a highly available service in your own network, it can be deployed in a redundant fashion. The gateway’s health checks and failover mechanisms ensure that legitimate traffic is not blocked, while still providing the same level of audit and masking on each replica.
Next steps
To see the code, contribute, or run your own instance, visit the GitHub repository. The open‑source nature of hoop.dev means you can inspect the implementation of session recording, masking, and approval workflows to verify that they meet your organization’s compliance standards.
