AI coding agents now run shell commands, edit files, and hit live APIs on their own. That autonomy is the whole point of tools like Claude Code, Cursor, and Codex, and it is also the risk. A single misread instruction can delete a directory, paste a secret into a log, or push to the wrong environment. Kastra, which surfaced on Hacker News on July 9, 2026, is a runtime authorization layer that sits between your agent and your machine and decides what each action is allowed to do before it happens. Its own tagline is blunt: "Kastra decides what your AI is allowed to do before it does it."
For creators and builders who have handed real filesystem and terminal access to an AI agent, this is the missing safety layer. Below is what Kastra does, how it compares to the permission prompts already built into these tools, and the exact three-command setup for its local Edge module.
What Kastra Actually Does
Kastra is a policy engine that intercepts an agent's actions and checks each one against rules you define, in real time, before the action executes. According to Kastra, decisions land in under one millisecond at the p99 percentile, so enforcement stays out of the critical path and your agent does not feel sluggish. Every decision is signed and hash-chained into an append-only audit log, which is the part compliance teams care about: you get a tamper-evident record of what the agent tried, what was allowed, and what was blocked.
The product splits into two surfaces. The cloud and self-hosted policy engine governs server-side agents and frameworks. The Edge module is the one that matters for local coding assistants: it installs on your laptop and governs the agent running in your terminal. Kastra describes this as "governance on the laptop," intercepting shell commands, file edits, writes, and API calls before they run so that a destructive command like rm -rf or an accidental secret exposure never reaches the shell.
How It Compares to Built-In Agent Permissions
Claude Code, Cursor, and Codex already ship permission systems. Claude Code has an allow/deny settings model with per-tool prompts, and Cursor added environment governance in its 2026 releases. So what does a dedicated layer add? The short answer is coverage that survives across every agent, a real audit trail, and policies you cannot click past at 2 a.m. Here is how the approaches line up.
| Approach | Where it runs | What it checks | Audit trail | Works across tools |
|---|---|---|---|---|
| Built-in permission prompts | Inside each agent | Tool calls it exposes | Limited / per-tool | No, per-tool config |
| Manual review of every diff | In your head | Whatever you notice | None | Yes, but does not scale |
| Kastra Edge | On the machine, below the agent | Shell, file writes, API calls | Signed, append-only | Yes, one policy set |
The distinction is that built-in prompts are a feature of the agent, so a new agent means a new configuration and a fresh set of blind spots. Kastra sits a layer down, enforcing one composable policy set across Claude Code, Cursor, Codex, and the other agents it integrates with, so the rules travel with the machine rather than the tool. The New Stack has documented how these coding tools are merging into one stack, which makes a tool-agnostic guardrail more useful, not less.
Setting It Up: Three Commands to Governed
Kastra Edge ships as a macOS menu-bar app that bundles the CLI and an MCP server, or as a CLI and hooks install for macOS and Linux via Homebrew (brew install kastra-labs/tap/kastra-edge). Per the quick start, getting from installed to enforcing is three commands:
- Sign in:
kastra-edge loginauthorizes the device through your browser. - Connect your agent:
kastra-edge install-cursoradds governance to Claude Code, Codex, or Cursor. - Verify enforcement:
kastra-edge statusconfirms Kastra is live on the machine.
After that, in Kastra's words, "every action your agent takes is checked, decided, and logged." Kastra advertises a free tier for solo developers with a roughly 60-second setup and no lock-in, so the barrier to trying it on a single project is low.
What Kinds of Actions Get Checked
Kastra's policy model is composable, combining rules across identity, scope, intent, content, and destination. In practice, that means a policy can reason about more than a bare command string. It can consider who is running the agent, what project scope it is operating in, what the action appears to be trying to do, what data is inside the payload, and where a call is headed. The engine enforces inline on prompts, tool calls, shell commands, queries, and API requests.
Concretely, the kinds of rules a builder would set include blocking recursive deletes outside a project directory, refusing any command that reads a .env or credentials file and sends it to an external host, gating writes to production configuration, and requiring that outbound API calls only target approved destinations. Kastra lists integrations with 38 sources, including coding agents (Claude Code, Cursor, Continue, Aider, Windsurf), agent frameworks (LangChain, LangGraph, LlamaIndex, Vercel AI SDK, Mastra, OpenAI Agents), and identity providers, per its integrations page. Security researchers have catalogued the specific risks these agents introduce, and independent write-ups on securing Cursor, Codex, and Claude Code map closely to the failure modes Kastra targets.
Why This Matters for Builders: What This Enables
The real unlock here is trusting an agent with more autonomy without trusting it blindly. Most people cap what their coding agent can do by babysitting it: approving each diff, keeping it out of the terminal, or running it in a throwaway container. A runtime policy layer flips that. You write the boundaries once, then let the agent work in your actual project with a hard floor under it. For a solo creator that means you can leave an agent running a long refactor and know that a hallucinated rm -rf ~ gets blocked, not executed. For a team it means the audit log answers "what did the AI touch" with signed evidence instead of a shrug.
If you already lean on Claude Code or Cursor for daily building, the workflow to adopt this is small: install Edge on one machine, start with a permissive log-only posture to see what your agent actually does, then tighten the rules that would have caught something you did not want. You keep your existing agent, prompts, and habits. You just add a layer that says no when it counts. For a deeper look at how policy-as-enforcement works, Kastra's own explainer on what AI policy enforcement is is a useful primer.
Frequently Asked Questions
Is Kastra free?
Kastra advertises a free tier aimed at solo developers, with a quick setup and no lock-in. It also offers cloud, self-hosted, and air-gapped deployments for teams, and lists enterprise compliance certifications, but specific paid pricing is not published on the marketing pages as of July 9, 2026.
Does Kastra slow down my coding agent?
Kastra states policy decisions complete in under one millisecond at the p99 percentile, so enforcement is designed to stay off the critical path. In practice the check happens between the agent deciding on an action and that action executing, so you should not notice added latency in normal use.
Which agents does it support?
The Edge module explicitly covers Claude Code, Cursor, and Codex, and Kastra's integrations list adds Continue, Aider, and Windsurf among coding agents, plus frameworks like LangChain, LangGraph, LlamaIndex, Vercel AI SDK, Mastra, and OpenAI Agents.
How is this different from the permission prompts already in Claude Code or Cursor?
Built-in prompts live inside each agent and cover the tools that agent exposes, so they must be reconfigured per tool. Kastra runs a layer below the agent on the machine, enforces one policy set across every supported agent, and produces a signed, append-only audit log rather than per-tool approvals you can click past.
Do I have to send my code to Kastra's cloud?
No. Edge governs actions locally on the laptop, and Kastra offers self-hosted and air-gapped deployment options for teams that cannot use the cloud. The policy decision happens on the device for local coding agents.
Can it stop an agent from leaking secrets?
That is a core use case. Because policies can reason about content and destination, you can write a rule that blocks any action reading a credentials or .env file and sending its contents to an external host, and the block happens before the request leaves the machine.
