Launched this week
Kastra
Runtime authorization for Claude, Cursor, Codex and OpenClaw
818 followers
Runtime authorization for Claude, Cursor, Codex and OpenClaw
818 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.
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.
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.
@carlosjimenez1 that makes sense, scoping by context instead of a flat rule scan is the sane way to keep it fast as the policy set grows. Good luck with the launch, will be keeping an eye on this!
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.
Congrats on the launch. The "trust the rules, not the agents" framing is the right instinct — we've landed on the same philosophy internally. One thing I'm curious about: when a policy check fails, is deny the only outcome, or can a policy route the action to a human approval queue instead? In practice I've found agents need three outcomes, not two — allow, deny, and "a human decides this one." Sub-1ms is impressive for the allow path; wondering what the escalation path looks like.
Kastra