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.
the part that keeps me from letting my coding agents run fully unattended is exactly this. they will happily do something you didn't want and you only find out after the fact. a layer that decides no before the action runs is the piece i keep wishing i had. how granular can the policies get per tool?
Kastra
@terminal_candy very granular. Kastra sits in front of the action (a pre-tool hook for Claude Code / Codex / Cursor, or the LLM proxy), so every tool call is evaluated before it executes. A rule can target:
A specific tool: exact name, a list of tools, or a regex (e.g. only Bash, or every mcp__* tool).
The tool's arguments: substring, multi-substring, or regex conditions over the tool input (e.g. block Bash when the command contains rm -rf or git push --force; block Write when the file path matches .env). On the proxy path, arguments are flattened per field (output.tool_call.arguments.<key>), so you can match one named argument in isolation.
The context around the call: working directory, git repo/branch/dirty state, session, OS, agent permission mode, environment (dev/prod), model, principal/agent identity, data classification.
Content: built-in scanners (secrets, PII) can run over the tool input or model output with confidence/count thresholds.
And "no" isn't the only answer. Each rule chooses its effect: hard deny, hold (pause the agent and page a human to approve, with a timeout that fails open or closed, your choice), monitor (allow but flag), redact, rate-limit, or spend-cap.
The sub-1 ms policy decision is the detail that caught me. Agent approvals usually feel bolted-on once latency shows up. Curious how teams debug a denied action — do they get a readable policy trace?
Kastra
@xiaosong001 Yes, every denied action includes a readable decision trace showing which policy matched, why it matched, the relevant action context, and the resulting decision. Teams can see the exact shell command, tool call, arguments, environment, and rule that triggered the denial, then adjust or version the policy from there.
The goal is for a denial to feel debuggable, not like a black box.
Interesting approach. I lead a data platform team and agent authorization is exactly the gap we keep running into when letting coding agents touch production-adjacent systems. Does Kastra support scoping per-tool permissions, or is it per-session? Congrats on the launch!
Kastra
@piyanat_saphiman Thank you! That's exactly the type of workflow we built Kastra for. Yes, permissions can be scoped far beyond the session. Policies can target specific tools, shell commands, file paths, Git operations, databases, APIs, users, environments, and even the arguments passed to each action. The goal is to give teams deterministic control over what an agent can do, not just who started the session.
Runtime authorization for agents is a problem I didn't appreciate until I started building AI tools that take real actions (creating records, modifying data, triggering workflows). The trust boundary question is hard — how granular does Kastra get? Can you scope down to specific fields/operations, or is it more at the API-call level?
Kastra
@rachid_abadli Thanks! We had the same realization once agents started interacting with real systems.
Kastra is designed to be quite granular. Policies aren't limited to the API-call level; they can evaluate the operation being performed, the tool being used, the arguments passed, the user, environment, and other request context before deciding whether to allow, deny, or require approval. That lets you write policies that are much more specific than "this agent can call this API." Our goal is to give developers deterministic control over the actions an agent can take, regardless of which coding agent they're using.
Infrastructure products often become invisible when they're doing their job well.
Curious—do developers initially adopt Kastra for security, or do they end up valuing the confidence it gives them to move faster?
Kastra
@aryan787544 Great question. We've found it's usually both, but the initial motivation depends on the team.
Some adopt Kastra because they need stronger security and governance. Others simply want the confidence to give AI more autonomy without worrying about costly mistakes. Long-term, that's the outcome we're aiming for: developers can move faster because they trust the guardrails, instead of slowing down to constantly supervise their agents.
how granular do the policies get in practice - is it more like broad allow/deny categories per tool, or can you actually write a rule like "deny this specific SQL write pattern but allow reads"? asking because the false positive rate on anything doing semantic judgment on agent intent tends to be the real blocker to running this in prod, not the latency.
Kastra
@omri_ben_shoham1 Yes, exactly, you can be very specific about what you want to block. For example, you can create a policy to block all write/destructive operations on a specific table. Just type what you want, like "Block all write operations on the users table," and Kastra will create the policy for you.
The important line here is "before actions execute." For teams using agents around real repos or customer systems, post-hoc logs are useful but they are not a control boundary. Policy has to sit in the path of the work.
Kastra