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.
- 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.
How the data path changes for planner‑executor agents to generate compliance evidence
- Agent retrieves a static credential from a vault.
- Agent opens a direct TCP connection to the target.
- Target processes the request; any logs are kept locally.
- Agent authenticates to hoop.dev with an OIDC token.
- hoop.dev validates the token, then establishes its own credentialed connection to the target.
- All traffic flows through hoop.dev, where it can be recorded, masked, or paused for approval.
- 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.