Kastra
Runtime authorization for Claude, Cursor, Codex and OpenClaw
737 followers
Runtime authorization for Claude, Cursor, Codex and OpenClaw
737 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.
Congrats on the launch. Deciding before the action executes, rather than reviewing what already happened, is the right place to sit.
The thing I would want as a builder is every denial landing as a structured event I can line up with the agent's own trace. When an agent quietly stops making progress, the hardest case to debug is not knowing whether it hit a policy or just reasoned itself into a dead end. If the authorization decision and the step that triggered it share an id, that is a five minute answer instead of an afternoon.
Kastra
@paul_crinigan Thanks! We think that's a key part of the developer experience. Every authorization decision includes structured metadata and a request ID so it can be correlated with the agent's execution trace. When something stops, you should be able to answer "was this a policy decision or an agent decision?" in minutes, not hours.
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
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!