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.
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.
runtime authz is exactly the missing peice for agents 🔥 how granular do the policies get?
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?
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!
The "existing controls only look at what the agent already did" line is the real gap — logging and evals are post-hoc, and the irreversible action already happened by then. Sub-1ms allow/deny I buy. The piece I'd want to understand is what routes an action to human-review vs auto-allow, because that classification is the hard part: when I give Claude Code broad access the legit action space is huge and situational. Auto-deny runs brittle and breaks a real task mid-run; escalate too much and I rubber-stamp the ~1s approvals until I'm not really reviewing. Is that routing static rules on tool + args, or does it reason about intent against the current task? And input-layer injection — how do you flag the instruction that reads as a perfectly normal one inside a 1ms budget, without an LLM in the loop?
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?
The integrations with tools like Cursor and Claude Code caught my attention. Looking forward to testing this in a real workflow.
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.
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?
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.
congrats on hitting product hunt @carlosjimenez1 keeping dev velocity high while putting hard guardrails around shell commands is pure leverage.
This is the unglamorous layer everyone is about to need. The moment you let Claude or Codex actually run things, "what is this agent allowed to do right now" stops being a nice-to-have. Runtime is the key word for me. Static permissions are easy, but authorizing per action while the agent works is the hard part. How do you handle an agent that needs to escalate mid-task without a human sitting there approving every step?
Congrats on the launch. Deciding before the action executes, rather than reviewing what already happened, is the right place to sit.
The thing I would want as a builder is every denial landing as a structured event I can line up with the agent's own trace. When an agent quietly stops making progress, the hardest case to debug is not knowing whether it hit a policy or just reasoned itself into a dead end. If the authorization decision and the step that triggered it share an id, that is a five minute answer instead of an afternoon.
Congrats team! 🚀 Runtime authorization before execution is the piece most agent stacks are missing, and covering Claude Code, Cursor, and both major SDKs from one control plane is a smart wedge. Quick technical question: how do you intercept actions across such different runtimes? Is it a proxy sitting between the agent and its tools, SDK-level hooks, or MCP middleware? Curious whether an agent could bypass enforcement by shelling out directly, and how Kastra closes that gap. Excited to dig into the docs!
Really interesting approach to AI security. Instead of monitoring after something happens, preventing risky actions before execution feels like the right direction.
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?
About Kastra on Product Hunt
“Runtime authorization for Claude, Cursor, Codex and OpenClaw”
Kastra launched on Product Hunt on July 22nd, 2026 and earned 385 upvotes and 144 comments, placing #4 on the daily leaderboard. 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 was featured in Developer Tools (516.2k followers), Artificial Intelligence (474.3k followers), GitHub (41.3k followers) and Security (2.8k followers) on Product Hunt. Together, these topics include over 216.2k products, making this a competitive space to launch in.
Who hunted Kastra?
Kastra was hunted by Ben Lang. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how Kastra stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
Ben Lang
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