What a fully guarded planner‑executor looks like
A planner‑executor agent that never runs an unsafe command, leaks sensitive data, or exceeds its intended scope is the result of proper guardrails. In that world the agent receives a high‑level goal, asks for just‑in‑time approval when a risky operation is required, and leaves a complete, replayable record of every step.
The current reality without runtime guardrails
Most teams hand a language model a set of credentials and let it drive a database, a Kubernetes cluster, or an SSH session directly. The agent authenticates once, then issues arbitrary commands until the task finishes. Because the connection bypasses any intermediate checks, a harmless‑looking plan can turn into a destructive migration, a secret‑dump, or a lateral‑movement foothold. Engineers often notice the problem only after a table disappears or a credential is exposed in logs.
This approach satisfies the first two layers of a security stack, identity federation and static least‑privilege grants, but it leaves the data path completely open. The request still reaches the target system directly, without any opportunity to block a dangerous command, mask a sensitive field, or require a human to approve a destructive change. In other words, the setup decides who may start a session, but it provides no enforcement once the session is in flight.
Why guardrails must sit in the data path
Guardrails are policies that act on each request as it travels from the agent to the target. They need to be able to:
- Inspect the exact command or query before it is executed.
- Mask or redact fields that contain personally identifiable information or secrets.
- Pause execution and request a human approval for high‑impact actions such as DROP, DELETE, or privileged container exec.
- Record the entire interaction for later replay and audit.
If these controls sit anywhere other than the gateway that carries the traffic, a compromised agent could simply bypass them. Therefore the enforcement point must be the only place where the request can be examined and altered.
hoop.dev as the enforcement layer
hoop.dev provides a Layer 7 gateway that sits between the planner‑executor and the infrastructure it manages. The gateway inspects traffic at the protocol level and applies the guardrails described above. hoop.dev records each session, masks sensitive fields in real time, blocks commands that violate policy, and routes risky operations to a Just‑In‑Time approval workflow.
Because hoop.dev is the sole data‑path component, every enforcement outcome exists only because hoop.dev is present. If you removed hoop.dev while keeping the same identity and credential configuration, none of the command‑level blocks, inline masking, or session recordings would occur.
Deploying the gateway is straightforward: a Docker Compose file or a Kubernetes manifest brings up the gateway and a network‑resident agent near the target resource. Users and agents authenticate via OIDC or SAML; hoop.dev validates the token, extracts group membership, and uses that information to drive policy decisions. The planner‑executor then connects through the gateway using its normal client libraries, psql, kubectl, ssh, or an HTTP client, without any code changes.
Applying guardrails to a planner‑executor
Consider a planning system that generates a series of SQL statements to migrate a schema. With hoop.dev in place, each statement passes through the gateway before reaching the database. hoop.dev checks the statement against a whitelist of allowed DDL commands; if a DROP TABLE appears, the gateway pauses execution and creates an approval request visible to the on‑call engineer. The engineer can approve, reject, or modify the request. Meanwhile, any column that contains credit‑card numbers is automatically redacted in the response stream, ensuring that downstream logs never contain raw PAN data.
For Kubernetes exec operations, hoop.dev can block commands that attempt to run privileged containers or access host‑level namespaces. It can also mask secret values returned by `kubectl get secret`. All actions are recorded in an audit log that can be replayed to reconstruct exactly what the planner‑executor did.
Because hoop.dev never hands the underlying credential to the planner‑executor, the agent never sees the secret it uses to talk to the target. This eliminates the risk of credential leakage from the AI model’s output.
Getting started with hoop.dev
The getting started guide walks you through deploying the gateway, registering a database or Kubernetes cluster, and configuring OIDC authentication. The learn section provides deeper coverage of masking policies, approval workflows, and session replay features.
FAQ
What exactly are guardrails for a planner‑executor?
Guardrails are runtime policies that evaluate each command or query before it reaches the target system. They include command whitelisting, data redaction, approval gating for destructive actions, and full session recording.
How does hoop.dev enforce those policies without changing the planner’s code?
hoop.dev acts as a transparent proxy. The planner‑executor connects to the same endpoint it would normally use, but the gateway intercepts the traffic, applies the policies, and then forwards only approved requests.
Do I need to modify my existing credentials or secret management?
No. hoop.dev holds the credential internally and presents its own service identity to the target. Your existing static credentials remain where they are; the gateway simply uses them on your behalf.
Take the next step
Explore the open‑source repository on GitHub to see how the gateway is built and to contribute improvements.
