In many organizations, engineers still reach production servers with a shared SSH private key that lives in a repository, or they use a static database credential that multiple services embed in code. Those secrets grant standing access, bypass any approval workflow, and leave no reliable record of who ran which command. When a breach occurs, the audit logs are either missing or scattered across disparate systems, making it impossible to prove compliance with ISO 27001 requirements.
Some teams have added an identity provider such as Okta or Azure AD to authenticate users before they obtain a token. The token proves who the user is, but the token is handed off to the same shared credential and the connection still goes directly to the target host. The request now carries an identity, yet the traffic still flows unchecked: there is no real‑time approval, no command‑level audit, and no masking of sensitive data that might appear in query results.
hoop.dev resolves this gap by inserting a Layer 7 gateway between the authenticated identity and the infrastructure endpoint. The gateway becomes the only path for traffic, allowing it to enforce approval, record every command, mask regulated fields, and capture a replayable session. By doing so, hoop.dev generates the concrete artifacts ISO 27001 auditors demand.
What auditors expect for task‑level evidence
ISO 27001 Annex A.12.4 requires organizations to record user activity on information processing facilities. For task decomposition, the standard translates into three concrete deliverables:
- Access request and approval logs that show the exact moment a user or automated agent was granted permission to run a specific task.
- Command‑level audit trails that capture every statement, query, or shell instruction executed as part of the task.
- Data‑handling proof that demonstrates any personally identifiable information (PII) or secrets were masked or redacted before leaving the system.
These artifacts must be immutable, time‑stamped, and tied to the identity that initiated the request. Without a single point that enforces and records these controls, teams end up stitching together logs from IAM, database audit, and SSH history, which rarely satisfies a rigorous ISO reviewer.
Why a data‑path gateway is required
The three artifacts above share a common prerequisite: they all need the system to generate them at the moment traffic flows between the identity and the target resource. Identity providers (Okta, Azure AD, etc.) can authenticate the user, but they cannot see the SQL statement that a developer runs or the keystrokes typed over SSH. Likewise, a database’s native audit can log queries, but it cannot enforce a pre‑execution approval workflow.
Placing enforcement in the data path solves the problem. The gateway sits between the authenticated identity and the infrastructure endpoint, so it can:
- Intercept the request, check it against a policy, and pause for human approval if the task is deemed risky.
- Record the exact command stream for later replay, tying each line to the requesting identity.
- Apply inline masking to any response that contains regulated fields, ensuring that logs never expose raw PII.
Because the gateway controls the only path to the resource, the audit trail is complete and cannot be altered without changing the gateway itself.
How hoop.dev delivers audit‑ready artifacts
hoop.dev implements the data‑path model described above. It authenticates users via OIDC or SAML, reads group membership, and then proxies the connection to the target, whether that is a PostgreSQL database, an SSH host, or a Kubernetes API server. While the traffic passes through the gateway, hoop.dev applies four enforcement outcomes that map directly to ISO 27001 evidence requirements:
- Just‑in‑time approval: Before a high‑risk task runs, hoop.dev can route the request to an approver. The approval decision is recorded with a timestamp and the identity of the approver.
- Command‑level audit: Every statement sent to the backend is logged. The log entry includes the user’s identity, the exact command text, and the time it was executed.
- Inline data masking: Responses that contain regulated fields are automatically redacted before they reach the client or are written to logs, satisfying data‑handling controls.
- Session recording and replay: The entire interaction, handshake, commands, and responses, is captured as a replayable session. Auditors can play back a task to verify that the approved workflow was followed.
hoop.dev itself generates all of these artifacts, not downstream services. Because the gateway is the sole conduit, teams can export the logs, approval records, and session files to the location required by their ISO 27001 audit process.
Getting started is straightforward. Follow the getting‑started guide to deploy the gateway, configure OIDC authentication, and register a task‑level resource. The learn section provides deeper explanations of each enforcement feature and how they map to compliance controls.
FAQ
Does hoop.dev replace existing database or SSH audit logs?
No. hoop.dev complements native logs by providing a single, immutable source of truth for the exact traffic that passed through the gateway. Auditors can still reference native logs, but hoop.dev’s records satisfy the “complete audit trail” requirement of ISO 27001.
Can I use hoop.dev with existing identity providers?
Yes. hoop.dev acts as an OIDC/SAML relying party, so any provider that issues standard tokens, Okta, Azure AD, Google Workspace, etc., works out of the box.
What happens to masked data in the audit logs?
hoop.dev redacts masked fields before writing them to the audit store, ensuring that logs never expose raw PII while still proving that the masking step occurred.
Ready to see the code that makes this possible? Explore the open‑source repository on GitHub and start building ISO 27001‑ready evidence for your task‑decomposition workflows.
