When an iso 27001 audit asks for proof that every LLM query is controlled, the ideal artifact is an audit log that shows exactly which user supplied which prompt, what data was returned, and which parts were masked or redacted. With those records in hand, auditors can verify that the organization enforces confidentiality, integrity, and access‑control policies for the most sensitive part of the AI workflow – the context window.
That level of evidence also satisfies the requirement to demonstrate that data‑processing activities are auditable and that any exposure of personal or proprietary information is detected and mitigated in real time. In practice, teams often fall short of this ideal.
Why context windows matter for iso 27001
Context windows are the slice of text that an LLM sees when it generates a response. They commonly contain raw business data, customer PII, or internal code snippets. Because the window is sent in clear text to the model provider, a breach or accidental leakage can instantly violate confidentiality clauses in iso 27001 Annex A. Moreover, the window determines the model’s output, so any manipulation of the prompt can affect downstream decisions, creating integrity risks.
Auditors therefore look for three artifacts: a record of who initiated the request, a snapshot of the exact prompt sent, and evidence that any sensitive fields were masked before leaving the organization’s boundary.
The missing controls in a direct LLM integration
Most engineering teams connect to LLM APIs with a shared service account key. The key lives in a CI/CD secret store, is checked out by developers, and is used by scripts that call the provider’s endpoint directly. This approach has several gaps:
- There is no central point where the request can be inspected, so the organization cannot enforce masking or approval policies.
- Session data is stored only in the provider’s logs, which the organization cannot guarantee integrity or retention.
- Because the credential is static, any compromise grants unlimited access to every downstream context window.
Even if the team adopts short‑lived tokens for the API, the token validation happens upstream of the actual data flow. The request still reaches the LLM service without a gate that can record the exact prompt or apply inline redaction. In iso 27001 terms, the control objective of “secure logging and monitoring of privileged actions” remains unmet.
Putting hoop.dev in the data path
hoop.dev is a layer‑7 gateway that sits between identities and the LLM endpoint. It receives the user’s request, validates the OIDC token, and then forwards the call to the model provider. Because the gateway operates at the protocol level, it can enforce the missing controls without changing existing client code.
When a request arrives, hoop.dev performs three enforcement actions:
- Inline masking – before the prompt is sent, hoop.dev scans for patterns that match configured sensitive fields (such as credit‑card numbers or internal identifiers) and replaces them with placeholders. This ensures that only sanitized data reaches the external model.
- Just‑in‑time approval – for prompts that exceed a risk threshold (for example, containing more than a certain number of PII tokens), hoop.dev routes the request to a human approver. The approver’s decision is recorded alongside the request.
- Session recording – hoop.dev logs the authenticated user, the original prompt, the masked version, and the model’s response. The log entry is recorded and retained according to the organization’s retention policy, providing the audit trail required by iso 27001.
All three outcomes exist only because hoop.dev sits in the data path. The initial identity verification (the setup) decides who may start the request, but without the gateway there would be no place to apply masking, approval, or recording.
What auditors will see
After deploying hoop.dev, the evidence package for an iso 27001 audit includes:
- A searchable log that correlates each user’s identity with the exact context window they submitted.
- Masked‑prompt snapshots that demonstrate the organization’s data‑loss‑prevention controls.
- Approval records that show a documented decision process for high‑risk queries.
- Retention policies configured in hoop.dev that guarantee logs are kept for the required period.
Because the logs are generated by hoop.dev, the organization can attest that the records were produced outside the LLM client process, satisfying the “independent review” requirement of iso 27001. The logs can be exported to a SIEM or a compliance‑reporting tool for further analysis.
Getting started
To adopt this approach, begin with the Getting started guide to deploy the gateway in your network. The guide walks you through configuring OIDC authentication, defining masking rules, and enabling just‑in‑time approvals. For deeper details on how each feature works, see the learn page. The open‑source repository on GitHub provides the full implementation and example configurations: Explore the open‑source repository on GitHub.
FAQ
Do I need to change my existing LLM client code?
No. hoop.dev works as a transparent proxy. Your existing client points at the gateway endpoint instead of the provider’s URL, and the rest of the workflow remains unchanged.
Can I use hoop.dev with any LLM provider?
hoop.dev supports any HTTP‑based LLM API. You configure the target endpoint and the gateway handles the rest, including masking and logging.
How does hoop.dev help me meet iso 27001’s logging requirements?
hoop.dev records every request and response in a log that includes the authenticated user, the original context window, and any masking or approval actions. Those logs constitute the evidence auditors require for secure logging and monitoring.
