tonyww
Joined 10 months ago
Karma
37
Submissions
36
Member since
Dec 20
Recent submissions
Comment · 6 months ago
Browser use is a token hog
Comment · 8 months ago
AI agents currently operate on a flawed security model: they inherit the ambient permissions of the terminal they are spawned in. If an agent gets prompt-injected or hallucinates, a broad blast radius is guaranteed. I built predicate-claw to fix this. It’s a drop-in security plugin for OpenClaw, paired with a lightweight Rust daemon (predicate-authorityd). The core architecture is essentially defense-grade Run Time Assurance (RTA) applied to LLMs. Since you cannot formally verify a non-deterministic black box, you have to physically decouple the "brain" from the "actuators" and drop a hard-coded, deterministic gatekeeper in the middle. How it works:
The Interceptor: We hook into OpenClaw's before_tool_call execution loop. The LLM has no idea the security layer exists. The Sidecar Gate: The tool request is routed to the local Rust daemon, which evaluates the intent against a deterministic YAML policy (e.g., blocking rm -rf, allowing fs.read only in ./src). It fails closed by default. The TUI: The daemon ships with a terminal UI to monitor all agent requests, allows, and denies in real-time. I built this in Rust to get strict memory safety with <1ms of latency overhead. It compiles to a static binary and drops into existing projects with zero friction.
Link to GitHub Repo: https://github.com/PredicateSystems/predicate-claw
Demo (GIF): https://github.com/PredicateSystems/predicate-claw/blob/main...
We already use deterministic post-execution verification for our web agents (DOM snapshot diffing, strictly avoiding the 'LLM-as-judge' trap). Next on the roadmap is bringing that same verifiable state-hashing to the OS level. I’d love to hear your thoughts on the architecture and how you're currently handling local agent sandboxing. Note: If you aren't using OpenClaw, our core engine also supports Python frameworks like LangChain and browser-use in 3 lines of code.
You can read the full architecture and see our enterprise fleet management here: https://predicatesystems.ai/docs/vault
Comment · 9 months ago
Yeah, that’s a pretty good analogy.
The main difference is that the “tests” are predicates over live browser state and are often proposed alongside the plan on the fly, not written upfront by a developer. But conceptually it’s very close: make the expected outcome explicit, try an action, verify, and only move forward if the condition actually holds.
Comment · 9 months ago
Absolutely agree on the compounding error point - that’s exactly what pushed us toward verification.
On “verification wrong”: we try hard to keep predicates grounded and re-evaluated, not “check a cached handle”. Assertions do re-snapshot / re-query during each retry, and we scope them to signals that should change (URL, existence/state of an element, text/value).
If the page is flaky/stale, the assertion just won’t prove the condition within the retry window and we fail with artifacts such as frames of clip (if ffmpeg available) rather than claiming success.
There are still edge cases (virtualized DOM, optimistic UI, async updates), but in those cases the goal is the same: make the failure explicit and debuggable with artifacts and time-travel traces, not silently drift.
Comment · 9 months ago
It’s mostly the former: there’s a small set of generic checks/primitives, and we choose which ones to apply per step.
The binding between “task/step” and “what to verify” can come from either:
the user (explicit assertions), or the planner/executor proposing a post-condition (e.g. “after clicking checkout, URL contains /checkout and a checkout button exists”).
But the verifier itself is not an AI, by design it’s predicate-only
Comment · 9 months ago
I’m absolutely not AI, I dedicate this morning to technical discussion with HN community on my post, which I’ve spent weeks building the technology behind it