Compliance Evidence for Planner-Executor Agents

Are you confident that every action taken by your planner‑executor agents can be traced back to a single, tamper‑proof record that satisfies compliance evidence requirements?

Most organizations treat these agents like any other service account: a static credential is stored in a vault, the agent pulls the secret, and then it opens a direct TCP connection to a database, an API endpoint, or a cloud service. The connection bypasses any central control point, so there is no real‑time visibility into what the agent is doing. If the agent runs an unexpected query, writes to the wrong table, or inadvertently leaks a PII field, the event disappears into the target’s logs – logs that may be rotated, that may lack user‑level detail, and that are often inaccessible to auditors. In short, the current model provides no continuous compliance evidence.

What most teams already have in place is a non‑human identity for the agent – an OIDC token, a service‑account key, or an IAM role that grants the minimum set of permissions required for the job. This satisfies the “least‑privilege” requirement, but it does not solve the core problem: the request still travels straight from the agent to the target, untouched by any guardrail, and without a reliable audit trail. The identity check happens at the perimeter, not on the data path, so the system cannot enforce inline masking, command‑level approvals, or session recording. Those capabilities remain missing, leaving a gap in the compliance evidence chain.

Enter hoop.dev. It is a Layer 7 gateway that sits between the planner‑executor agent and the infrastructure it controls. By proxying every connection, hoop.dev becomes the only place where enforcement can be applied. When an agent authenticates with an OIDC token, hoop.dev validates the token, extracts the identity, and then forwards the request to the target on behalf of the agent. While the traffic passes through the gateway, hoop.dev can record the full session, mask any fields that match compliance policies, and, if a command is deemed risky, pause execution and route the request to a human approver. Because the gateway owns the credential used to talk to the backend, the agent never sees the secret, and hoop.dev captures the entire interaction as immutable compliance evidence.

From a compliance standpoint, hoop.dev provides three essential outcomes:

• Continuous audit logs: Every query, API call, or shell command is logged with the exact user identity, timestamp, and result. These logs are stored outside the target system, giving auditors a single source of truth.
• Inline data masking: Sensitive fields – such as credit‑card numbers or social‑security numbers – are redacted in real time before they ever reach the agent or downstream systems, ensuring that downstream logs do not contain raw PII.
• Just‑in‑time approvals: High‑risk operations trigger a workflow that requires a designated reviewer to approve the action, creating a documented decision trail for each privileged command.

Because hoop.dev is open source and MIT‑licensed, you can run the gateway inside your own network, integrate it with any OIDC provider, and extend the policy engine to match your organization’s compliance framework. The getting‑started guide walks you through deploying the gateway with Docker Compose, while the learn section details how to define masking rules, approval policies, and session‑recording settings.

How the data path changes for planner‑executor agents to generate compliance evidence

Before hoop.dev, the data path looked like this:

1. Agent retrieves a static credential from a vault.
2. Agent opens a direct TCP connection to the target.
3. Target processes the request; any logs are kept locally.

After introducing hoop.dev, the path becomes:

1. Agent authenticates to hoop.dev with an OIDC token.
2. hoop.dev validates the token, then establishes its own credentialed connection to the target.
3. All traffic flows through hoop.dev, where it can be recorded, masked, or paused for approval.
4. After processing, hoop.dev returns the response to the agent.

This shift moves the enforcement point from the target to the gateway, guaranteeing that every action is captured as compliance evidence.

FAQ

How does hoop.dev ensure the audit logs cannot be altered?

hoop.dev writes each session record to a storage backend that is separate from the target system. Because the gateway is the sole writer of those records, any attempt to modify a log would require compromising the gateway itself, which is protected by the same identity‑based controls that protect the agents.

Can I keep using my existing service‑account keys?

Yes. hoop.dev stores the keys it needs to talk to the backend, but the agents never receive them. The agents only need an OIDC token that hoop.dev can verify, preserving the principle of credential‑least‑exposure.

Will routing traffic through the gateway add noticeable latency?

The gateway operates at the protocol layer and adds only the processing time required for policy checks and logging. In most environments the added latency is measured in low‑single‑digit milliseconds, which is negligible compared to the round‑trip time to the backend.

Explore the open‑source repository on GitHub to see the code, contribute improvements, or fork the project for a custom deployment.