Kastra

Finally something that treats agent permissions like a real problem. The sub-1ms latency claim seems legit - I didn't notice any lag in tool calls when I tested it with Claude Code.

Congratulations on your launch! This feels like the missing piece for regulated AI adoption. Enterprise‑ready - control, neutral, deterministic, and fast.

Runtime authorization for coding agents is something I didnt know I needed till now. Using OpenClaw quite a bit and the permission layer is always something I have to handle manually. Nice solve

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.

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.

How does kastra prevent prompt injection attacks where an agent attempts to bypass tool parameters by obfuscating CLI commands? huge congrats for shipping 🙌@carlosjimenez1

The deterministic claim holds right up until the tool is generic.Denying delete_file or write_prod is the easy case, because the intent sits in the tool name and you can rule on it in under a millisecond. But a coding agent needs a shell. Once bash or run_command is permitted, the dangerous action stops being a tool call and becomes an argument string, and the engine is no longer authorizing an action, it is parsing arbitrary shell to predict one. That is the part that cannot be made deterministic.It is also where the real incidents will come from, because nobody takes the terminal away from the agent. They deny it the scary sounding tools it was never going to reach for anyway.How does a policy express that boundary? Can you constrain inside a permitted generic executor, or does allowing bash effectively allow everything downstream of it?

This is the kind of infrastructure that won't get the loudest headlines, but could become a core part of every serious AI stack. As agents gain more autonomy, authorization becomes just as important as intelligence. Congrats to the entire team and wishing you an amazing launch

Carlos, the deterministic engine is the part that matters for my world. I sell AI into healthcare, and "the agent usually behaves" is not a line you can put in front of an auditor or a BAA, since a probabilistic guardrail is a suggestion while a deny decision in the execution path is a real control.Where I would push: preventing exposure of sensitive data assumes you can recognize it first. Is a policy written against the tool or endpoint, or can it key off the content itself, say a rule that blocks any output carrying patient identifiers no matter which tool produced it?And does every allow or deny land in an audit trail I can hand to a compliance review? In regulated work, proof that the control fired is worth as much as the control.

Hi PH. I'm Carlos. Fernando and I built Kastra.Here's what kept happening. We'd deploy AI agents in real environments: a coding agent, a support agent, and an infra agent. It had credentials and access, and there was nothing structural stopping it from running any action it decided to take, even in production.Most teams have authentication, logging, monitoring, and evals. Almost none have a layer that decides "this specific action cannot execute" before it executes. The controls that exist look at what the agent already did. We wanted something that decides on the input and output to cover most of the execution level risks. This required a new infra layer for autonomous AI around the authorization angle.That's Kastra. Every agent action is evaluated against policy and gets an allow or deny decision in under a millisecond. When something needs a human review, that approval now completes in about a second, across our desktop app, web console, and macOS notifications. We reduce that number down every week, and it changes how the product feels. Sub 1ms latency means human-in-the-loop authorization is practical, not theoretical. Kastra is neutral and deterministic across the stack and works with the tools you already use.We integrate via 1 click to Claude Code, Codex, OpenClaw, and Cursor, and other regulated enterprise use cases right now. The runtime and policy pack library are open source. The enterprise control plane is commercial. The product is free to try, if you are wondering if you need Kastra run these 2 commands below on your coding agent to scan for potential risks your agent has already done that should have policies built. Everything stays locally on your machine, so you can do this safely.Run "brew install kastra-labs/tap/kastra-edge" and then once connected to your account, you can run "kastra-edge scan".Happy to go into the policy engine architecture, the latency story, how we think about fail-open vs. fail-closed, probabilistic vs deterministic rules, or anything else. We'll be in the comments all day.Carlos & Fernando