When auditors verify iso 27001 compliance, they expect an immutable record of every nested‑agent session, showing who started the chain, which commands ran, and that any sensitive data was concealed. The evidence must prove that access was granted just‑in‑time and approved where required.
Today many teams launch inner agents with long‑lived service‑account keys embedded in scripts or images. The outer agent authenticates once, then the inner agents inherit the same credential and connect directly to databases, Kubernetes clusters, or SSH hosts, bypassing any central checkpoint.
Adopting short‑lived, non‑human identities and least‑privilege roles is a necessary improvement. Yet without a gateway that inspects traffic, the request still reaches the target unmediated: there is no per‑command audit, no real‑time masking, and no ability to pause a risky operation for manual approval.
The missing piece is a data‑path enforcement point that can observe every request, apply policy, and produce immutable logs. Without such a proxy, the chain remains invisible to auditors and cannot satisfy iso 27001’s evidence requirements.
How hoop.dev creates iso 27001 evidence
hoop.dev sits in the data path between the identity provider and the target system. Every nested‑agent connection is proxied through the gateway, so the gateway becomes the only place where enforcement can be applied.
When a user or automated process presents an OIDC token, hoop.dev validates the token, extracts the non‑human identity, and checks the associated least‑privilege role. Because the request must travel through hoop.dev, the platform can record the exact command, the full response payload, and the identity that initiated it. hoop.dev records each session in a log that auditors can query.
If a command matches a risky pattern, hoop.dev blocks it before it reaches the backend. For operations that require human sign‑off, hoop.dev routes the request to an approval workflow and only forwards it after an authorized reviewer approves. Sensitive fields such as credit‑card numbers or personal identifiers are masked in the response stream by hoop.dev, ensuring that the recorded audit trail never contains raw PII.
All of these enforcement outcomes exist because hoop.dev occupies the data path; the underlying setup, OIDC identity, service‑account roles, and network placement, only determines who may start a session. The gateway is the place where masking, approval, blocking, and recording happen.
The surrounding setup, OIDC authentication, service‑account provisioning, and network topology, only determines who may initiate a session. Because the credential never leaves the gateway, an attacker who compromises a nested agent cannot modify the policy or erase the logs. This separation ensures that the audit trail cannot be altered from the target side, a core requirement of iso 27001's control on integrity of security logs.
To get started, follow the getting started guide. Detailed policy examples and configuration options are described in the feature documentation.
hoop.dev can be deployed via Docker Compose for quick trials, or as a Kubernetes DaemonSet for production clusters. The agent runs close to the protected resource, guaranteeing low latency while keeping the enforcement point inside your trusted network perimeter.
Auditable artifacts required by iso 27001
iso 27001 mandates that organizations maintain evidence of controlled access to information assets. When nested agents are routed through hoop.dev, the following artifacts are automatically produced:
- Session logs that capture the identity, timestamp, command, and outcome for every nested‑agent interaction.
- Approval records that show who authorized a privileged operation, the justification, and the decision timestamp.
- Data‑masking logs that indicate which fields were redacted and the masking policy applied.
- JIT access grants that detail the duration and scope of each temporary credential.
- Configuration snapshots of the gateway policy that map identities to allowed actions.
Each artifact is tagged with the originating identity, a cryptographic hash of the request payload, and a timestamp synchronized to an authoritative time source. This metadata enables auditors to verify that logs have not been tampered with and that the recorded actions align with the approved policy at the moment of execution.
hoop.dev stores these artifacts in a secure log repository that can be exported for audit review. Because the gateway enforces policies at runtime, the evidence reflects actual behavior rather than static configuration alone, satisfying the iso 27001 requirement for “evidence of operation”.
Mapping hoop.dev controls to iso 27001 clauses
Clause A.12.4.1 requires logging of user activities and protection of log integrity. hoop.dev satisfies this by generating immutable session logs at the gateway. Clause A.9.2.3 calls for monitoring and reviewing privileged access. The just‑in‑time approval workflow provides a documented trail for each privileged command, and the replay feature lets reviewers watch the exact sequence of actions. Clause A.13.2.1 demands protection of data in transit; hoop.dev terminates TLS at the gateway and re‑encrypts to the backend, ensuring that any masked data never leaves the gateway in clear text.
FAQ
Does hoop.dev replace existing IAM systems?
No. hoop.dev relies on existing identity providers for authentication and on existing role definitions for authorization. It adds a runtime enforcement layer that records and controls each nested‑agent request.
Can I use hoop.dev with existing nested‑agent scripts?
Yes. By pointing the agent’s target endpoint to the hoop.dev gateway address, the same scripts continue to work while gaining session recording, inline masking, and just‑in‑time approval.
The retention policy should align with your organization’s iso 27001 control A.12.4.1. hoop.dev allows you to set a retention window that matches your compliance schedule.
Explore the open‑source repository on GitHub to review the implementation details and contribute to the project.
