A recently offboarded contractor still has a CI job that spins up a planner‑executor agent to provision test databases. The token used by that job was never revoked, and the agent continues to run privileged commands against production services. The organization now faces a classic FFIEC audit question: *who* did what, *when*, and whether any sensitive data was exposed.
Financial institutions that follow FFIEC guidance must prove that every automated action is traceable, that sensitive fields are never leaked, and that any out‑of‑policy operation receives documented approval. Most teams already federate identities with OIDC or SAML and assign least‑privilege roles to service accounts. Those steps answer “who may start” but they do not record what the planner‑executor actually does once the connection is established.
What is missing is a control point that sits on the data path, inspects each request, and captures immutable evidence. A Layer 7 gateway positioned between the planner‑executor and the target can enforce inline masking, block dangerous commands, route risky actions for human approval, and record every session for replay.
hoop.dev is the open‑source Layer 7 gateway that implements exactly this approach. By placing the gateway between users (engineers, AI agents, service accounts) and infrastructure, hoop.dev validates the OIDC token, then applies a policy engine before the request ever reaches the database, Kubernetes cluster, or SSH host.
FFIEC evidence requirements for automated agents
FFIEC’s technology risk management framework expects three categories of evidence for any automated workload:
- Access provenance: a log that ties each connection to a specific identity, including timestamps, source IP, and the exact credential used.
- Command‑level audit: a record of every statement or API call made by the agent, with the ability to replay the session for forensic analysis.
- Data protection controls: proof that sensitive fields (account numbers, SSNs, etc.) are masked in responses and that any attempt to retrieve them is either blocked or requires explicit approval.
Regulators also look for “just‑in‑time” (JIT) approvals that demonstrate a human reviewed high‑risk actions before they were executed. The evidence must be continuous, not a one‑off report generated after an audit window.
How hoop.dev generates the required ffiec evidence
hoop.dev is the only component that can guarantee these outcomes because it lives in the data path. When a planner‑executor initiates a connection, hoop.dev first validates the OIDC token, then applies a policy engine that:
- Records the session: hoop.dev writes a timestamped audit entry for every byte that crosses the gateway, creating a replayable transcript that ties actions to the originating identity.
- Applies inline masking: hoop.dev scans response payloads and redacts fields that match FFIEC‑defined sensitive patterns before they ever reach the agent.
- Enforces JIT approval: for commands flagged as high‑risk, hoop.dev pauses execution and routes the request to an approver. The approval decision, along with the approver’s identity, is stored alongside the session record.
- Blocks prohibited commands: hoop.dev can reject statements that match a deny list (for example, “DROP DATABASE” or “DELETE FROM accounts”) and log the block event.
Because hoop.dev owns the gateway, none of these safeguards can be bypassed by reconfiguring the planner‑executor or by altering the service‑account token. The enforcement outcomes exist only because hoop.dev sits between the identity and the resource.
Deploying hoop.dev for planner‑executor workloads
Getting started is straightforward. Deploy the gateway using the official Docker Compose quick‑start, which runs the agent close to the target infrastructure. Register each resource, whether a PostgreSQL instance, a Kubernetes cluster, or an SSH host, in the hoop.dev UI, and attach the credential that the planner‑executor will use. Configure OIDC authentication against your identity provider so that every request carries a verifiable token.
Once the gateway is live, update the planner‑executor’s connection string to point at the hoop.dev endpoint instead of the raw host. From that point forward, every command the agent issues passes through hoop.dev, which automatically records, masks, and applies JIT approvals according to the policies you define.
For detailed steps, follow the getting‑started guide. The learn section provides deeper examples of masking policies, approval workflows, and session replay.
FAQ
Does hoop.dev replace existing IAM roles?
No. IAM or service‑account roles still define *who may start* a connection. hoop.dev complements those roles by providing the enforcement layer that records *what actually happened*.
Can I use hoop.dev with multiple planners?
Yes. Each planner‑executor presents its own OIDC token, and hoop.dev evaluates the token against the configured policies, ensuring consistent evidence across all agents.
How long are session records retained?
Retention is a policy decision you make in your storage backend. hoop.dev simply writes the immutable audit trail; you can configure your log archive to meet FFIEC retention requirements.
By placing a Layer 7 gateway in front of planner‑executor agents, organizations can continuously generate the evidence FFIEC expects without retrofitting each script or job. hoop.dev provides the single control surface that turns raw command streams into auditable, masked, and approved actions.
Ready to see the code? Explore the open‑source repository on GitHub.
