How can you protect a long-term memory system when the actors accessing it are bots, services, or AI agents using a non-human identity? The challenge is ensuring that a non-human identity cannot overstep its bounds.
Long-term memory stores user conversations, embeddings, and other data that can be highly sensitive. In many organizations the only way these automated workloads reach the store is with a static credential that lives in configuration files, CI pipelines, or container images. The credential is shared across many services, rarely rotated, and never tied to an individual user. Because the connection is direct, there is little visibility into who queried the memory, what was returned, or whether a response contained personally identifiable information.
This unsanitized state is common: a service account is created once, granted broad read/write rights on the memory database, and then handed to every microservice that needs it. The account is used for weeks or months without any per-request review. Auditors cannot answer basic questions about which AI agent accessed a specific record, and developers cannot enforce data-redaction policies on the fly.
Why non-human identity matters for long-term memory
Switching to non-human identities, service accounts, AI-issued tokens, or federated identities, solves the first problem. The identity is now managed in a central IdP, can be rotated programmatically, and can carry group membership that reflects the purpose of the workload. However, merely issuing a non-human identity does not close the security gap. The request still travels straight to the memory store, bypassing any runtime guardrails. There is still no way to:
- Inspect the query before it reaches the database.
- Mask fields that should never leave the system in clear text.
- Require a human to approve a write that could corrupt the knowledge base.
- Record the full session for later replay or forensic analysis.
In other words, the setup decides who the request is, but it does not enforce what the request may do.
Placing enforcement in the data path
To gain control, the enforcement point must sit on the data path between the identity and the long-term memory target. This is where policies can be applied consistently, regardless of which service or AI agent initiates the connection. The gateway that occupies this position inspects the wire-protocol, applies masking rules, blocks disallowed commands, and logs every interaction.
How hoop.dev provides the required data-path gateway
hoop.dev is built exactly for this role. It acts as an identity-aware proxy that sits between non-human identities and the memory database. When a service presents an OIDC token, hoop.dev validates the token against the IdP, extracts the group claims, and then decides whether the request is allowed. Because hoop.dev is the only component that sees the traffic, it can:
- Mask sensitive fields in query results, ensuring that downstream services never receive raw personal data.
- Require just-in-time approval for write operations that could alter the knowledge base.
- Block dangerous commands such as bulk deletes or schema changes before they reach the database.
- Record each session, providing a replayable audit trail that can be queried later.
All of these enforcement outcomes exist only because hoop.dev sits in the data path. Without the gateway, the non-human identity would communicate directly with the memory store, and none of the above controls would be enforceable.
Practical steps to protect long-term memory with non-human identity
Below is a high-level workflow that teams can follow. Detailed configuration instructions are available in the getting-started guide and the broader learn section.
- Define the non-human identity in your IdP. Create a service account or AI-issued client, assign it to a group that reflects the workload’s purpose, and enable short-lived token issuance.
- Register the long-term memory target with hoop.dev. Provide the connection details (host, port, and the credential hoop.dev will use). The credential is stored only inside the gateway; the service never sees it.
- Configure masking policies. Identify fields such as user_id, email, or session_token that must be redacted. hoop.dev will replace those values in responses before they reach the caller.
- Enable just-in-time approval for write actions. Define a policy that routes any INSERT, UPDATE, or DELETE to an approver workflow. The request pauses at hoop.dev until a human authorizes it.
- Activate session recording. Turn on the audit log for the connection. hoop.dev will store a replayable record of every query and response, satisfying compliance and forensic needs.
- Test the end-to-end flow. Use a standard client (for example, the language-specific SDK or a CLI) to issue a read request. Verify that the response is masked and that the session appears in the audit UI.
Because hoop.dev handles the enforcement, you retain the flexibility to rotate the underlying credential without touching the services, and you gain visibility into every automated access.
FAQ
What is a non-human identity?A non-human identity is an authentication principal that represents a service, bot, or AI agent rather than a person. It is typically issued by an IdP as a client credential or short-lived token.How does hoop.dev enforce policies for AI agents?hoop.dev validates the AI agent’s token, then inspects each request at the protocol level. It can mask fields, require approval, or block commands before they reach the memory store.Can I audit past accesses that occurred before hoop.dev was deployed?hoop.dev can only record sessions that pass through its gateway. For historical data you would need to rely on whatever logging the memory store already provides.
By moving the enforcement point to the data path and leveraging non-human identities, teams can secure long-term memory workloads without sacrificing automation.
Explore the open-source implementation and contribute on GitHub: https://github.com/hoophq/hoop
