Kastra Enforces Policies for Cursor Agents

Kastra is a Show HN project by Fernando and his co-founder that adds policy enforcement for Claude Code, Anthropic's coding agent; Cursor, Anysphere's AI code editor; and Codex, OpenAI's coding agent. 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. 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.

The trap is 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

Developers cared because 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.

The trap is using 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, the related training topic on 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.

The trap is 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.

The trap is 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

• Is cursor suitable for teams and large codebases?

  Yes, Cursor can be suitable for teams and large codebases when repo context, cursor rules, review habits, and external permissions are designed deliberately. The caveat is that model-facing instructions do not replace runtime controls. If agents can reach databases, deployment systems, or internal MCP servers, add hard boundaries outside the chat.

• Does Kastra replace Cursor rules?

  No, Kastra-style runtime authorization does not replace Cursor rules. Rules tell the agent how the repo works and what behavior you expect. A policy layer checks whether a requested tool call is allowed before it executes. The strongest setup uses both: instructions for quality, authorization for irreversible actions.

• 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.

• Should a cursor ai agent ever touch production?

  Usually, not directly, and never with broad default permissions. If an agent needs production context, prefer read-only credentials, narrow MCP tools, audited access, and short-lived sessions. A runtime policy layer is most useful as a backstop for the small set of production-adjacent actions you have chosen to expose.

• Is this the same as sandboxing?

  No, sandboxing and runtime authorization solve different parts of the problem. A sandbox limits the environment an agent can affect. Runtime authorization evaluates a specific tool call before it runs. Use sandboxes first where possible, then add policy checks where the agent must cross into external systems.

Best ways to use this research

• Best for: evaluating coding-agent workflows where the agent can call shell commands, MCP tools, database clients, deployment scripts, or internal services.
• Best first artifact: a one-page permission table for a single risky tool, plus a Cursor rule that tells the agent how to request review before using it.
• Best comparison angle: compare prompt-only safety, sandboxing, read-only credentials, and runtime authorization by asking which layer stops an already-requested destructive action.
• Best limitation to remember: a policy layer can block known risky actions, but it cannot fix vague ownership, overbroad credentials, or a workflow nobody reviews.

Further reading

• Cursor — Agent
• Cursor — Rules
• Policy enforcement for Claude Code, Cursor, and Codex — source

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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.