Relying on point‑in‑time logs to prove ISO 27001 controls is a recipe for audit failure.
Most teams that expose an MCP gateway to LLMs or other AI agents treat the gateway as a simple pass‑through. The identity system authenticates the request, the gateway forwards traffic, and the backend service returns a response. When auditors ask for evidence of who accessed what, when, and whether any sensitive data was exposed, the answer is often “we have some logs, but they are incomplete, they lack command‑level detail, and they are stored on the same host that runs the service.” This creates a blind spot: the very point where policy should be enforced is the same place that can be altered or erased.
ISO 27001 requires evidence of access and control, and continuous, tamper‑evident logging helps satisfy that requirement. The standard’s Annex A.12.4 requires that “event logs be produced, kept and regularly reviewed.” In practice, organizations try to stitch together logs from the identity provider, the MCP gateway, and the target service. The stitching process is manual, error‑prone, and does not guarantee that every command or data element is captured.
One common pre‑condition is the deployment of an MCP gateway that authenticates via OIDC or SAML, then proxies requests to a database, an internal API, or a remote shell. This setup solves the identity problem but leaves the data path wide open. The request still reaches the target directly, with no central point that can enforce masking, block risky commands, or require an approval workflow. Without a gatekeeper that records every interaction, the organization cannot produce the granular evidence ISO 27001 expects.
Why iso 27001 evidence must be continuous
Continuous evidence means that every session, every command, and every response is captured at the moment it happens, not after the fact. For ISO 27001, this provides three critical benefits:
- It satisfies the audit requirement for immutable logs that can be reviewed at any time.
- It enables real‑time detection of policy violations, allowing the organization to stop a breach before data is exfiltrated.
- It reduces the operational overhead of manual log aggregation, because the evidence is already centralized.
Achieving this level of assurance requires a component that sits in the data path, not merely at the authentication layer.
hoop.dev as the data‑path enforcement point
hoop.dev is built to occupy exactly that position. It is a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH hosts, RDP sessions, and internal HTTP services. When an identity token is presented, hoop.dev validates it and then becomes the sole conduit for traffic to the target. Because all traffic passes through hoop.dev, it can apply enforcement outcomes directly.
hoop.dev records each session, capturing every command issued and every response returned. It masks sensitive fields in real time, ensuring that even if a response contains credit‑card numbers or personal identifiers, those values are never stored in clear text. It can block dangerous commands before they reach the backend, and it can route high‑risk operations to a human approver for just‑in‑time (JIT) approval. All of these actions happen inside the data path, making the evidence generated by hoop.dev both complete and trustworthy.