ISO 27001 for Planner-Executor Agents

When an ISO 27001 audit is completed, the auditor should be able to walk away with a complete, reliable audit trail that shows exactly who asked a planner‑executor agent to act, what the agent did, and whether any sensitive data was exposed.

In practice, teams that let AI‑driven planners run commands against production databases, Kubernetes clusters, or internal APIs often struggle to produce that trail. The agents typically use a shared service account, bypass traditional ticketing systems, and leave no record of the individual request that triggered the action. Without a clear boundary that can observe and log each step, auditors see only the final state of the system and a handful of vague logs that do not satisfy ISO 27001 clauses around access control, auditability, and data protection.

ISO 27001 expects evidence that demonstrates:

• Identity of the requester and the service account that performed the operation (A.9.2.1).
• Just‑in‑time approval or documented business justification (A.9.4.2).
• Full command‑level audit logs captured for review (A.12.4.1).
• Protection of sensitive fields in responses, such as credit‑card numbers or personal identifiers (A.14.1.2).
• Retention of records for the period required by the organization’s information security policy (A.18.1.3).

Generating iso 27001 evidence for planner‑executor agents

To satisfy those requirements, the control point must sit between the identity that initiates a request and the target resource that executes it. That is where hoop.dev comes into play. hoop.dev is a Layer 7 gateway that proxies connections to databases, Kubernetes, SSH, RDP, and internal HTTP services. By placing hoop.dev in the data path, every request from a planner‑executor agent is forced through a single, policy‑driven choke point.

Setup: defining who can ask an agent to act

The first step is to provision non‑human identities for the planner‑executor framework. These identities are typically OIDC service accounts or SAML‑backed service principals. The setup defines the minimal set of permissions each identity needs to request work, but it does not enforce any limits on its actions. In other words, the setup decides who may start a request, but it does not guarantee that the request will be recorded or approved.

The data path: hoop.dev as the enforcement boundary

Once the identities are in place, hoop.dev sits in front of every target resource. When a planner‑executor agent attempts to open a PostgreSQL connection, execute a kubectl command, or start an SSH session, hoop.dev intercepts the traffic, validates the presented token, and applies the configured policies before the request reaches the backend. Because enforcement happens inside the gateway, the agent itself cannot bypass the checks or hide its activity.

Enforcement outcomes that satisfy iso 27001

hoop.dev records each session, captures the identity that initiated the request, and stores the exact command string. It also supports just‑in‑time approval workflows, so a privileged reviewer can approve or reject a risky operation before it is executed. Sensitive fields in query results are masked in real time, ensuring that downstream logs never contain raw personal data. All of these outcomes exist only because hoop.dev occupies the data path; removing the gateway would eliminate the audit trail, the approval step, and the masking capability.

These capabilities map directly to ISO 27001 controls:

• A.9.2.1 – User access provisioning: hoop.dev ties every action to a verified identity.
• A.9.4.2 – Access control to program source code: the approval workflow enforces separation of duties.
• A.12.4.1 – Event logging: session recordings and command‑level logs provide evidence for audit.
• A.14.1.2 – Secure development: inline masking protects sensitive data at the point of retrieval.
• A.18.1.3 – Protection of records: logs are retained according to policy and can be presented to auditors.

Practical steps to get audit‑ready evidence

1. Follow the getting‑started guide to deploy the hoop.dev gateway in your network. The gateway runs as a container or a Kubernetes pod and includes an agent that lives next to each target resource.

2. Register each planner‑executor service account as a connection source in hoop.dev. Assign the minimal IAM or database role needed for the agent to perform its work.

3. Enable just‑in‑time approvals for commands that modify production state. Configure an approval group that receives a notification and must explicitly approve the request before hoop.dev forwards it.

4. Turn on session recording and command‑level logging for every connection type the agents use. The logs are retained according to your policy and can be accessed for audit purposes.

5. Define masking rules for any columns or fields that contain regulated data. hoop.dev will replace those values with placeholders before they are written to logs or returned to the agent.

6. Set retention policies that match your organization’s information‑security schedule. hoop.dev retains logs for the configured period, providing the evidence required by ISO 27001.

7. Periodically review the audit reports generated by hoop.dev. The learn portal contains examples of compliance dashboards and export formats that auditors readily accept.

FAQ

Do I need to change my existing planner‑executor code?

No. The agents continue to use their native clients (psql, kubectl, ssh, etc.). hoop.dev acts as a transparent proxy, so the only change is the endpoint address that points to the gateway.

Can I still use my current CI/CD pipelines?

Yes. CI/CD jobs can authenticate with the same OIDC service accounts that the planner‑executor agents use. hoop.dev will enforce the same policies, ensuring that automated pipelines also generate ISO 27001‑compatible evidence.

What if an auditor asks for raw data that was masked?

Masking is applied only to logs and audit records. The underlying target still receives the full data, so you can retrieve the original values directly from the database if a legitimate request is made under a separate, audited process.

By placing a policy‑driven gateway in front of every infrastructure endpoint, teams can turn opaque AI‑driven actions into a fully auditable, approval‑controlled workflow that satisfies ISO 27001 evidence requirements.

View the open‑source repository on GitHub to get the code, contribute, or fork the project for your own compliance needs.