AI agents that run unrestricted SQL against production Postgres instances can expose banks to massive regulatory risk.
The FFIEC expects every database interaction to be traceable, that sensitive fields be protected, and that privileged work be granted only for a narrowly defined window. When an autonomous agent connects directly to a database, the organization loses the ability to prove who asked for what, when, and whether the response contained protected data.
Meeting FFIEC’s audit‑ready mandate therefore requires three core capabilities: immutable, per‑user session logs; real‑time masking of personally identifiable information; and just‑in‑time (JIT) approval workflows that enforce the principle of least privilege. Identity providers can tell the gateway who the request originates from, but without a data‑path enforcement point the request still reaches the database unchecked, leaving the audit trail incomplete and masking unavailable.
FFIEC requirements for database access
The Federal Financial Institutions Examination Council (FFIEC) outlines a set of controls for any system that stores or processes customer data. For relational databases the key expectations are:
- Comprehensive audit logs: each query must be recorded with the user or service identity, timestamp, and outcome. The logs are stored securely and retained according to your retention policy.
- Data protection at rest and in transit: any response that contains regulated fields (SSN, account numbers, etc.) must be masked or redacted for users who lack the appropriate clearance.
- Just‑in‑time privileged access: elevated permissions (e.g., superuser or read‑write on sensitive tables) must be granted only after an explicit, time‑bounded approval.
- Separation of duties: the entity that approves a request cannot be the same that executes it, preventing a single point of compromise.
These controls are not optional; auditors will request concrete evidence that each of them was enforced for every database session.
Why a data‑path gateway is essential
Identity federation (OIDC, SAML) tells the system *who* is making a request, but it does not dictate *what* the request can do once it reaches the database. If the connection is made directly from the AI agent to Postgres, the database sees only a standard client connection and cannot apply the FFIEC guardrails.
The missing piece is a gateway that sits on Layer 7, intercepting the wire‑protocol traffic before it hits the target. By placing enforcement in the data path, the organization can:
- Inject masking logic into every response, ensuring regulated fields never leave the gateway unfiltered.
- Log each command with full context, tying it back to the originating identity.
- Pause risky statements and route them to an approver, enforcing JIT access.
- Record the entire session for replay, giving auditors a verifiable playback of what occurred.
Without that gateway, the best‑case scenario is a set of logs generated by the database itself, which lack the granularity and policy enforcement the FFIEC demands.
How hoop.dev satisfies the FFIEC control set
hoop.dev implements the exact data‑path enforcement point described above. It sits between AI agents (or any service account) and PostgreSQL, acting as an identity‑aware proxy that applies guardrails on every query.
- Session recording: hoop.dev captures each request and response, storing a replay‑able log that includes the user’s OIDC token claims. Auditors can retrieve these logs to demonstrate compliance.
- Inline data masking: before a response leaves the gateway, hoop.dev can redact or replace regulated fields based on policy rules, ensuring that downstream consumers only see what they are permitted to see.
- Just‑in‑time approval workflow: when a query matches a high‑risk pattern (e.g., a DROP TABLE or a SELECT on a PII‑heavy table), hoop.dev pauses execution and routes the request to a human approver. The approval is time‑boxed, and the gateway automatically revokes the privilege after the window expires.
- Separation of duties enforced by design: the approval UI is separate from the agent that initiates the request, satisfying the FFIEC separation requirement.
Because hoop.dev is open source and MIT‑licensed, organizations can inspect the code, extend policies, and host the gateway in their own network, keeping the audit trail under their control.
Getting started with hoop.dev for FFIEC‑ready AI agents
To begin, deploy the gateway using the official getting started guide. The quick‑start Docker Compose file provisions an OIDC‑enabled gateway and a network‑resident agent that will hold the PostgreSQL credentials. Once deployed, register the Postgres target in the hoop.dev UI, define masking rules for regulated columns, and configure the JIT approval policy for privileged statements.
For deeper policy examples and best‑practice recommendations, see the learn section of the documentation.
After configuration, AI agents connect to the gateway using their normal PostgreSQL client libraries. The gateway transparently enforces the policies you defined, while the agents remain unaware of the underlying controls.
FAQ
Does hoop.dev replace the need for database‑level auditing?
No. hoop.dev complements native database logs by adding policy enforcement, masking, and replay capabilities that the FFIEC specifically requires. Together they provide a complete audit trail.
Yes. Because hoop.dev works at the protocol level, any client that can speak PostgreSQL over TCP can be routed through the gateway without code changes.
Is the audit data stored securely?
hoop.dev stores session logs in a location you configure, and the logs are immutable by design. The storage backend is chosen by the operator, allowing you to meet any retention or protection policy.
Explore the open‑source repository on GitHub for detailed implementation notes and contribution guidelines.
