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