You asked a question, I gave you an answer. You can actually install it and run it with claude and the github MCP. You can also easily integrate it to OpenClaw.
not sure why you say this, if you don’t like it don’t use it, if you can create your own, do it, or just check the repo and try it, you might find it useful
Fair question. Yes, you can absolutely generate a basic proxy with an LLM, the gap is in the stuff that's hard to get right and boring to maintain. Policy hot-reload without dropping in-flight requests (ArcSwap, not "restart the process"). Tamper-evident audit with blake3 hash chains, not just append-only logs. Credential injection where the agent process literally never sees the secret, not env vars. Content inspection that runs bidirectionally without buffering entire responses into memory. Correct TLS MITM for the HTTP proxy mode with dynamic per-host certs. An LLM will generate something that works for a demo. We created 409 tests including property-based testing with proptest, because the failure modes in a security proxy are subtle, off-by-one in glob matching, race conditions in policy reload, Content-Length mismatches after redaction. Same reason, for example, you use nginx instead of asking your AI to write an HTTP server. The first 80% is easy. The last 20% is where credentials leak.
Yes! You are right about the three primitives and that's basically Bulwark's core loop.
On idempotency: right now Bulwark observes but doesn't enforce dedupe. Every request gets a unique event ID in the audit log, and you can see retries in the session timeline, but there's no automatic "this looks like the same create_issue call from 2 seconds ago, block it."
It's on the roadmap and I think it needs to be two things: (1) a configurable dedupe window per tool pattern (you want it for create_charge but not for list_issues), and (2) content-aware hashing so it's not just "same tool + same action" but "same tool + same action + same arguments within N seconds."
The tricky part is that some tools are intentionally non-idempotent, posting the same Slack message twice might be deliberate. So it probably needs to be opt-in per rule rather than global. Would love to hear what patterns you've seen cause the worst double-fires.