What compliance evidence can you generate for every subagent action?
Why continuous evidence matters
Regulators and auditors increasingly expect teams to prove that privileged processes are monitored in real time. When a subagent runs a database migration, spins up a container, or updates a configuration file, the organization must show who initiated the request, what command was executed, and whether any sensitive data was exposed. Traditional approaches rely on periodic snapshots of log files or manual collection after an incident. Those methods create gaps: a missed log rotation, a mis‑configured syslog collector, or a short‑lived credential can erase the trail before anyone notices. The result is a compliance evidence gap that can lead to audit findings, fines, or loss of trust.
The missing piece in typical subagent deployments
Most teams deploy subagents as lightweight daemons that authenticate directly to the target service using a static credential. The credential lives on the host, often in a configuration file, and the subagent talks to the database or Kubernetes API without any intermediary. This model satisfies the immediate need for automation but leaves three critical weaknesses:
- No unified audit point. Each subagent writes its own logs, scattering data across nodes and formats.
- Uncontrolled data exposure. Responses that contain secrets or personal data travel back to the subagent unfiltered.
- Absent approval workflow. Any request that reaches the target executes immediately, even if a human should review it.
These gaps persist even when an organization adopts strong identity providers or role‑based access controls. The setup decides who may start a subagent, but it does not enforce what the subagent can do once the connection is open. Without a dedicated enforcement layer, the organization cannot claim that it generates reliable compliance evidence for every subagent interaction.
How hoop.dev creates a verifiable audit trail
Inserting a Layer 7 gateway between the subagent and the target resource resolves the three gaps described above. The gateway becomes the sole data path for every subagent request, and it enforces policy at the protocol level. The architecture consists of three logical layers:
Setup – identity and provisioning
Identity providers such as Okta, Azure AD, or Google Workspace issue OIDC or SAML tokens to the subagent. The tokens convey the subagent’s service account identity and group membership. hoop.dev validates those tokens, ensuring that only properly provisioned subagents may initiate a connection. This step decides who can start a request, but it does not dictate what the request can do.
The data path – the gateway
All traffic from the subagent to the database, Kubernetes cluster, or other supported target passes through hoop.dev. Because the gateway sits at the protocol layer, it inspects each command before it reaches the backend. hoop.dev applies just‑in‑time approval rules, blocks disallowed statements, and masks fields that contain regulated data. By centralising the traffic, the gateway becomes the only place where enforcement can happen.
Enforcement outcomes – continuous compliance evidence
Because hoop.dev controls the data path, it generates the compliance evidence required by auditors:
- Session recording. hoop.dev captures every subagent session byte‑for‑byte, allowing replay of the exact command sequence.
- Command‑level audit logs. hoop.dev logs each statement with the subagent’s identity, timestamp, and approval status.
- Inline data masking. hoop.dev redacts sensitive response fields before they are stored, ensuring that logs never expose secrets.
- Just‑in‑time approval workflow. When hoop.dev detects a high‑risk command, it routes the request to a designated approver, records the decision, and only then forwards the command.
These outcomes exist only because hoop.dev sits in the data path. If the gateway were removed, the subagent would talk directly to the target, and the system would no longer produce any of the above evidence.
Putting it together for subagents
To achieve continuous compliance evidence, teams should follow this high‑level flow:
- Register each subagent’s service account in the identity provider and assign it the minimal groups required for its job.
- Configure hoop.dev with the target resource credentials. The gateway stores the credentials; the subagent never sees them.
- Deploy the hoop.dev agent inside the same network segment as the target. The agent forwards traffic to the gateway, ensuring that every request passes through the enforced data path.
- Define masking rules and approval policies that match the organization’s regulatory requirements. For example, mask credit‑card numbers in database responses or require senior engineer approval for schema changes.
- Enable session recording and forward audit logs to the organization’s SIEM or log archive. The logs contain the full compliance evidence set: who, what, when, and how the request was handled.
With this pattern, compliance evidence accrues automatically, without the need for custom scripts or manual log collection. The evidence remains reliable because hoop.dev creates it at the point of control, and it aligns with standards that demand continuous monitoring of privileged operations.
Getting started
hoop.dev is open source and MIT licensed. The getting‑started guide walks you through deploying the gateway, registering a subagent, and defining basic policies. For deeper policy design, the learn section provides examples of masking rules, approval workflows, and audit‑log integration.
FAQ
Do I need to change my subagent code?
No. Subagents continue to use their native client libraries (psql, kubectl, etc.). The only change is that they point to the hoop.dev endpoint instead of the raw target address.
What happens if the gateway is unavailable?
Because all traffic must flow through hoop.dev, a temporary outage blocks subagent operations. This behavior deliberately prevents unmonitored access and guarantees that no session occurs without recorded evidence.
Can I store the audit logs in my own system?
Yes. hoop.dev can forward logs to any HTTP endpoint or file sink. The important point is that the logs are produced by the gateway, ensuring they contain the full compliance evidence set.
Explore the source code and contribute on GitHub.
