Imagine the review. An auditor asks how an AI coding agent in Cursor is prevented from running a destructive command against production, and asks you to show the evidence. If your answer is a prompt instruction that says "please do not drop tables," you fail. Real guardrails are enforced where the agent cannot edit them, and they produce a record someone else can read.
This post frames the setup around that review, because passing it is the bar that separates a guardrail from a suggestion. Anything you cannot demonstrate is, for audit purposes, simply not there.
What an auditor counts as guardrails
A guardrail an auditor accepts has three properties. It is enforced outside the controlled process, so the agent cannot turn it off. It is specific, so you can name the operation it blocks or pauses. And it leaves evidence, so the control can be demonstrated after the fact, not just asserted in a meeting.
A rule written into the agent's system prompt has none of these. The agent can be talked past it, there is no enforcement point where the command actually fires, and there is no record. It is the first thing an audit discards. The same is true of a linter or a code-review step: useful for the code, silent about what the agent does at runtime against a live system.
How guardrails work through hoop.dev
hoop.dev is an open-source Layer 7 access gateway. The Cursor agent reaches a database or internal service through it, and the guardrails apply on that connection:
- Access is just in time and scoped per connection, so there is no standing credential to misuse.
- Dangerous operations route for human approval and pause until a person responds.
- Every command is recorded at the gateway, outside the agent, with the identity attached.
- Sensitive fields are masked inline on results from supported databases.
Because these run at the gateway, the agent cannot reconfigure them. That is what makes them defensible in a review, and it is why hoop.dev governs the connection rather than living inside Cursor. The agent reaches infrastructure through the gateway; it does not get to vote on the rules there, and hoop.dev never reads its prompts. The control model is laid out on the hoop.dev site.
A setup that produces audit evidence
- Run the hoop.dev agent beside the target database and register the connection.
- Scope the agent's identity to the minimum: read where it should read, no schema changes.
- Set an approval rule on writes and deletes, so they pause for a named approver.
- Confirm sessions are recorded, then run a sample query and pull the session record.
When the auditor asks for proof, you export the session log: who connected, what command ran, whether it was approved. The guardrail is no longer a claim. It is a record. That shift, from assertion to evidence, is the entire point of putting the control on the connection.
Pitfalls to avoid
Do not let the agent hold its own credentials in a local config, because that path skips the gateway and every guardrail with it. Do not treat the agent's own logs as audit evidence; a log the agent can write is a log it can omit. And do not assume one broad approval rule fits every connection. Scope rules to the risk of each target, so a read-heavy reporting database is not gated the same way as the billing tables. A blanket rule either blocks too much, training the team to route around it, or too little, leaving the dangerous path open. Tune the approval threshold per connection and revisit it when the agent's role changes.
FAQ
Are guardrails enforced inside Cursor?
No. They are enforced on the connection at the gateway. The agent reaches infrastructure through hoop.dev and cannot disable controls that live there.
What evidence does an audit get?
Per-session records tied to an identity: the command run, the connection used, and the approval status. That is the artifact reviewers ask for.
Is hoop.dev open source?
Yes, it is MIT licensed, so you can verify how the guardrails are enforced rather than take it on faith.
Build guardrails you can defend in a review. Start from the hoop.dev GitHub repository and set your first approval and recording policy with the getting started guide.
