great stuff working in a similar project that enforces guardrails at runtime
Show HN: Scan your AI agents for dangerous capabilities
21–25 of 25 posts
Re: Show HN: Scan your AI agents for dangerous capabilities
#22Really great idea, simple yet effective.
Re: Show HN: Scan your AI agents for dangerous capabilities
#23Earlier quoted context omitted.
Any LSM can stop that POST. SELinux, AppArmor, Tomoyo, etc. They are built-in to the kernel. You just need to know what you are doing to use them.
Yes, but they operate at the OS boundary, but we are defining application/business logic OS controls answer "can this process make network requests?" App-level policies answer "is this request, with these parameters, acceptable?"
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.
Re: Show HN: Scan your AI agents for dangerous capabilities
#24[flagged]
Re: Show HN: Scan your AI agents for dangerous capabilities
#25Earlier quoted context omitted.
One benefit is that this can run in serverless / sandboxed containers where OS primitives are not exposed or heavily limited. I immediately thought of Cloudflare Workers, which runs on V8 and exposes WASM-only interfaces, using Workers AI. Further, servers still have hosting value, but any business running agents is almost certainly going to want a sandbox that limits what code runs for agentic work, so targeting _sa…
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
[dead]