Completely agree, though the LLM part of the scanner can help with that contextual part of the analysis.
Runtime enforcement already exists (the embedded governor wraps tool calls in-process); extending it with a quarantined contextual evaluator like you describe would the logical next step.
Thanks for the feedback, actually will raise an issue on that to explore
I’d say the biggest difference would be:
1. Parameter-aware rules: OS permissions don’t know your application logic. (How would you tell OS permissions not to let your AI to trade on over 1M dollars)
2. You can’t easily model multi-pary and RBAC.
3. Agents call remote APIs for alot of those tools. Native OS doesn’t really parse web traffic to decide if a request is safe or not.
OS sandboxing is good for host security, but not necessarily for governing business logic or AI agents
Is that a real boundary? I mean if an application asks the kernel to enforce a rule, the kernel enforces that rule, regardless of whether it counts as business logic or not. Why have two languages for defining such things if they're not actually distinct?
I'll admit that OS interfaces could stand to improve in their ability to do so, there's a lot of stuff in plan9 and fuchsia that I'd love to see in widespread use, but despite that I still think the quickest route to sanity is improving existing tools that constrain arbitrary processes, not replacing them with tools that specifically constrain agents.
You'd do that with a container and a layer 7 egress proxy rule e.g. mitmproxy.
Sure it's work to build such things, but building restraints into the app feels more reliable than playing whack-a-mole with scanner results.
Operating systems can probably do better to meet this need (e.g. capability based ones like fuchsia) but even as is their rules just feel so much more binding.
The scanner is just one part of the codebase, good for maintaining quality in a pipeline.
There is also @makerchecker/embedded, which has runtime permission primitives you wrap around the agent's actions, so the restraints live in the app exactly like you're describing
Less whack-a-mole, more wrap the risky calls and they're bound
It’s equal parts funny and frustrating to see how deep into the ”a few hypothetical percent of profits for corporations matters more than customer rights and less e-waste” some are.
I'm preparing to release my first app to the App Store and they're currently requiring me to dox myself if I want to sell in the EU. Which facts am I missing that makes this not very inconvenient for me?
I've been working an open-source toolkit to stop AI agents from running amok.
You can scan your code (Python, JS, TS) and it will flag any risks and can offer fixes. It runs offline, but you can wire an LLM to do code analysis as well.
The US has actively suppressed any development in countries that could become competitors or non-aligned regional powers. Think Chile, Argentina, and Brazil (at least twice).
It wraps around agents you already have and provides structured controls:
- Each agent acts only through a role and can only run skills its approved for.
- It cannot approve its own work.
- Support for human approval gates.
- Every action is committed to a hash-chained signed log.
I also built alot of runnable examples based on real life case studies (e.g. Knight Capital, Air Canada refund chatbot) and how it can be used to prevent them.
The goal is to help get agents that do impactful work (move money, healthcare triaging, prod releases, etc) out of pilot and into production.
A bit past the OpenClaw hype-train, but I remember seeing all this news about the massive security risks OpenClaw has, so I wrapped it with MakerChecker so you can have sophisticated guarantees and controls over OpenClaw. Good enough that you could have it be an employee ;)
Made a few demos where you could control how it uses finances, customer databases, etc. And how it could actually be used in the workplace.
