When AI agents can read and write a company’s long‑term memory without oversight, the organization loses control over what knowledge is retained, who can influence it, and how it might be weaponized.
Shadow AI describes autonomous or semi‑autonomous models that act on data outside the visible governance layer, often persisting state in vector stores, document databases, or custom caches. Those models can generate new embeddings, update reference documents, or delete records based on internal heuristics that no human ever reviews.
Long‑term memory for AI typically lives in vector databases, object storage buckets, or specialized knowledge bases that keep embeddings and raw documents for future retrieval. The value of that memory grows over time, but so does the risk that an unchecked model silently reshapes it.
How shadow ai interacts with long‑term memory
Today many teams give an AI service a static API key that grants unlimited read/write access to the memory store. The key is baked into the container image, rotated rarely, and shared across multiple workloads. No request is logged centrally, no field is masked, and no human ever sees what the model is storing or retrieving. The result is a black‑box data pipeline that can leak PII, overwrite critical business knowledge, or insert malicious prompts that persist indefinitely.
What organizations really need is a way to bind every query to an identity, to redact or mask sensitive fields, and to require human approval for any write that could change the model’s knowledge base. Even with strong identity‑provider configuration and least‑privilege tokens, the request still travels directly to the database, bypassing any guardrails. The setup decides who can start a connection, but it does not enforce what happens once the connection reaches the memory store.
hoop.dev solves this by inserting a Layer 7 gateway between the AI agent and the memory store. The gateway authenticates the agent via OIDC, maps the identity to fine‑grained policies, and inspects each protocol message before it reaches the target. hoop.dev records each session for replay, masks fields that match compliance patterns, and can pause a write operation until a human reviewer approves it. Because the enforcement happens in the data path, the underlying store never sees an unauthenticated request.
With hoop.dev in place, every read from a vector database is logged with the caller’s user ID, the exact query vector, and the timestamp. If the response contains a field marked as sensitive, such as a social security number or an internal API key, hoop.dev replaces the value with a placeholder before it reaches the model. For write operations, hoop.dev evaluates the payload against policy rules; if the change would add new embeddings to a protected namespace, the gateway routes the request to an approval workflow and blocks execution until an authorized reviewer signs off.
These outcomes exist only because hoop.dev sits in the data path. The identity provider supplies the token, but without hoop.dev the token would be passed straight to the database, and no masking, no approval, and no session recording would occur. hoop.dev therefore provides the single control surface that turns a raw memory store into a governed knowledge vault.
Deploying the gateway is straightforward: the quick‑start guide shows how to run hoop.dev with Docker Compose, configure OIDC, and register a vector database as a connection. The same approach works for MongoDB, Redis, or any of the supported back‑ends. Once the gateway is running, existing client libraries, for example, the Python pinecone‑client or the JavaScript pgvector driver, can point to the local proxy address without code changes, preserving developer velocity while adding an effective enforcement layer.
FAQ
- Does hoop.dev store the data it proxies? No. The gateway only forwards traffic after applying policies. All records, masks, and approvals are kept in the audit store that the platform configures.
- Can I use hoop.dev with an existing vector database that already has IAM roles? Yes. hoop.dev can be configured to use the database’s native credentials while still enforcing identity‑aware policies at the gateway.
- What happens if a write is blocked? The request is returned with a clear error indicating that approval is required. The pending operation can be reviewed in the web console and approved or rejected by an authorized user.
For a hands‑on walkthrough, see the getting‑started guide. To explore the full set of features, visit the learn page. The project is open source; you can review the code, contribute improvements, or fork the repository on GitHub.
