Launching today
Kastra
Runtime authorization for Claude, Cursor, Codex and OpenClaw
299 followers
Runtime authorization for Claude, Cursor, Codex and OpenClaw
299 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.
Kastra
Hi PH. I'm Carlos. Fernando and I built Kastra.
Here's what kept happening. We'd deploy AI agents in real environments: a coding agent, a support agent, and an infra agent. It had credentials and access, and there was nothing structural stopping it from running any action it decided to take, even in production.
Most teams have authentication, logging, monitoring, and evals. Almost none have a layer that decides "this specific action cannot execute" before it executes. The controls that exist look at what the agent already did. We wanted something that decides on the input and output to cover most of the execution level risks. This required a new infra layer for autonomous AI around the authorization angle.
That's Kastra. Every agent action is evaluated against policy and gets an allow or deny decision in under a millisecond. When something needs a human review, that approval now completes in about a second, across our desktop app, web console, and macOS notifications. We reduce that number down every week, and it changes how the product feels. Sub 1ms latency means human-in-the-loop authorization is practical, not theoretical. Kastra is neutral and deterministic across the stack and works with the tools you already use.
We integrate via 1 click to Claude Code, Codex, OpenClaw, and Cursor, and other regulated enterprise use cases right now. The runtime and policy pack library are open source. The enterprise control plane is commercial. The product is free to try, if you are wondering if you need Kastra run these 2 commands below on your coding agent to scan for potential risks your agent has already done that should have policies built. Everything stays locally on your machine, so you can do this safely.
Run "brew install kastra-labs/tap/kastra-edge" and then once connected to your account, you can run "kastra-edge scan".
Happy to go into the policy engine architecture, the latency story, how we think about fail-open vs. fail-closed, probabilistic vs deterministic rules, or anything else. We'll be in the comments all day.
Carlos & Fernando
Cross-framework support is huge. Claude Code, Cursor, Codex, one policy layer, that's rare.
Kastra
@sulemna_ola Our neutral enforcement engine across models and agentic systems enables us to enforce the same rules throughout the stack. We want to enhance how you use the tools you love, not replace them.
Kastra
@sulemna_ola Yes, and we are adding support for more tools every day! Thank you!
What I like here is the "trust the rules, not the agents" framing. It flips the usual assumption that agents will behave if you prompt them nicely enough. They won't always.
Kastra
@nancy_philip Exactly, we have seen our users want to customize the rules that adjust to their agentic coding style. We allow them to do so; at scale, this helps build trust, and trust allows them to delegate more work to their coding agents.
Kastra
@nancy_philip Exactly, only a deterministic, neutral layer can enforce this.
I've watched teams try to solve this with prompt engineering alone, telling the agent what it's allowed to touch and hoping it listens. That's not authorization, that's a suggestion. What Kastra seems to be doing is treating agent permissions the way we already treat API permissions, with enforced rules instead of good intentions. Overdue shift.
Kastra
@ramish_saje Yes, the prompt engineering rules/policies are often probabilistic approaches that can't be guaranteed to work 100% of the time. There is a margin of error that some engineers and enterprises can't take the risk of "trusting". That is why we built our engine fully deterministic, so we can build these rules for every custom angle but make sure the highest-risk actions are avoided before they happen. What exists in the market is mostly post-action observability and monitoring, which is insufficient for autonomous AI.
Genuinely curious how the policy engine handles nested tool calls, where one authorized action triggers a second unauthorized one downstream.
Kastra
@steven_granata Great question. We evaluate every execution independently, not just the initial request.
If an authorized action triggers additional tool calls, each downstream action is intercepted and evaluated against the same policy engine before it executes. Authorization doesn't "carry over" simply because the parent action was allowed.
Sensitive data exposure prevention baked into the control plane, not bolted on afterward. That's the correct order of operations.
Kastra
@peter_victor That's exactly the philosophy behind Kastra. We believe authorization should sit directly in the execution path, where every tool call, shell command, API request, and file operation can be evaluated before it executes rather than remediated afterward.
you mentioned fail-open vs fail-closed as something you're happy to dig into, so - what's the actual default when the Kastra runtime itself is unreachable or crashes mid-decision? fail-closed sounds obviously "safer" on paper but in practice that just turns your authorization layer into a single point of failure that can halt production agents. is that a global setting, or does it vary per policy depending on how risky the action is?
Kastra
@galdayan This is a great point. We learned from enterprise conversations that policies needed to be tested per environment for high-frequency authorizations in order to be trusted by large companies that could not have a single point of failure.
So we enabled these fail-open and fail-closed features so every integration can be tested and evaluated before launching to production to make sure the risk of the integration was minimal. Think of it as sandboxing policies in a custom environment: one mode logs every decision without blocking, and the other one logs and blocks them. This can be switched on the dashboard at any time once the customer is ready. The interception and enforcement engine works just the same with every authorization.