When a vector store or other long‑term memory service streams raw embeddings across an internal network without protection, a single compromised host can harvest proprietary models, expose user data, and trigger costly compliance violations. Applying encryption in transit to that traffic eliminates the eavesdropping risk. The financial impact of a data leak often dwarfs the modest overhead of securing the same traffic with proper encryption.
Long‑term memory in modern applications refers to persistent stores that retain embeddings, document chunks, or inference results for future retrieval. These stores are typically accessed by microservices, batch jobs, or AI agents that need low‑latency reads and writes. Because the data is highly sensitive, often containing personally identifiable information or trade secrets, any exposure in transit is a direct threat to confidentiality and regulatory posture.
In many organizations the default pattern is a direct TCP connection from the application container to the memory service. Credentials are baked into environment variables, and the connection is assumed safe because it never leaves the corporate LAN. In practice, internal traffic can be intercepted by a malicious insider, a compromised host, or mis‑routed packets, and most deployments skip TLS verification to avoid the perceived operational friction.
This baseline state fixes the identity problem: the service authenticates the caller using a static secret. It does not, however, guarantee that the bytes traveling over the wire are encrypted, nor does it provide any visibility into who issued each query or whether the request complied with policy.
The missing piece is a control surface that sits on the data path. Only a gateway that intercepts every request can enforce TLS, validate certificates, and log the full session. Without such a data‑path enforcement point, the connection still reaches the memory store directly, leaving the organization without audit trails, without the ability to block insecure attempts, and without real‑time masking of sensitive fields.
hoop.dev fulfills that role. It acts as an identity‑aware proxy that sits between the requester and the long‑term memory endpoint. The gateway authenticates the user via OIDC or SAML, then proxies the protocol‑level traffic to the target service. Because the gateway is the only point where the traffic passes, it can require encryption, verify TLS certificates, and reject any attempt to communicate without a secure channel.
Setup: Organizations configure an OIDC identity provider (such as Okta or Azure AD) and grant hoop.dev read‑only access to group membership. This step determines who may initiate a connection but does not enforce encryption on its own.
The data path: hoop.dev runs a lightweight agent inside the same network segment as the memory store. All client connections are routed through the agent, which terminates the inbound TLS session, re‑establishes a validated TLS session to the backend, and inspects the payload at the wire‑protocol level.
Enforcement outcomes: hoop.dev encrypts every request and response, records the full session for replay, and can apply inline masking to remove sensitive fields before they are logged. Because the gateway controls the flow, it can also trigger just‑in‑time approval workflows for high‑risk queries, ensuring that privileged access is reviewed in real time.
By centralising encryption enforcement, organizations gain a single source of truth for traffic security, simplify compliance reporting, and reduce the blast radius of a compromised credential. The approach also scales: adding a new memory service only requires registering it with the gateway, without re‑architecting each client.
For a step‑by‑step walkthrough of deploying the gateway and connecting a vector store, see the getting‑started guide. The broader feature set, including session replay and policy‑driven masking, is documented in the learn portal.
Ready to try it yourself? The full source code and contribution guidelines are available on GitHub.
Why encryption in transit matters for long‑term memory
Long‑term memory services retain data that can be reverse‑engineered into user profiles or proprietary knowledge. When traffic is unencrypted, an attacker who gains network visibility can capture raw embeddings, reconstruct text, or infer model behaviour. Encryption in transit mitigates this risk by ensuring that every byte is scrambled until it reaches the trusted endpoint.
How a gateway enforces encryption in transit
The gateway terminates the inbound connection, validates that the client presented a valid TLS handshake, and then initiates a separate TLS session to the backend. Because the gateway controls both ends, it can reject any connection that fails validation, enforce strong cipher suites, and log the outcome of each handshake. The enforcement happens at the protocol layer, so applications do not need to be rewritten.
FAQ
Do I need to change my client libraries?
No. Clients continue to use their native drivers (e.g., the standard Python or Java SDK). The only change is the endpoint address, which now points to the gateway.
Can hoop.dev work with any vector store?
Yes. As long as the store speaks a supported wire protocol (for example, a PostgreSQL‑based vector extension or a proprietary HTTP API), the gateway can proxy the traffic and apply encryption enforcement.
What audit data does hoop.dev capture?
hoop.dev records each session, including timestamps, user identity, command payload, and the result of any masking or approval workflow. These logs can be exported to existing SIEM or compliance tools.
