When auditors request soc 2 evidence for a long‑term memory system, they expect a complete audit trail that shows who accessed what data, when, and under what approval.
Why long‑term memory is a compliance blind spot
Most teams treat long‑term memory as a simple key‑value store that an application reads and writes directly. The usual pattern is a shared credential embedded in code or a static service account that has unrestricted read/write rights. Engineers, automated jobs, and even experimental AI agents can reach the store without any visibility into the exact queries they issue. The result is a data lake where every write is possible, but no one can prove which piece of data was retrieved, altered, or exposed at any point in time.
What soc 2 actually asks for
soc 2 focuses on five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. For a long‑term memory service the most relevant artifacts are:
- Evidence that every access request is tied to an authenticated identity.
- Logs that capture the full request and response payloads, or at least the fields that are considered sensitive.
- Records of any manual approvals that were required before a privileged operation could proceed.
- Proof that sensitive data is masked or redacted in logs and in downstream responses.
- Retention of these logs for the period defined by your audit policy.
Many organizations already have the first piece in place – an identity provider that issues OIDC or SAML tokens. They also often deploy just‑in‑time (JIT) access controls that grant a short‑lived role before a request reaches the memory store. What is missing is a single enforcement point that can capture the request, apply masking, enforce approvals, and preserve the session for later replay.
Introducing a data‑path gateway
Placing a Layer 7 gateway between the authenticated identity and the long‑term memory backend solves the missing piece. The gateway sits on the network, receives the user’s request, inspects the wire‑protocol, and then forwards the traffic to the memory store only after applying the configured guardrails.
How the gateway creates soc 2 evidence
hoop.dev records each session in an audit log that is stored separately from the client and the backend, ensuring the recorded data is protected from alteration by either side. Every query, response, and metadata element is stored with the identity that originated it, the timestamp, and the outcome of any policy checks.
When a request contains fields marked as sensitive, hoop.dev masks those fields in the response before they are written to the audit log or returned to the caller. This satisfies the confidentiality criterion without requiring the application to implement its own redaction logic.
If a request attempts an operation that exceeds the caller’s baseline permissions, hoop.dev can pause the flow and route the request to a human approver. The approval decision – grant or deny – is recorded alongside the original request, providing the manual‑approval evidence that soc 2 auditors look for.
Mapping gateway capabilities to the trust service criteria
- Security: hoop.dev mediates all access with authenticated tokens and enforces least‑privilege policies before any command reaches the memory store.
- Processing integrity: The gateway validates that each request conforms to the expected protocol, blocking malformed or potentially harmful commands.
- Confidentiality: Inline masking ensures that personally identifiable information never appears in logs or in downstream systems unless explicitly allowed.
- Availability: Because the gateway runs as a resilient service, it can be scaled and monitored independently of the memory backend, providing a clear point for health checks and incident response.
- Privacy: The combination of identity‑bound logs, masking, and controlled approvals gives a demonstrable audit trail for any data‑subject request.
Getting started with the gateway
Deploy the gateway using the official Docker Compose quick‑start, or run it in Kubernetes for production workloads. Connect your identity provider (Okta, Azure AD, Google Workspace, etc.) so the gateway can verify OIDC or SAML tokens. Register the long‑term memory service as a connection, providing the backend credentials that the gateway will use – the callers never see those secrets.
For step‑by‑step instructions, see the getting‑started guide. The learn section contains deeper explanations of session recording, inline masking, and just‑in‑time approval workflows.
FAQ
Do I need to change my application code?
No. The gateway speaks the native protocol of the memory store (e.g., Redis, PostgreSQL). Your application continues to use its existing client library; the only change is the network endpoint it points to.
How long are audit logs retained?
Retention is configured in the gateway’s storage backend. You can align the policy with your organization’s soc 2 evidence retention schedule, typically one to three years.
Can I still use existing IAM roles for the backend?
Yes. The gateway holds the credential that the backend expects. Your existing role‑based access model remains, but the gateway adds an additional layer of visibility and control.
Take the next step
Explore the open‑source repository, review the implementation details, and start building a compliant audit trail for your long‑term memory system: github.com/hoophq/hoop.
