Uncontrolled AI agents can execute costly queries, exfiltrate confidential fields, or spin up cloud resources that balloon your bill in minutes. Applying policy as code to these agents is the only way to keep costs predictable and enforce intent.
In many organizations the default is to hand an agent a static API key or a service‑account token that has broad read/write privileges. The agent talks directly to the database, Kubernetes API, or SSH host, and there is no per‑request visibility. Because the connection bypasses any central control point, a single malformed prompt can delete production tables, expose secrets, or trigger a cascade of resource provisioning. When something goes wrong, you discover it weeks later, after the damage is done and remediation costs have exploded.
Policy as code promises a declarative way to say “this agent may only SELECT from the public schema” or “it may only create pods in the dev namespace”. Yet if the policy lives only in a Git repository and never touches the traffic, the request still reaches the target unchanged. The connection lacks an audit trail, inline data masking, or a just‑in‑time approval step, so you cannot prove who caused a breach or prevent it in real time.
To close that gap you need three pieces. First, a **setup** that authenticates the agent with an identity provider and issues a least‑privilege token scoped to the exact operations the agent needs. Second, a **data path** that sits between the agent and the resource and is the only place where enforcement can happen; no traffic may skirt around it. Third, the **enforcement outcomes**, session recording, real‑time masking, command blocking, and approval workflows, that exist only because a gateway enforces the policy at the point of entry.
Why policy as code matters for AI agents
AI agents are powerful because they can generate and run commands at scale. Without a guardrail, a well‑intentioned prompt can cause a DELETE on a production table, or an unintended credential leak that spreads across services. Encoding the allowed actions in policy as code gives you a single source of truth that can be versioned, reviewed, and tested before deployment, reducing the chance of accidental over‑reach.
When the policy is expressed in a machine‑readable format, you can automate compliance checks, integrate with CI pipelines, and propagate changes across environments without manual reconfiguration. The real benefit, however, appears only when that policy is enforced at the point where the agent’s traffic passes, turning a static declaration into an active control.
Building a trustworthy enforcement layer
The **setup** begins with an OIDC or SAML identity provider, Okta, Azure AD, Google Workspace, or any SAML‑compatible IdP. The agent authenticates, receives a token that carries its group membership, and the token is scoped to the minimal set of permissions required for its job. By limiting the token’s claims, you prevent the agent from presenting broader credentials later in the workflow.
Next, the **data path** must be a gateway that proxies the connection. This gateway inspects the wire‑level protocol, applies the policy, and only then forwards the request to the target. Because the gateway is the sole conduit, it can block disallowed commands, mask sensitive columns in query results, or pause execution for a human approval. Deploying the gateway close to the resource, on the same VLAN or within the same Kubernetes namespace, ensures that traffic cannot bypass it via an alternate route.
hoop.dev provides exactly that gateway. It sits between identities and infrastructure, proxies PostgreSQL, MySQL, SSH, Kubernetes, and other supported services, and enforces policy as code on every request. hoop.dev records each session for replay, masks fields that match policy rules, and can require just‑in‑time approval before a risky command proceeds. The enforcement outcomes exist only because hoop.dev lives in the data path.
To get started, follow the getting started guide and review the learn page for detailed feature explanations.
Practical best practices
- Define policies in a declarative language and store them in version control alongside your code so changes are tracked and reviewed.
- Scope agent identities to the narrowest possible role in the identity provider; never grant admin‑level tokens.
- Deploy the gateway close to the target resource so that traffic cannot bypass it, and enforce TLS to protect data in transit.
- Enable session recording for every AI‑initiated connection; use replay to investigate anomalies and provide evidence for audits.
- Apply inline masking for any columns that contain PII or secrets, ensuring they never leave the gateway in clear text.
- Require just‑in‑time approval for commands that modify production state or access privileged data, and configure alerts for blocked attempts.
- Regularly review audit logs generated by the gateway to refine policies, detect drift, and improve the risk model.
FAQ
How does policy as code differ from traditional access control lists?
Traditional ACLs are often static and attached to a user or role. Policy as code is a versioned, programmable set of rules that can express conditions on the request itself, such as the specific SQL statement, the target namespace, or the time of day. When enforced by a gateway, those rules are applied to each request in real time, turning intent into enforceable action.
Can I use hoop.dev with existing CI/CD pipelines?
Yes. Because policies are stored in code repositories, you can validate them in CI, and hoop.dev will enforce the same policies at runtime without additional tooling. This keeps the policy lifecycle consistent from development through production.
What happens if an AI agent tries to run a disallowed command?
hoop.dev intercepts the request, checks it against the policy, and blocks execution. The blocked attempt is logged, and if configured, a notification can be sent to a reviewer for further action.
Explore the source code and contribute on GitHub.
