Running LangGraph without runtime guardrails invites audit failures and data leaks.
SOC 2 is a set of trust‑service criteria that auditors use to verify that a service provider protects customer data and operates with reliability. For a workflow engine like LangGraph, the standard translates into concrete expectations around access control, change management, logging, and data confidentiality. Auditors will look for evidence that every user who triggers a graph execution is properly authenticated, that the execution environment cannot be tampered with, and that any sensitive payloads are protected both in‑flight and at rest.
What SOC 2 expects from a runtime platform
The five criteria are Security, Availability, Processing Integrity, Confidentiality, and Privacy. They map to a handful of technical controls for LangGraph:
- Identity‑based access. Each request to start, pause, or modify a graph must be tied to a unique, verifiable identity. The system should enforce least‑privilege permissions and record the identity of every actor.
- Immutable audit trail. Every step in a graph, every input, and every output must be logged with timestamps, user identifiers, and success or failure status. The logs must be retained for the audit period.
- Just‑in‑time approvals. High‑risk operations, such as executing a graph that accesses external APIs or writes to a database, should be gated behind a manual or automated approval workflow.
- Data masking. When a graph returns personally identifiable information (PII) or secret tokens, the platform should redact those fields before they are stored in logs or displayed to downstream services.
- Session replay. Auditors often request the ability to reconstruct a graph execution to verify that no unauthorized steps were taken. The platform must capture enough context to replay the session.
Meeting these expectations is not a matter of configuring a single setting; it requires an integrated control surface that can observe every request, enforce policies, and generate the evidence auditors demand.
Where the evidence gaps appear
Many LangGraph deployments rely on static credentials stored in environment variables or secret managers that are read directly by the runtime. This approach satisfies the "credential exists" part of the security criterion but leaves three gaps:
- The runtime itself sees the secret, so a compromised process can exfiltrate it.
- There is no central point where approvals can be injected, so risky graph executions happen without oversight.
- Logs are written by the application code, which may omit user identifiers or fail to mask sensitive fields.
Because the control logic lives inside the same process that executes the graph, auditors cannot trust that the recorded evidence is complete or untampered. The missing piece is a gateway that sits outside the LangGraph process, intercepts traffic, and applies the required safeguards.
How hoop.dev fills the gap
hoop.dev is a Layer 7 gateway that proxies connections to infrastructure, including runtime environments like LangGraph. The gateway is deployed as a network‑resident agent, separate from the LangGraph process, and it becomes the sole path through which all graph‑execution requests travel.
When a user or an automated service initiates a LangGraph run, hoop.dev authenticates the request via OIDC or SAML, extracts the user’s group membership, and evaluates the request against policy. Because the gateway sits in the data path, it can enforce just‑in‑time approvals, block disallowed commands, and mask sensitive fields before they ever reach the LangGraph runtime.