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.
"Trust the rules, not the agents" is the correct instinct, because prompting for good behavior stops working the second the input is adversarial. The part I would dig into is authoring: a policy engine is only as useful as people's ability to write and test rules without breaking their own agents, so can I dry-run a new policy against past runs before it starts blocking things live? And when Kastra denies an action, is that decision logged with its reason in a form I could hand an auditor later? Blocking is table stakes. The defensible record of why is where this earns its place in the stack.
Kastra
Kastra
@cmumulle both are things we leaned into, so good ones to land on.
Dry run against past runs, yes, literally. You can replay your stored decisions through the candidate policy and diff against what actually happened. You get would-flip counts (how many past ALLOWs become DENYs and vice versa) plus concrete samples, before it's ever active.
Shadow mode is the forward-looking half: publish a policy in shadow and it evaluates live traffic, records what it would do, and enforces nothing, so you watch the block rate on real traffic before flipping to enforce. One honest limit: pre-inference rules (tool calls, commands) replay exactly, but rules matching raw prompt content don't, since we store prompts only hashed. Those you validate in shadow rather than by replay.
The defensible record, yes. Every evaluation, denies included, is a persisted decision row: the outcome, the exact rule that matched and its reason, plus tenant, environment, model, and timestamp. The log is per-tenant hash chained (HMAC-SHA256 fingerprint plus linked sequence), so it's tamper evident, with a chain verification API an auditor runs to prove nothing was altered or dropped. From there it exports as framework-scoped evidence packs (SOC 2, HIPAA, GDPR, EU AI Act) or plain CSV/JSON, plus a read-only auditor role with shareable evidence links. So you hand over the "why," not just the "no," which is exactly the part you're pointing at.
I've been burned by an agent calling a tool it shouldn't have. A pre-execution control plane like this feels overdue, honestly.
Kastra
@grayson_carter3 Yes, this is a very common problem. We've heard similar stories from a lot of developers over the past few months. As agents become more autonomous, trusting them isn't enough; you also need deterministic guardrails around what they're allowed to do. That's the gap we set out to solve with Kastra.
The line I keep going back to is "approval now completes in about a second".
We run an approve-before-send step on the support side, and latency was never what broke it. Attention was. While the queue is short people actually read what they are approving. Once it gets long they stop reading and start clicking, and you have a human in the loop on paper but not in practice. Making approval fast is good, but it also makes it cheap, and cheap approvals get rubber-stamped.
I have never solved this properly, so genuinely asking: does the console show time-to-decision, not just allow/deny counts? A median of 0.4s across 200 approvals a day, and the same allow rate across 20, are two very different situations and only one of them is human-in-the-loop.
One smaller thing, and it may be out of scope for an authorization layer: the approver sees the action and the policy that matched. What usually decides whether an action should run is what the agent read three steps earlier. Do you carry any of that into the approval prompt?
Kastra
@carlosjimenez1 Hold as the exception rather than the default is the right shape, and carrying the execution context into the prompt is further than I expected you to be. Good answer.
I asked the metric question badly though. I did not mean your latency, that part is clearly solved. I meant the human's: how long the person sat on a Hold before clicking allow. Your side is sub-1ms, their side is the one that quietly decays. If a team's median goes from 8s to under 1s over a month, the policy set has probably drifted too broad and Hold is firing on things that should be Allow. You are the only ones who can see that, since you own both ends of the decision.
Not asking you to build it. It is just the number I would want to watch.
Kastra
@carlosjimenez1 @jernej_jan_kocica Yes, it's an excellent metric. Too many Holds get normalized by the team, and people start clicking Allow on autopilot. We can measure this: since we own both ends of the decision, we see the time between a Hold firing and the human resolving it, and when that number starts dropping we can flag that the policy has drifted too broad and suggest where to tighten it. Thank you for the suggestion!
@carlosjimenez1 @fernando_vintacourt Flagging the drop rather than the absolute number is the right read. The absolute number means nothing without that team's own baseline, a 3s median can be attentive on one team and autopilot on another.
The 3 minute auto-reject is the one I would watch next to it. A Hold nobody feels able to decide shows up as a timeout, not as a slow approval, so those are two different failures sitting in the same bucket if you do not split them.
Good luck with the rest of the launch.
Carlos, the deterministic engine is the part that matters for my world. I sell AI into healthcare, and "the agent usually behaves" is not a line you can put in front of an auditor or a BAA, since a probabilistic guardrail is a suggestion while a deny decision in the execution path is a real control.
Where I would push: preventing exposure of sensitive data assumes you can recognize it first. Is a policy written against the tool or endpoint, or can it key off the content itself, say a rule that blocks any output carrying patient identifiers no matter which tool produced it?
And does every allow or deny land in an audit trail I can hand to a compliance review? In regulated work, proof that the control fired is worth as much as the control.
Kastra
The deterministic claim holds right up until the tool is generic.
Denying delete_file or write_prod is the easy case, because the intent sits in the tool name and you can rule on it in under a millisecond. But a coding agent needs a shell. Once bash or run_command is permitted, the dangerous action stops being a tool call and becomes an argument string, and the engine is no longer authorizing an action, it is parsing arbitrary shell to predict one. That is the part that cannot be made deterministic.
It is also where the real incidents will come from, because nobody takes the terminal away from the agent. They deny it the scary sounding tools it was never going to reach for anyway.
How does a policy express that boundary? Can you constrain inside a permitted generic executor, or does allowing bash effectively allow everything downstream of it?
Kastra
@carlosjimenez1 That is the answer I was hoping for, and it moves the question down a level rather than closing it.
Inspecting the command and its arguments works when the dangerous thing is visible in the string. The cases I would worry about are the ones where it is not. A base64 blob piped to sh, a curl to a URL that is fine today, a variable resolved from the environment at run time, a script the agent wrote to a file one step earlier and now executes by path.
In all of those the literal argv is harmless and the effect is not, so the check either resolves the indirection or it is matching on surface text.
Where does Kastra draw that line?
Kastra
@abdullah_javaid3 This is the part we spent the most time on, so it's fun to talk about.
The principle we settled on: a command check should judge what's written, not predict what will happen. Reading argv is decidable; predicting the effect of arbitrary shell isn't. The line sits there.
On the readable side, matching anchors on the operation rather than its spelling. The same rm -rf trips whether the binary is path-qualified (/bin/rm -rf) or the flags are reordered (rm -fr), across every surface the agent uses.
Your four cases sit on the other side, where the string is honest but the effect is hidden: base64 | sh encodes the payload, $VAR resolves only at expansion, a safe URL can turn hostile later, and write-then-run splits intent across two calls. We don't claim to see through that, what covers it isn't a smarter parser but a different control: high-blast-radius operations get a hold and a human regardless of how the string reads, and every executed call lands in a tamper-evident, hash-chained audit log, so what we can't decode up front is still recorded and provable after.
@fernando_vintacourt Fair split, and the hash chained log is the right backstop. The part I would push on is that it is a different class of control than the tagline promises.
A log is detection. It proves what happened after the credential was already spent. Prevention is what stops the call. So for the four opaque cases you are not preventing, you are recording, and those two things sell to different buyers with different risk appetites.
Which puts all the weight on the blast radius classifier. If it rates the command, opacity beats it, because you cannot rate the radius of a payload you cannot decode. If it rates the context instead, prod credentials in scope, egress allowed, write access outside the workspace, then opacity stops mattering and the guarantee survives.
Which is it? And does an undecodable construct escalate on its own, or does it pass when the surrounding context looks ordinary?
Shell is where I'd expect this to get hard. Our own gate covers browser writes and it holds up because the surface is tiny, a selector and a URL allowlist. Once the agent has a terminal the dangerous action stops having a name: it isn't rm, it's a git checkout that throws away an hour of work, or python -c doing whatever it likes. Does the engine evaluate the tool call and its arguments as a string, or do you parse the command, and what happens with bash -c and heredocs?
Kastra
@dipankar_sarkar You’re right, shell safety cannot be reduced to an executable allowlist. We evaluate the full invocation, not just the command name, and normalize/parse common command families so policies can reason about operations like destructive Git changes rather than only strings.
Opaque wrappers such as bash -c, python -c, heredocs, pipes, and chained commands are treated conservatively: they can be inspected recursively, held for approval, or denied. We also don’t pretend arbitrary shell code can always be perfectly understood statically, so downstream actions are authorized independently whenever they surface.
I've watched a few "AI firewall" products overpromise and underdeliver, so I'm cautiously optimistic rather than sold. What would actually convince me is seeing how this performs against a red-teamed agent trying to route around the rules, not just against a well-behaved one following the happy path.
Kastra