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.
Runtime authorization is the missing layer for coding agents. Prompt rules and post-action logs are useful, but they do not help much once an agent has already touched prod or leaked data.
The part I’d want to understand is policy authoring. For a team using Claude Code and Cursor heavily, do policies start from templates, scanned risky actions, or does each org end up writing a lot of custom rules by hand?
Kastra
@aditya_harish_2002 @carlosjimenez1 A follow-up on the plain English custom rules: can those be authored and enforced entirely on the open-source runtime, or does that need the commercial control plane? I am trying to work out what the self-hosted path covers on its own.
@carlosjimenez1 @alieksia curious about the self-hosted path here too. If plain English rules can be authored and enforced fully in the open-source runtime, that makes the OSS story much stronger. If the commercial control plane is mainly for team-wide management, auditability, and admin workflows, that distinction would be useful to spell out.
Kastra
@aditya_harish_2002 @alieksia The runtime itself is commercial and can enforce policies entirely self-hosted. Plain-English policy authoring is part of the commercial control plane; the Pro and Teams plans have this feature. It generates and manages the deterministic policies that the runtime enforces based on your plain English input. We wanted to keep the enforcement engine independent, while the control plane provides the developer experience and operational tooling for managing policies at scale.
Kastra
@carlosjimenez1 Thanks, that is clear.
Kastra
What I like here is the scope, one control plane across Claude Code, Cursor, Codex and OpenClaw. I've juggled separate configs for each tool before, and it's a mess nobody talks about enough.
Kastra
Love the recon scan to know all the unexpected/dangerous things Claude Code has done in the past. Some things I already knew but it caught some others I didn't know about it. And with automatic policy generation I don't need to worry about it messing up again!
Kastra
@churds Exactly, Richard, this gives you a baseline of policies that adjust to your coding behavior first. Then, once you have this baseline, you can build new daily policies on top of them to continue reducing risks you learn along the way. Some Recon scans from our customers show many important high-risk actions they were not aware of; some thought they were protected with their existing frameworks, and the reality was different.
Kastra
@churds Happy Recon could help, Richard!
How does kastra prevent prompt injection attacks where an agent attempts to bypass tool parameters by obfuscating CLI commands? huge congrats for shipping 🙌@carlosjimenez1
Kastra
@carlosjimenez1 Got it, thanks for the insight really like the deterministic policy approach.
Kastra
Thank you Vikram!
Carlos — "authorization doesn't carry over because the parent action was allowed" is the detail that got me. WinBidIQ's agent reads all kinds of docs — a public RFP one minute, a client's confidential pricing sheet the next. Does Kastra gate by action type only, or can policy also key off how sensitive the actual content is?
Kastra
@medal411 It depends on the kind of content. For things that can be detected deterministically, like API keys, secrets, certificates, and credentials, yes. You can write policies that block them before they ever reach the AI provider, so the data is never exposed. For something like an RFP or a private spreadsheet, it depends on the context, and in some cases you can write custom policies to catch it, but that's a harder problem and less reliable than the deterministic cases.
Kastra
@medal411 Great question! It's not just based on the action type. Policies can also evaluate the execution context, including things like data classification, the resource being accessed, the environment, the tool being used, and other attributes relevant to the request.
So, for example, reading a public RFP and exporting a client's confidential pricing sheet could follow completely different policies, even if the agent is using the same tool. The authorization decision is based on the full context of the action, not just the action itself.
That's one of the reasons we think every action should be evaluated independently rather than inheriting trust from what came before.
Congrats on the launch. Runtime authorization for agents is a strong direction because the risk usually appears after the model decides to act. How do teams define the boundary between low-risk actions that can run automatically and sensitive actions that need explicit approval or audit?
Kastra
Kastra
Thank you for the support@yaroslav_stelmakh!
Manufact (mcp-use)
Congrats on the launch @carlosjimenez1 🎉🎉🎉
I think that runtime authorization is the right place to sit. Most teams stuff guardrails into the system prompt but enforcing before the action executes is the only version that actually holds up in production!
Kastra
@carlosjimenez1 @pederzh Yes, exactly that! The system prompt is a suggestion, the enforcement layer is the guarantee. Thanks for the support! 🙏
Kastra
@pederzh Thank you, Luigi; you are totally right. This is a new problem that just became more relevant with autonomous AI systems. This authorization layer will continue to drive most of the trust required in these AI systems when touching production, scalable but still controlled by humans.