Kastra

Runtime authorization for Claude, Cursor, Codex and OpenClaw

Developer Tools

Artificial Intelligence

GitHub

Security

Visit WebsiteSee on Product HuntTwitter ⧉Instagram ⧉

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?

The output-side check is the half most policy layers skip — gating on the agent's output before it executes, not just the input. Two things I'd wire-test first in a coding-agent loop: is the sub-1ms decision in-process/local, or a network hop to your control plane (which changes the latency math mid tool-call)? And when a policy can't reach a verdict in time, do you fail-closed by default, or is that configurable per-policy?

Shell is where I'd expect this to get hard. Our own gate covers browser writes and it holds up because the surface is tiny, a selector and a URL allowlist. Once the agent has a terminal the dangerous action stops having a name: it isn't rm, it's a git checkout that throws away an hour of work, or python -c doing whatever it likes. Does the engine evaluate the tool call and its arguments as a string, or do you parse the command, and what happens with bash -c and heredocs?

Congrats on the launch @carlosjimenez1 🎉🎉🎉

I think that runtime authorization is the right place to sit. Most teams stuff guardrails into the system prompt but enforcing before the action executes is the only version that actually holds up in production!

Congrats on the launch. Runtime authorization for agents is a strong direction because the risk usually appears after the model decides to act. How do teams define the boundary between low-risk actions that can run automatically and sensitive actions that need explicit approval or audit?

@carlosjimenez1 congrats on the launch ! I'm curious how the sub-1ms number holds up as policy count grows. Is that benchmark against a handful of rules? or does latency stay flat once a team has been customizing dozens or hundreds of overlapping policies over time?

"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.

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.