A recently off‑boarded contractor left a vector database full of customer PII that the organization still queries in production. When the regulator’s audit team arrived, the first request was: “Show us who accessed that data, when, and whether any sensitive fields were exposed.” The answer depended on whether the long‑term memory layer could produce verifiable evidence that met FFIEC expectations.
What FFIEC expects from a long‑term memory store
FFIEC guidance treats persistent AI memory as a data repository that must be governed like any other sensitive database. Auditors look for:
- Identity‑bound access records that prove who queried the store and under what authority.
- Real‑time masking of regulated fields so that even authorized users cannot see raw PII unless explicitly permitted.
- Just‑in‑time (JIT) approval workflows for high‑risk queries, providing a documented decision trail.
- Immutable session recordings that can be replayed to verify that the query behaved as approved.
These artifacts together form the evidence package that satisfies the FFIEC requirement for “controlled access and accountability” for persistent AI memory.
Why traditional setups miss the mark
Most teams treat a long‑term memory store like any other database. They provision a static credential, embed it in application code, and let every service call the store directly. This approach creates three critical gaps.
1. No central enforcement point. The credential gives the caller unrestricted access to the underlying data. Even when the organization adopts OIDC or SAML for user authentication, the request still travels straight to the memory store, bypassing any gate that could enforce masking or approval.
2. Auditing is an after‑thought. Without a dedicated proxy, logs are limited to connection timestamps. They do not capture which columns were returned, whether a query was blocked, or who approved an exception. The audit trail is therefore incomplete for FFIEC.
3. Sensitive fields leak silently. Inline data masking is rarely baked into the database driver. If a user runs a query that returns a Social Security number, the raw value is sent back to the client before any policy can intervene.
These shortcomings mean that, even with a strong identity foundation, the organization cannot prove compliance with FFIEC’s “evidence of controlled access” requirement.
hoop.dev as the enforcement layer
hoop.dev provides a Layer 7 gateway that sits between the authenticated identity and the long‑term memory store. By placing enforcement in the data path, hoop.dev becomes the sole source of the audit evidence FFIEC demands.
When a request reaches the gateway, hoop.dev records the full session, including the user’s identity, the exact query text, and the timestamp. If the query attempts to retrieve regulated fields, hoop.dev masks those fields in real time, ensuring that the response never contains raw PII unless an explicit exception is granted.
For high‑risk queries, hoop.dev triggers a just‑in‑time approval workflow. The request is paused, a designated approver is notified, and the decision, approve or deny, is logged alongside the original request. Only after approval does hoop.dev forward the query to the memory store.
All of these actions, session recording, inline masking, JIT approval, are performed by hoop.dev because it is the only component that intercepts traffic on the way to the target. The underlying credential remains hidden inside the gateway, so the downstream service never sees it.
How hoop.dev’s artifacts satisfy FFIEC
Because hoop.dev sits in the data path, the evidence it produces aligns directly with FFIEC’s checklist:
- Identity‑bound logs: Every access record includes the user’s OIDC token claims, proving who performed the operation.
- Masked data evidence: The logs capture both the original query and the masked response, demonstrating that regulated fields were protected.
- Approval workflow records: Each JIT decision is stored with the approver’s identity, timestamp, and justification, creating a recorded approval trail.
- Replayable sessions: Recorded sessions can be replayed in a sandbox to verify that the observed behavior matches the documented policy.
When an auditor requests proof, the organization can export the relevant session logs, masking logs, and approval records from hoop.dev. The export is a single, coherent package that demonstrates compliance without having to piece together logs from multiple systems.
Getting started with hoop.dev
Deploying the gateway is straightforward. The open‑source project can be run via Docker Compose for a quick trial, or installed in Kubernetes for production workloads. The official getting‑started guide walks through the deployment steps, while the learn site contains deeper explanations of masking policies, approval flows, and session replay.
Because hoop.dev is MIT‑licensed, organizations retain full control over the source code and can audit the implementation themselves. For those who prefer to explore the codebase directly, the repository is available on GitHub: View the hoop.dev source on GitHub.
FAQ
Does hoop.dev replace the underlying database?
No. hoop.dev acts as a proxy that forwards authorized queries to the existing long‑term memory store. The database remains unchanged; hoop.dev only intercepts traffic.
Can existing OIDC providers be used?
Yes. hoop.dev validates OIDC or SAML tokens from any compliant identity provider, extracting group membership to drive its access policies.
How long are session recordings retained?
Retention is configurable in the deployment settings. Organizations can align the retention period with their internal data‑retention policies and FFIEC guidance.
