Uncontrolled planner‑executor agents can silently rewrite production data without any guardrails. Policy enforcement is essential because without a central control point, a single faulty decision can cascade into irreversible damage.
Current practice
Many organizations treat a planner‑executor pair as a single automation component. The planner analyzes a goal, the executor runs the resulting commands against databases, Kubernetes clusters, or SSH hosts. To keep the system simple, teams often embed a static service‑account key or a long‑lived credential directly in the planner’s configuration. The executor then connects straight to the target resource using that credential, bypassing any runtime check.
This approach satisfies the immediate need for speed, but it also creates a blind spot. The credential is shared across multiple jobs, rotated only when an incident occurs, and is visible to anyone who can read the planner’s code or container image. No central authority sees which SQL statement was issued, which pod was created, or which file was edited. If the planner makes a wrong decision, the executor carries it out unchallenged.
Why policy enforcement matters
Policy enforcement for planner‑executor agents is a two‑step problem. First, the identity system (OIDC, SAML, service accounts) decides *who* may start a planning job. That setup is necessary, but it does not guarantee that the subsequent execution respects organizational rules. The request still reaches the database, the Kubernetes API, or the SSH daemon directly, without any audit trail, without inline data masking, and without a chance for a human to approve a risky operation.
Without a control point on the data path, the organization cannot answer questions such as:
- Did the executor run a destructive command that was not approved?
- Were sensitive fields like credit‑card numbers ever returned to the planner?
- Can we replay the exact command sequence that led to a production outage?
These gaps persist even when the identity layer is perfectly configured, because the enforcement logic never sees the traffic.
Introducing hoop.dev
hoop.dev is a Layer 7 gateway that sits between the planner‑executor pair and the target infrastructure. It verifies the user’s OIDC token, then proxies the connection, applying policies at the protocol level. Because the gateway is the only place the traffic passes, every enforcement decision happens there.
How hoop.dev enforces policy
When an executor attempts a connection, hoop.dev first checks the identity token against the configured identity provider. After the token is validated, the request is handed to the gateway. At that point hoop.dev can:
- Require just‑in‑time approval for commands that match a high‑risk pattern.
- Block or rewrite statements that would delete or alter protected tables.
- Mask sensitive response fields in real time, preventing the planner from seeing raw credit‑card numbers.
- Record the full session, including timestamps, commands, and responses, for later replay.
Each of those outcomes exists only because hoop.dev occupies the data path. The setup layer alone cannot provide them.
Benefits of a gateway
hoop.dev gives organizations concrete evidence that planner‑executor activity complies with policy. The recorded sessions become audit artifacts that satisfy internal and external reviewers. Inline masking reduces the blast radius of a compromised planner, because the executor never receives raw sensitive data. Just‑in‑time approvals turn a potentially dangerous operation into a controlled workflow, allowing a security analyst to intervene before damage occurs.
Because the credential is stored inside the gateway, the executor never sees the secret. This “credential‑never‑exposed” property eliminates the risk of credential leakage from logs or memory dumps.
Getting started
To adopt this model, start with the public getting‑started guide. It walks you through deploying the gateway, registering a planner‑executor connection, and configuring policy rules. The learn section provides deeper explanations of masking, approval workflows, and session replay.
All of the code is open source; you can review, customize, or contribute to the project on GitHub.
FAQ
How does hoop.dev differentiate between the planning and execution phases?
Both phases are treated as separate connections that pass through the gateway. Policies can be scoped per command, so a planning request that only reads data may be allowed, while the subsequent execution request that writes data can trigger approval.
Can I keep using existing service‑account keys?
Yes. hoop.dev stores the credential internally and presents it to the target only after the request has been authorized. The executor never receives the raw key.
Will the gateway add noticeable latency?
hoop.dev adds a small amount of processing time for policy checks and logging, but the trade‑off is a measurable increase in security and auditability. In most deployments the overhead is well within acceptable limits for automated workloads.
