Customer.ioAutomate Messaging Everywhere — Startups Get 12 Months Free
Promoted
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.
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.
Dial
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
Checking shell commands and tool calls before they run is the part that clicks for me. The local policy checks and scan of past agent activity make this feel practical, not just another monitoring dashboard.
Kastra
@adriancia Thanks! That was exactly our goal. We wanted to move from observing what agents did after the fact to deterministically deciding what they're allowed to do before they execute. The scan is there to make creating those policies much easier.
minimalist phone: reduce your screentime
So basically it prevents to disasters made by AI agents?
Kastra
@busmark_w_nika Exactly! No accidental file deletions, dropped database tables, emails sent to the wrong people, and so on. Kastra stops those actions before they execute, rather than reading about them in the logs afterward.
minimalist phone: reduce your screentime
@fernando_vintacourt That's cool, at least it will prevent some unsolicited charges that would ai agent do with the card :D
Kastra
@busmark_w_nika That's exactly the goal. AI agents are incredibly capable, but they can also make high-impact mistakes when given real autonomy. Kastra evaluates every action before it executes and enforces deterministic policies, so instead of discovering a destructive action after it happens, you can prevent it, require approval, or allow it based on your own rules. Think of it as an authorization layer for AI agents; you decide what they're allowed to do before they do it.