Launching today
Kastra
Runtime authorization for Claude, Cursor, Codex and OpenClaw
469 followers
Runtime authorization for Claude, Cursor, Codex and OpenClaw
469 followers
Kastra is the runtime authorization layer for AI agents. It decides what agents can and cannot do before actions execute, enforcing policies with sub-1 ms latency across tools, prompts, inputs, and outputs. Use one control plane to govern agents and policies across Claude Code, Cursor, Codex, OpenClaw, the Anthropic SDK, the OpenAI SDK, and more. Prevent unauthorized tool use, prompt injection, and exposure of sensitive data before they become incidents. Trust the rules, not the agents.
One control plane across Claude Cursor Codex and other tools feels practical for mixed environments. Does it support temporary project exceptions without weakening security? That flexibility could help development teams move faster.
Kastra
@jason_scott8 Yes, teams can create project-specific or time-limited policy exceptions while keeping organization-wide guardrails in place. That way, developers can unblock legitimate work without permanently weakening their security posture. The idea is to make exceptions explicit, auditable, and easy to revoke.
Our "Teams" plan also allows CTOs and Engineering leaders to push policies down to their employees for company-wide rules; these are enforced locally and also with their cloud and browser agents or plugged directly into the LLM SDKs for custom integrations.
@carlosjimenez1 congrats on the launch ! I'm curious how the sub-1ms number holds up as policy count grows. Is that benchmark against a handful of rules? or does latency stay flat once a team has been customizing dozens or hundreds of overlapping policies over time?
Kastra
@carlosjimenez1 this is a strong claim for a policy engine, most implementations tend to slow down as rule count grows unless there's indexing under the hood. are you compiling or slicing policies ahead of time so only the relevant ones get evaluated per request?
Kastra
@clement_avq We don't evaluate every policy on every request. Policies are scoped to the execution context (for example, the agent, tool, action, environment, or resource), so we only evaluate the subset that's relevant to the current operation rather than the entire policy set. Keeping authorization latency consistently low as policy sets grow was a core design goal from day one, so we spent a lot of time optimizing the evaluation path instead of treating policy execution as an afterthought.
The output-side check is the half most policy layers skip — gating on the agent's output before it executes, not just the input. Two things I'd wire-test first in a coding-agent loop: is the sub-1ms decision in-process/local, or a network hop to your control plane (which changes the latency math mid tool-call)? And when a policy can't reach a verdict in time, do you fail-closed by default, or is that configurable per-policy?
Kastra
@hi_i_am_mimo Great questions. The sub-1 ms number is local policy-evaluation time, not a network round trip to our hosted control plane. In coding-agent loops, the data plane evaluates policies locally; the control plane distributes policies and receives decision logs.
Failure behavior is configurable by environment/workload. A team might fail closed for production actions and sensitive-data access, while failing open for lower-risk local development. We don’t think one universal default makes sense across every action surface.
how granular do the policies get in practice - is it more like broad allow/deny categories per tool, or can you actually write a rule like "deny this specific SQL write pattern but allow reads"? asking because the false positive rate on anything doing semantic judgment on agent intent tends to be the real blocker to running this in prod, not the latency.
Kastra
@omri_ben_shoham1 Yes, exactly, you can be very specific about what you want to block. For example, you can create a policy to block all write/destructive operations on a specific table. Just type what you want, like "Block all write operations on the users table," and Kastra will create the policy for you.
The important line here is "before actions execute." For teams using agents around real repos or customer systems, post-hoc logs are useful but they are not a control boundary. Policy has to sit in the path of the work.
Kastra
Governing agents before they act instead of auditing after the fact is the shift I've been hoping for.
Kastra
Kastra
@charlos_brat Exactly! And the nicest part is it isn't either/or. Every decision Kastra makes before an action runs is written to a tamper-evident, per-tenant hash-chained decision log, so the "audit after the fact" is just the other face of governing before it. And because it's chained, you can prove nothing was altered or dropped. There's a chain-verification API an auditor runs, not a log file you take on faith.
Congrats team! 🚀 Runtime authorization before execution is the piece most agent stacks are missing, and covering Claude Code, Cursor, and both major SDKs from one control plane is a smart wedge. Quick technical question: how do you intercept actions across such different runtimes? Is it a proxy sitting between the agent and its tools, SDK-level hooks, or MCP middleware? Curious whether an agent could bypass enforcement by shelling out directly, and how Kastra closes that gap. Excited to dig into the docs!