How can you prove that every automated task, script, or AI‑driven job that touches your infrastructure generates reliable compliance evidence at the moment it runs?
Most teams treat agent orchestration as a black box: a CI pipeline pushes a change, a scheduled job rotates secrets, an AI assistant runs a diagnostic. The orchestration platform authenticates the service account, the job executes, and the result is logged in a generic system log. Those logs rarely contain who approved the action, which fields were redacted, or whether a risky command was blocked. The result is a compliance gap – auditors see a list of jobs but no evidence that each step followed the organization’s controls.
What you need is a point in the data flow where every request can be inspected, approved, and recorded before it reaches the target system. The requirement is simple: the request must still travel to the database, Kubernetes cluster, or SSH host directly, but the path must be instrumented so that compliance evidence is collected automatically.
Why the existing orchestration layer is insufficient
In a typical setup, the orchestration engine authenticates using a static service account or a long‑lived token. That token grants the engine standing access to all downstream resources. Because the token itself carries the authority, the engine can issue commands without any additional check. The audit trail is limited to the engine’s internal logs, which often omit the raw request payload, the exact SQL statement, or the command that was executed on a host. Masking of sensitive fields, just‑in‑time approvals, or command‑level blocking are not possible without modifying the engine itself.
Even if you add a separate logging service, it runs after the fact. It cannot prevent a dangerous command from reaching the target, nor can it redact data in real time. The enforcement outcomes you need, session recording, inline masking, approval workflows, remain outside the reach of the orchestration layer.
How hoop.dev creates compliance evidence in the data path
hoop.dev is built to sit in the data path between the orchestrator and the target resource. It acts as a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH hosts, and internal HTTP services. The gateway validates the caller’s OIDC or SAML token, extracts group membership, and then enforces policy before the request is forwarded.
Because hoop.dev is the only point where traffic passes, it can generate the compliance evidence you need. hoop.dev records each session, masks sensitive response fields, requires just‑in‑time approval for risky commands, and blocks disallowed operations before they reach the target. The evidence is stored in an audit log that auditors can query at any time.
How the evidence accrues continuously
- Every connection is logged with the identity that initiated it, the time, and the exact command or query.
- Inline masking ensures that personally identifiable information never appears in logs, while still providing a complete audit trail.
- Approval workflows capture who granted permission for a privileged operation, creating a clear chain of custody.
- Session replay lets you reconstruct the exact sequence of actions for forensic analysis.
These outcomes exist only because hoop.dev occupies the data path. The orchestration engine’s setup, its OIDC configuration, service accounts, and role bindings, decides who may start a request, but it does not enforce any of the controls listed above. hoop.dev is the enforcement layer that turns raw traffic into actionable compliance evidence.
Putting the pieces together
The architecture looks like this: an orchestrator (CI/CD, scheduler, AI agent) authenticates to hoop.dev using an OIDC token. hoop.dev checks the token, applies policy, and then proxies the request to the target resource. The target never sees the original credentials; hoop.dev holds them securely. After the request completes, hoop.dev writes a detailed audit record that includes the identity, the approved actions, any masked fields, and a replayable session artifact.
This pattern satisfies most regulatory frameworks that require continuous evidence of who did what, when, and why. Because the evidence is generated at the moment of access, you avoid the “post‑hoc” gap that plagues traditional logging approaches.
Getting started
To adopt this model, start with the getting‑started guide. Deploy the gateway in your network, register the resources you need to protect, and configure your orchestration platform to obtain an OIDC token from your identity provider. The learn section provides deeper coverage of policy definition, masking rules, and approval workflows.
All of the code is open source, and you can explore the implementation or contribute improvements on GitHub.
Explore the hoop.dev repository to see how the gateway is built and to start a deployment in your environment.
FAQ
Does hoop.dev replace my existing CI/CD system?
No. hoop.dev complements your orchestrator by adding a security‑focused data path. Your pipelines continue to trigger jobs as before; hoop.dev simply intercepts the actual connections to infrastructure.
What types of resources can be protected?
hoop.dev proxies connections to databases (PostgreSQL, MySQL, etc.), Kubernetes clusters, SSH hosts, RDP sessions, and internal HTTP services. Each of these can be wrapped with the same compliance‑evidence workflow.
How is sensitive data handled in the audit logs?
Inline masking removes or redacts fields such as credit‑card numbers or personal identifiers before the data is written to the audit store, ensuring privacy while preserving a complete operational record.
