Kastra Enforces Policies for Cursor Agents

Kastra describes an authorization layer that evaluates policy before an AI system acts. Its current product page offers an HTTP API for agent integrations and Kastra Edge for developer tools including Cursor. It advertises allow, deny, redact, and hold decisions with recorded audit evidence. These are vendor claims; this article proposes an integration exercise rather than reporting a completed evaluation.

Updated 21 September 2026: checked the current product description, removed repeated search phrases and an unverified launch anecdote, and replaced a name-based database policy example with a test of actual enforcement.

Locate the enforcement point

A policy response and an enforced restriction are different things. The caller must request a decision before execution, respect that decision, and prevent another route from performing the same operation unchecked. A successful API demo alone does not establish those properties for an entire coding environment.

Map one operation from Cursor to its destination. For example, an agent might request a write through an MCP tool whose server calls a test API. Identify where policy is checked, which identity and resource attributes it receives, and which component can actually stop the write. Then list other available routes, such as a shell command with credentials for the same API.

If those routes remain unrestricted, the boundary is incomplete. Removing unnecessary credentials may solve the problem more directly than adding another policy integration. Keep native service authorization in place while evaluating any additional layer.

Use a disposable service and observable state

Create a test service with fixture records and two operations: read a record and change one field. Use credentials restricted to that service. Record the fixture state before each case, then inspect it afterwards independently of the agent's explanation.

These are test requirements, not Kastra policy syntax:

Choose the expected outage behavior before running the test. For this write-blocking experiment, deny writes when authorization cannot be established. Confirm what the selected integration actually does; do not assume that a product-wide feature description proves a particular adapter fails closed.

Avoid policies based only on an environment string such as prod. A caller-controlled label is not reliable evidence of the destination. Use trusted resource identity and service-side permissions, and include a deliberately mismatched label in the test to expose accidental trust in request text.

Keep instructions useful without treating them as permissions

Repository instructions can tell the agent which tools to use, how to explain a denied action, and where to report missing access. They cannot make an otherwise permitted API call impossible. Keep workflow guidance in the subagents and skills conventions, while access restrictions remain in the executing systems.

Ask the agent to stop and report a denial rather than search for an alternative credential. Also test that the environment prevents the prohibited action independently of that instruction. An obedient run is useful evidence about the workflow, but it is not proof of enforcement.

Review the evidence before widening access

Retain the policy version, operation, trusted target identity, decision, and observed service state. Avoid copying secrets into an audit note. A reviewer should be able to connect a denial to the unchanged fixture without relying on a chat summary.

Use the result to decide whether the integration closes a real gap. Keep it narrow if only one tool path has been verified. If a read-only credential already meets the task's needs, use that simpler boundary. Broader agent access should follow demonstrated coverage, rather than being granted because an authorization product has been installed.