When auditors ask for SOC 2 evidence, you hand them a complete, immutable trail that proves every subagent action was authorized, recorded, and masked where required.
Subagents, automated scripts, CI jobs, or service accounts, are the workhorses of modern pipelines. They run commands, query databases, and push code without a human at the keyboard. In many organizations, those agents are granted static credentials and allowed to connect directly to production resources. The result is a blind spot: the identity system knows the agent existed, but nothing records what the agent actually did, which data it touched, or whether a privileged command received proper oversight.
Current reality without a gateway
Today, most teams provision a service account in the cloud console, embed its key in a CI secret store, and let the CI runner use that key to reach a database or a Kubernetes cluster. The account often has broad, standing permissions that exceed the needs of any single job. Because the connection goes straight from the runner to the target, there is no place to enforce policy, no inline masking of sensitive columns, and no checkpoint that forces a human to approve a risky command. Auditors therefore see only the static credential and a vague IAM policy; they cannot verify that a particular job accessed a protected table, that the access was time‑boxed, or that sensitive fields were redacted in logs.
What must change for SOC 2 compliance
SOC 2 requires evidence that access to systems is controlled, monitored, and auditable. The core controls revolve around three pillars:
- Identity and least‑privilege provisioning for every non‑human actor.
- A data‑path that can enforce guardrails such as just‑in‑time approval, command‑level blocking, and real‑time masking.
- Audit artifacts that demonstrate who did what, when, and with what outcome.
Providing the first pillar is relatively straightforward: you can issue OIDC tokens to subagents, bind them to specific groups, and enforce short lifetimes. However, without a gateway in the data path, those tokens alone do not produce the evidence auditors demand. The request still reaches the target directly, bypassing any opportunity to capture a detailed session record or to require an approval step.
Introducing hoop.dev as the enforcement point
hoop.dev is a Layer 7 gateway that sits between the subagent and the target resource. By proxying the connection, hoop.dev becomes the only place where policy can be applied and where evidence can be generated.
When a subagent presents its OIDC token, hoop.dev validates the token, extracts group membership, and then decides whether the request may proceed. If the request matches a policy that requires approval, hoop.dev pauses the operation and forwards it to an authorized reviewer. Once approved, the request continues.
During the session, hoop.dev records every command, every response, and every error. It can mask sensitive columns in database results before they are written to the audit log, ensuring that confidential data never appears in clear text in the logs. The recorded session can be replayed later, providing a forensic view of exactly what the subagent did.
Because hoop.dev holds the credential used to talk to the backend, the subagent never sees the secret. This eliminates credential leakage risk and satisfies the SOC 2 confidentiality principle.
How hoop.dev satisfies SOC 2 audit requirements
SOC 2 auditors typically request the following artifacts for systems accessed by automated agents:
- Access logs that show identity, timestamp, and outcome of each request.
- Approval records for privileged actions.
- Evidence that sensitive data was protected during processing.
- Session replays that can be used to verify that the observed behavior matches policy.
hoop.dev provides each of these directly:
- Access logs: hoop.dev records the subagent’s identity, the exact command issued, and the result of the operation.
- Approval workflow: hoop.dev requires a human reviewer to approve any request that matches a high‑risk rule before the command is sent to the backend.
- Inline masking: hoop.dev can redact fields such as credit‑card numbers or personally identifiable information in real time, so the stored logs contain only masked values.
- Session replay: hoop.dev stores a complete, time‑ordered transcript that can be streamed to an auditor for verification.
All of these artifacts are generated at the point where the subagent’s traffic leaves the network, ensuring they cannot be altered by the very process under review.
Getting started
To adopt this model, begin by defining a minimal set of OIDC scopes for each subagent and configuring hoop.dev as the relying party. The getting‑started guide walks you through deploying the gateway, registering a subagent connection, and creating a policy that requires approval for write‑heavy operations. The learn section contains deeper explanations of masking rules, session replay, and audit‑log retention.
FAQ
Do I need to change my existing CI pipelines?
No. hoop.dev acts as a transparent proxy, so you point your CI tool at the hoop.dev endpoint instead of the raw database or Kubernetes API. The rest of the pipeline remains unchanged.
Can I use hoop.dev with multiple cloud providers?
Yes. hoop.dev supports connections to databases, Kubernetes clusters, SSH hosts, and HTTP services regardless of where they run. The gateway simply forwards traffic after applying its policies.
How long are audit records retained?
Retention is configured according to your organization’s policy. For SOC 2 you typically keep logs for at least one year, and hoop.dev can be set up to meet that requirement.
Explore the source code, contribute improvements, and see the full feature set on the GitHub repository.
