How can you make an autonomous AI agent obey the same policy as code rules you write for code?
Many teams today treat an agentic AI model as a glorified script runner. They provision a service account, copy a static database password into the model’s prompt, and let the model issue queries directly against production systems. The model’s output is logged only by the host application, not by the data store. If the model hallucinates a table name or mis‑interprets a compliance rule, the request lands on the target without any human check, and no audit trail exists to prove who, or what, asked for the data. When a breach occurs, the organization can’t answer whether the AI was the source, because the request never passed through a control point that records intent, masks sensitive fields, or requires approval.
This reality violates the core idea of policy as code: policies should be expressed in a machine‑readable format and enforced automatically at the point of access. The current approach fixes the problem of “getting the model the credentials it needs,” but it leaves the request flowing straight to the backend, with no visibility, no inline data protection, and no way to intervene if a policy violation is detected.
Policy as code for agentic AI
Policy as code means writing rules, allow, deny, mask, require approval, in a declarative language that can be evaluated by an enforcement engine. For agentic AI, those rules typically cover:
- Which data sets the model may read or write.
- Field‑level redaction for personally identifiable information.
- Rate limits on the number of queries per minute.
- Escalation paths when a request touches high‑risk tables.
When the model submits a request, the enforcement point must be able to parse the protocol (SQL, HTTP, SSH, etc.), compare the operation against the policy, and either allow, mask, or block it before it reaches the target.
Why a data‑path gateway is required
The only place you can guarantee that every request is inspected is the network path that connects the AI agent to the backend service. Identity providers, service‑account tokens, and role‑based grants decide *who* can start a session, but they do not enforce *what* the session may do. Without a gateway sitting in the data path, any policy you write lives only in documentation or in a sidecar that the model can bypass.
Enforcement outcomes such as query‑level audit, inline masking, just‑in‑time approval, and session recording depend on a component that sits between the model and the resource. That component must be able to see the full request, apply the policy, and then forward the request only if it complies.
hoop.dev as the enforcement point
hoop.dev fulfills the requirement of a data‑path gateway. It proxies connections to databases, Kubernetes clusters, SSH hosts, and internal HTTP services. When an AI agent initiates a connection, hoop.dev validates the OIDC token, extracts group membership, and then routes the traffic through its Layer 7 inspection engine. At that point hoop.dev evaluates the policy as code you have defined.
hoop.dev records each session for replay, masks sensitive fields in query results, blocks commands that violate policy, and can pause a request for a human approver before it reaches the backend. Because the gateway holds the credential, the AI model never sees the secret directly, satisfying the “credential‑never‑exposed” principle.
How hoop.dev delivers the needed controls
- Just‑in‑time access: The model receives a short‑lived token that expires after the approved operation, reducing blast radius.
- Inline data masking: Responses containing PII are redacted according to the policy before they are returned to the model.
- Command‑level audit: Every statement the model sends is logged with identity, timestamp, and policy decision, providing a complete evidence trail.
- Human approval workflow: High‑risk queries trigger a workflow that requires a security analyst to approve or reject the request.
- Session replay: Recorded sessions can be replayed for forensic analysis or compliance reviews.
All of these outcomes exist only because hoop.dev sits in the data path. Removing hoop.dev would return the system to the original state where the model talks directly to the database with no guardrails.
Getting started
To adopt policy as code for your agentic AI, begin with the getting‑started guide. Deploy the gateway using the provided Docker Compose file, configure OIDC authentication with your identity provider, and register the target database as a connection. Define your policies in the supported YAML format and upload them through the UI or API. The learn section contains detailed examples of masking rules, approval workflows, and audit configuration.
View the hoop.dev source on GitHub for the full repository, contribution guidelines, and community support.
FAQ
Can I use hoop.dev with any AI model?
Yes. hoop.dev acts as a protocol‑level proxy, so any model that can speak the target protocol (SQL, SSH, HTTP, etc.) can be routed through the gateway.
Do I need to change my existing application code?
No. The model connects to the same host and port you would normally use; hoop.dev intercepts the traffic transparently.
How does hoop.dev store audit logs?
Audit logs are written to a configurable backend (object storage, database, or log aggregation service) and are immutable from the perspective of the model. The logs include the full request, the policy decision, and the identity that initiated the session.
