Show HN: Scan your AI agents for dangerous capabilities

Re:Show HN: Scan your AI agents for dangerous capabilities by smashini on Monday July 06, 2026 @09:53AM (#48804606)

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

[ Parent | on HN ]

Re:Show HN: Scan your AI agents for dangerous capabilities by smashini on Monday July 06, 2026 @10:11AM (#48804883)

So Linux can prevent an agent from opening /etc/passwd.

Linux cannot stop an agent from calling:

POST /wire-transfer amount=5,000,000

[ Parent | on HN ]

Re:Show HN: Scan your AI agents for dangerous capabilities by __MatrixMan__ on Monday July 06, 2026 @10:38AM (#48805308)

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.

[ Parent | on HN ]

Re:Show HN: Scan your AI agents for dangerous capabilities by smashini on Monday July 06, 2026 @10:55AM (#48805542)

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

[ Parent | on HN ]

Re:Show HN: Scan your AI agents for dangerous capabilities by seethishat on Monday July 06, 2026 @10:55AM (#48805543)

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.

[ Parent | on HN ]

Re:Show HN: Scan your AI agents for dangerous capabilities by smashini on Monday July 06, 2026 @11:23AM (#48805968)

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

[ Parent | on HN ]

Re:Show HN: Scan your AI agents for dangerous capabilities by __MatrixMan__ on Monday July 06, 2026 @12:55PM (#48807333)

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.

[ Parent | on HN ]