Viktor.comAn AI coworker that actually does the work
Promoted
Kastra
Runtime authorization for Claude, Cursor, Codex and OpenClaw
800 followers
Runtime authorization for Claude, Cursor, Codex and OpenClaw
800 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.
Kastra
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
Bhava
@carlosjimenez1 Kastra is tackling a problem that becomes more urgent every time AI systems gain another tool: deciding what they are allowed to do before the action runs.
What I liked most is how concrete the product makes that idea. Prompts, shell commands, DB writes, API calls, policy matches, and allow/deny decisions are all explained without turning the experience into a wall of security language.
I also walked through the fresh-account setup. The interface is polished and the install path is thoughtful. My one suggestion would be to make the first verified authorization result the unmistakable finish line. Once the device is connected and one decision is visible, plan and team expansion will have much more context.
Strong product, sharp category, and a very considered launch. Congrats to the team.
Kastra
@riya_jawandhiya Thank you for the feedback and support!
I've watched teams try to solve this with prompt engineering alone, telling the agent what it's allowed to touch and hoping it listens. That's not authorization, that's a suggestion. What Kastra seems to be doing is treating agent permissions the way we already treat API permissions, with enforced rules instead of good intentions. Overdue shift.
Kastra
@ramish_saje Yes, the prompt engineering rules/policies are often probabilistic approaches that can't be guaranteed to work 100% of the time. There is a margin of error that some engineers and enterprises can't take the risk of "trusting". That is why we built our engine fully deterministic, so we can build these rules for every custom angle but make sure the highest-risk actions are avoided before they happen. What exists in the market is mostly post-action observability and monitoring, which is insufficient for autonomous AI.
Genuinely curious how the policy engine handles nested tool calls, where one authorized action triggers a second unauthorized one downstream.
Kastra
@steven_granata Great question. We evaluate every execution independently, not just the initial request.
If an authorized action triggers additional tool calls, each downstream action is intercepted and evaluated against the same policy engine before it executes. Authorization doesn't "carry over" simply because the parent action was allowed.
Sensitive data exposure prevention baked into the control plane, not bolted on afterward. That's the correct order of operations.
Kastra
@peter_victor That's exactly the philosophy behind Kastra. We believe authorization should sit directly in the execution path, where every tool call, shell command, API request, and file operation can be evaluated before it executes rather than remediated afterward.
you mentioned fail-open vs fail-closed as something you're happy to dig into, so - what's the actual default when the Kastra runtime itself is unreachable or crashes mid-decision? fail-closed sounds obviously "safer" on paper but in practice that just turns your authorization layer into a single point of failure that can halt production agents. is that a global setting, or does it vary per policy depending on how risky the action is?
Kastra
@galdayan This is a great point. We learned from enterprise conversations that policies needed to be tested per environment for high-frequency authorizations in order to be trusted by large companies that could not have a single point of failure.
So we enabled these fail-open and fail-closed features so every integration can be tested and evaluated before launching to production to make sure the risk of the integration was minimal. Think of it as sandboxing policies in a custom environment: one mode logs every decision without blocking, and the other one logs and blocks them. This can be switched on the dashboard at any time once the customer is ready. The interception and enforcement engine works just the same with every authorization.
@carlosjimenez1 that sandboxed test-per-environment approach makes sense, letting a team see the blocked-vs-would-have-blocked delta before flipping the switch in prod is a much better onboarding path than asking them to trust it blind on day one. good luck with the launch.
Kastra
I've been burned by an agent calling a tool it shouldn't have. A pre-execution control plane like this feels overdue, honestly.
Kastra
@grayson_carter3 Yes, this is a very common problem. We've heard similar stories from a lot of developers over the past few months. As agents become more autonomous, trusting them isn't enough; you also need deterministic guardrails around what they're allowed to do. That's the gap we set out to solve with Kastra.
Meridian
@grayson_carter3 Same here. The risky part with agents is that one wrong tool call can have real side effects before anyone notices.
Pre-execution authorization feels like the right layer for this, especially when it works across coding agents instead of depending on each tool to behave perfectly. Runtime guardrails are going to become a basic requirement as these agents get more autonomy.
Kastra
@grayson_carter3 @akarsh_hegde Exactly, that's the problem we kept running into as well. Once an agent has permission to use tools, a single shell command, SQL query, or API call can have real consequences. Our view is that the decision should happen before the action executes, with deterministic policies that are consistent across coding agents rather than relying on each one to implement its own guardrails. Really appreciate the thoughtful comment!
"Trust the rules, not the agents" is the correct instinct, because prompting for good behavior stops working the second the input is adversarial. The part I would dig into is authoring: a policy engine is only as useful as people's ability to write and test rules without breaking their own agents, so can I dry-run a new policy against past runs before it starts blocking things live? And when Kastra denies an action, is that decision logged with its reason in a form I could hand an auditor later? Blocking is table stakes. The defensible record of why is where this earns its place in the stack.
Kastra
Kastra
@cmumulle both are things we leaned into, so good ones to land on.
Dry run against past runs, yes, literally. You can replay your stored decisions through the candidate policy and diff against what actually happened. You get would-flip counts (how many past ALLOWs become DENYs and vice versa) plus concrete samples, before it's ever active.
Shadow mode is the forward-looking half: publish a policy in shadow and it evaluates live traffic, records what it would do, and enforces nothing, so you watch the block rate on real traffic before flipping to enforce. One honest limit: pre-inference rules (tool calls, commands) replay exactly, but rules matching raw prompt content don't, since we store prompts only hashed. Those you validate in shadow rather than by replay.
The defensible record, yes. Every evaluation, denies included, is a persisted decision row: the outcome, the exact rule that matched and its reason, plus tenant, environment, model, and timestamp. The log is per-tenant hash chained (HMAC-SHA256 fingerprint plus linked sequence), so it's tamper evident, with a chain verification API an auditor runs to prove nothing was altered or dropped. From there it exports as framework-scoped evidence packs (SOC 2, HIPAA, GDPR, EU AI Act) or plain CSV/JSON, plus a read-only auditor role with shareable evidence links. So you hand over the "why," not just the "no," which is exactly the part you're pointing at.