When an ISO 27001 audit asks for proof that no privileged agent can masquerade as another user, the evidence package should include immutable session recordings, per‑command approval trails, and masked output that hides credential material. The auditor should be able to trace every privileged request back to an authenticated identity, see who approved it, and verify that sensitive data never left the controlled environment.
Why the current practice falls short
Many organizations still rely on shared SSH keys, static service‑account passwords, or long‑lived API tokens that are copied between engineers and automation jobs. Those credentials are often stored in plaintext files or password managers and then injected directly into scripts. The result is a world where any holder of the secret can impersonate any other holder, execute commands without visibility, and exfiltrate secrets without leaving a trace. Auditors who examine log files will find gaps: no record of who actually ran a command, no indication that a secret was displayed, and no way to prove that a privileged action was reviewed before execution.
What identity alone does not solve
Moving to OIDC or SAML‑based identities is a necessary first step. It lets you assign each engineer a unique token, enforce least‑privilege roles, and revoke access centrally. However, the token only proves who started a connection; the request still travels straight to the target host or database. Without a control point on the data path, the connection can issue any command, read any field, and the downstream system continues to log only what it natively records – typically a generic user name and timestamp. No inline masking, no just-in-time approval, and no session replay are added. In other words, identity solves "who may start," but it does not provide the "what happened" evidence required by ISO 27001 Annex A.12.4 (logging) or A.9.2 (user access provisioning).
hoop.dev as the enforcement layer
hoop.dev is a Layer 7 gateway that sits between the authenticated identity and the target infrastructure. By placing the gateway in the data path, hoop.dev can inspect every protocol packet, apply policy, and produce immutable artifacts. Specifically, hoop.dev:
- Records each agent session, creating a replayable log that ties every command to the original OIDC token.
- Masks sensitive response fields in real time, ensuring that secrets never appear in plain text on the client side.
- Requires just-in-time human approval for risky commands, storing the approver’s identity and timestamp alongside the command.
- Blocks disallowed commands before they reach the backend, preventing accidental or malicious misuse.
- Keeps audit records separate from the target host, preventing the target from altering them.
Because hoop.dev is the only component that can enforce these controls, the resulting artifacts become the primary evidence you hand to an auditor. The audit trail shows exactly which identity initiated a session, which commands were executed, which ones required approval, and which data fields were redacted. This satisfies the ISO 27001 control objectives for access control, monitoring, and protection of log information.
Mapping hoop.dev artifacts to ISO 27001 clauses
A.9.2 – User access provisioning: hoop.dev’s integration with OIDC ensures that only users with a valid token can start a session. The gateway logs the token’s claims, providing a verifiable record of who was granted access at the moment of connection.