When an ISO 27001 audit is complete, the auditor can walk away with a complete, verifiable trail that shows exactly who accessed LangGraph, what they did, and that any sensitive data was protected at the moment it left the system.
Why iso 27001 matters for LangGraph
ISO 27001 requires organizations to demonstrate that information security controls are not only defined but also consistently applied and evidence‑based. For a platform like LangGraph, which orchestrates data flows between LLMs and downstream services, the standard translates into three practical expectations: control over who can invoke a graph, proof that each invocation was authorized, and assurance that any personal or confidential payloads were handled according to policy.
Current practice and its gaps
In many teams, engineers reach LangGraph using a shared service account token that lives in a configuration file or CI secret store. The token grants broad, standing access to every graph endpoint, and there is no per‑invocation approval step. Because the request travels directly from the client to the LangGraph service, the platform itself sees only the raw HTTP call; no intermediate component records the request, masks data, or forces a review. The result is a black box for auditors: they can see that a token exists, but they cannot prove which user exercised it, whether the payload contained regulated data, or if any policy was enforced at runtime.
What iso 27001 actually demands from a data‑processing service
The standard’s Annex A controls require documented evidence of access control, monitoring, and data protection. Specifically, A.9.2.3 calls for “review of user access rights at regular intervals,” while A.12.4.1 expects “event logging to be performed and retained.” A.14.1.2 adds the need for “secure development and configuration management” that includes “protecting data in transit and at rest.” For LangGraph, this means the organization must be able to produce logs that tie a specific identity to each graph execution, show any manual or automated approval that preceded the execution, and demonstrate that any sensitive fields were redacted before they left the system.
How hoop.dev creates the required audit artifacts
hoop.dev is positioned as a Layer 7 gateway that sits between identities and the LangGraph endpoint. All client traffic is forced through this gateway, making it the only place where enforcement can occur. By inserting hoop.dev into the data path, the platform gains three essential capabilities that satisfy iso 27001 evidence requirements.
Session recording for traceability
hoop.dev records each request and response pair, attaching the verified identity from the OIDC token to the log entry. The recorded session includes timestamps, the exact GraphQL query, and the HTTP status returned. Because the recording happens at the gateway, the LangGraph service never sees the raw credentials; the audit trail is therefore tamper evident and can be presented directly to the auditor.
Inline masking to protect personal data
When a response contains fields marked as sensitive, such as user email, social security number, or credit‑card token, hoop.dev can mask or redact those values before they reach the client. The masking policy is defined centrally and applied in real time, ensuring that any downstream logs or screenshots do not expose regulated data. The original value is never stored in the audit log, satisfying the data‑protection clause of iso 27001.
Just in time access and approval workflow
Before a request is forwarded, hoop.dev can require an approval step based on the requested operation. For example, a request that writes to a production graph may be held for a manager’s sign‑off. The approval decision, the approver’s identity, and the time of approval are all recorded alongside the session. This creates a clear, auditable chain of custody for privileged actions, directly addressing the “access review” control in iso 27001.
Putting it together for an auditor
When an auditor asks for evidence, the organization can export the session logs from hoop.dev, filter them by date range, and correlate them with the identity provider’s user directory. The exported package includes:
- A chronological list of every LangGraph invocation, with the initiating user’s name and role.
- Approval records for any privileged executions, showing who granted permission and when.
- Masked response payloads that demonstrate compliance with data‑privacy policies.
- Metadata that ties each log entry to the underlying OIDC token, proving that authentication was performed at the gateway.
Because the gateway is the sole enforcement point, the evidence is complete and cannot be contested by the LangGraph service itself. The organization can therefore demonstrate continuous compliance with iso 27001 without having to instrument the application code.
Getting started
Deploy the gateway using the official getting‑started guide, configure an OIDC connection to your identity provider, and register the LangGraph endpoint as a protected resource. The learn section provides detailed explanations of masking policies, approval workflows, and audit‑log export formats.
FAQ
- Can I use hoop.dev with an existing LangGraph deployment? Yes. The gateway works as a reverse proxy, so you only need to point your client’s base URL at hoop.dev while leaving the LangGraph service unchanged.
- Does hoop.dev replace my identity provider? No. hoop.dev consumes OIDC or SAML tokens from your existing IdP and uses the embedded claims to enforce policies.
- How long are the session records retained? Retention is configurable in the gateway’s policy store; you can align it with your organization’s iso 27001 retention schedule.
Ready to see the evidence in action? Explore the open‑source code and contribute on GitHub: https://github.com/hoophq/hoop.
