Kastra Enforces Policies for Cursor Agents

By Rogier Muller07.10.26

Kastra is a Show HN project that adds policy enforcement for Claude Code; Cursor; and Codex. Its Hacker News launch thread names Fernando and his co-founder as the builders. It intercepts AI agent tool calls and checks deterministic policies before the call runs, especially around risky actions like database writes. The useful lesson for Cursor users is simple: cursor ai agents need runtime boundaries as well as good prompts, rules, and reviews. Try this kind of tool when an agent can touch real systems; skip it when the agent is only editing files in a sandbox.

Watch the tool call, not just the prompt

Runtime authorization is a last-second permission check on a tool call, done after the model asks to act and before the outside system changes.

That is the interesting part of Kastra. The project is not trying to make the model more careful by giving it a longer instruction. It sits in the path between the agent and the tool, then decides whether the requested action is allowed.

The origin story is concrete enough to make engineers sit up. On the same Hacker News thread, the builders said they made Kastra after a Cursor agent almost ran a DELETE FROM customers WHERE status='test' style query against a production database. They caught it before execution, but the scare exposed a gap: nothing in the stack was making an explicit allow-or-deny decision.

Watch for thinking the prompt was the failure. Prompts matter, and Cursor rules matter, but a prompt is not a permission system. If the agent can call a shell, database client, or MCP server with write access, you need something outside the model to say no.

Why the Show HN thread got sharp

The example crossed a bright line: an agent was close enough to production data that a bad tool call mattered. Some people read that as the real bug. Why was an agent anywhere near production in the first place?

That objection is fair. Sandbox the agent when you can. Give it short-lived credentials. Prefer read-only access. Make the orchestrator, operator, and subagents boringly constrained.

Kastra is interesting because it deals with the uncomfortable middle. Many real engineering workflows are not pure toy sandboxes. Agents inspect logs, open pull requests, run migrations locally, call internal services, and fetch context through MCP servers. The moment those tools cross from repo-only work into outside systems, deterministic policy checks become more useful.

The trick is boring in the best way. Do not ask the model whether it feels safe. Evaluate the requested action against a policy before it executes.

Don't use runtime authorization as an excuse to grant broad production access. A policy layer should reduce blast radius, not bless risky defaults.

Keep Cursor rules as instructions, not locks

Cursor rules are excellent for shaping how an agent works in a repo. A rule can say where tests live, how migrations are named, what files need review, and which APIs are deprecated. Cursor skills can package reusable workflows and reference material so the agent has a better path through common work.

Those artifacts are model-facing instructions. They help the agent choose better actions, but they do not prove the action is allowed. A .mdc rule that says never write to production is still text the model reads, not a guard at the database boundary.

A useful pattern is to keep the layers separate. Put durable repo rules in Cursor rules or AGENTS.md. Put repeatable workflows in cursor skills. Put external access behind MCP servers and other tools with the narrowest permissions you can manage. Then use runtime policy enforcement for the calls that could mutate data, spend money, leak secrets, or page humans.

For readers working through cursor subagents, cursor custom agents, and cursor skills, Cursor subagents and skills is the place to keep the instruction layer tidy. For a nearby MCP example, ultralytics-mcp Connects YOLO to Cursor shows how quickly agent workflows become more than local text editing once external tools enter the loop.

Watch for stuffing every safety concern into one giant rule file. Long rule files become vague policy theater. Small scoped rules plus hard tool boundaries are easier to review.

Try it when the agent can change the outside world

Kastra-style enforcement is worth testing when a coding agent can act beyond the working tree. That includes shell commands with credentials, database clients, deployment tools, MCP servers connected to internal systems, or any workflow where a Cursor custom subagent might do more than draft code.

It is probably overkill for a small personal repo where the agent only edits files and runs local tests. In that case, Cursor rules, branch isolation, code review, and a clean git reset path may be enough.

The practical question is not whether the agent is smart. It is whether the action is reversible. If the agent proposes a bad refactor, you can reject a diff. If it deletes customer rows, sends email, rotates a secret, or deploys a broken build, the recovery story is very different.

This is also the right place to be precise about cursor ai workflows. Whether you are using Cursor Agent, thinking in the older cursor composer style of multi-file edits, or wiring up Cursor MCP tools, the risk changes when the agent gets a handle to a real system. That handle deserves a permission table, not just a friendly reminder.

Try it safely in a small repo

Use a small experiment before you let any policy layer near valuable systems. The goal is not to prove the agent can do everything. The goal is to prove your boundary catches one dangerous thing without blocking normal work.

Copy this starter plan into a scratch repo and adapt it to your stack:

Experiment: runtime policy for one risky tool

Repo: internal-admin-sandbox
Agent path: Cursor Agent edits code, runs tests, and can call a local database client
Risky action: database write against any environment named prod or production
Allowed action: read-only SELECT against seeded local data
Expected block: DELETE, UPDATE, INSERT, ALTER, DROP against production-looking targets
Human review: required before changing policy from block to allow
Success signal: normal test workflow still works, dangerous write is denied before execution
Stop condition: the policy blocks ordinary local development more than twice in one session

Pair that with a small Cursor rule so the model knows the boundary even though the runtime policy enforces it:

---
description: Guardrails for agent access to databases and external services
globs:
  - **/*
alwaysApply: true
---
Do not run write queries against production databases.

Before using an MCP server, shell command, or database client that can mutate data, state:
- target environment
- operation type
- expected blast radius
- rollback plan

Prefer read-only credentials for agent-driven investigation.

Then review the actual blocked calls. A good first review checklist is short: what tool was called, what arguments were passed, what policy matched, what would have happened, and whether a human would ever approve that exact action.

Watch for starting with every policy at once. Pick one boundary. Production database writes are a good first candidate because the desired answer is usually obvious.

Common questions

Where do cursor skills fit if policies enforce actions?

Cursor skills fit on the knowledge and workflow side. A cursor skill can teach the agent how to investigate an incident, run a migration checklist, or format a review summary. Runtime policy should still guard the tools that skill uses, especially when the workflow touches credentials, databases, or production-like services.

Next step

Pick one agent tool that can change something outside your repo, and write the deny rule you wish had existed before the first scare. If the rule is hard to state, the agent probably has too much reach.