Show HN: Korveo – a local firewall for AI agents

[amitbidlan]

I got really tired of giving artificial intelligence agents access to tools. Then I had no idea what they were actually doing.

So I created Korveo.

Korveo runs on your computer between your agent and its tools.

Here is what Korveo does:

1. Korveo records every single tool and application programming interface call that the agent makes

2. Korveo lets you replay the sessions like a recording of a flight

3. Korveo blocks behavior right away like when the agent tries to leak data or connect to a bad host or when it tries to mix up information from different sessions

All of Korveos work happens on your computer. There is no cloud involved. You do not need to make an account. Everything that Korveo does stays on your machine.

Korveo is still a thing so there are some issues.

For example:

1. The language that Korveo uses to make rules is not good

2. Korveo does not work well with all frameworks

3. Korveo is not a space to test an agent that has been fully compromised

But even with these issues Korveo is already useful if you are working with autonomous agents and you want to see what they are doing and you want to make sure they do not do anything bad.

I would really like to hear your thoughts, on Korveo.

[amitbidlan]

Sorry,I took out two things from the main post to make it shorter.

1. The reason I like local-first is that I do not want logs from tools and agents going to some company.

With DuckDB everything stays on your system so you have control over it.

2. I want to be honest about something. Korveo is between the agent and the tools it uses.

If the agent itself is compromised it can still get around Korveo.

So Korveo is, like a guard that helps keep things safe. It also keeps a record of what happens.

It is not a solution but it helps.

I am happy to talk about how Korveo works with policies or how it supports certain frameworks if people want to know more about Korveo.

[rechannel]

The replay thing is what got me. Most of these tools just block stuff and leave you guessing why an agent did what it did. You mentioned the rule language isn't great — what's tripping you up on it?

[amitbidlan]

Glad the replay clicked for you. Honestly that was the thing I built before blocking, because I kept looking at agent failures with basically no clues.

The trace view also made the firewall work well in practice: you can promote rules from a real captured call instead of guessing everything upfront in YAML.

There are still three things in the policy model that need work:

1. Cross-call behavior is a bit clumsy.

A single rule sees one tool call, but the failures you actually care about are sequences — exfiltration, cross-session bleed, "agent read a secret then called an external host." Right now I express that with chained rules and tags, and it feels hacky. I want a way to handle sequences and stateful flows.

2. The matching model isn't consistent.

Host allowlists, argument matching, and payload predicates developed separately, so parts of the syntax feel different. New users hit this issue quickly.

3. Deny explanations are not clear.

Right now you mostly get "rule X blocked this." I want explanations like "blocked because arg.url matched Y and host wasn't allowed." Without that, debugging in shadow mode isn't as useful as it should be.

If anyone here has built policy systems or rule engines — especially around stateful rules without turning the whole thing into a programming language — I'd love to hear how you handled it.