When an ISO 27001 audit asks for proof that every subagent action is traceable, approved, and protected, the ideal report shows a complete, immutable trail of who did what, when, and how sensitive data was handled. Auditors expect documented policies, controlled access, real‑time monitoring, and evidence that privileged commands cannot bypass oversight.
Why subagents often fall short of iso 27001 evidence
In many organizations, teams grant subagents – scripts, CI runners, or automated services – long‑lived credentials and copy those credentials across environments. Organizations store the credentials in shared vaults or plain‑text files, and the agents connect directly to databases, Kubernetes clusters, or SSH hosts. The result is a black box: the subagent talks to the target, but no central system records the request, the exact query, or the response. When a breach occurs, the team can tell that a subagent participated, but they cannot prove which command triggered the event, whether the data returned contained PII, or whether an approval step bypassed the process.
Even when organizations adopt least‑privilege IAM roles or short‑lived tokens, the enforcement still happens on the client side. The request reaches the target directly, and the target has no visibility into who authorized the operation or whether the response needed redaction. Consequently, the audit trail fragments, and the organization cannot demonstrate compliance with ISO 27001 clauses that require controlled access (A.9.2), protection of information in use (A.12.4), and audit logging (A.12.4.1).
What must change before you can hand an auditor a complete package
The organization issues each subagent identity through a trusted identity provider and ensures the token carries only the permissions required for the specific job. This setup defines who the request is, but it does not enforce any guardrails on the traffic itself. The subagent still talks straight to the database or Kubernetes API, meaning the organization lacks a single point where policies such as just‑in‑time approval, command‑level blocking, or inline data masking can be applied.
Without a gateway in the data path, the organization cannot guarantee that every command is recorded, that sensitive fields are masked before they leave the target, or that a human can intervene on risky operations. In other words, the missing piece is a control surface that sits between the subagent and the resource and enforces the policies required by iso 27001.
hoop.dev as the data‑path enforcement layer
hoop.dev fulfills that missing layer. It is a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH hosts, and internal HTTP services. The gateway runs an agent inside the customer network, so the target never sees the subagent’s credentials. All traffic passes through hoop.dev, which is the only place where enforcement can happen.
Setup: The organization handles identity via OIDC or SAML. The IdP issues a token that the subagent presents, and hoop.dev validates the token, extracting group membership and attributes that drive policy decisions. This step decides who may start a session, but it does not, by itself, provide audit evidence.