Show HN: Scan your AI agents for dangerous capabilities
1–10 of 25 posts
Re: Show HN: Scan your AI agents for dangerous capabilities
#2Hey all :)
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.
You can run it with:
npx @makerchecker/scan
Would love to get any feedback!
Re: Show HN: Scan your AI agents for dangerous capabilities
#3Why build separate frameworks for this kind of thing when your operating system is right there?
You can make a file called "orders" and you can run your agent as a user with write access to that file, or as one that doesn't, and then you don't need scans or audits to tell you whether the agent can create orders or not, you can just take your operating system's word for it.
Is there anything all this bolt-on AI security stuff does that can't instead be handled by donning a sysadmin hat and managing your agents as separate users?
Re: Show HN: Scan your AI agents for dangerous capabilities
#4Hey all :) 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. You can run it with: npx @makerchecker/scan Would love to get any feedback!
oopsie doopsie, release pipeline failed fixing now...
Re: Show HN: Scan your AI agents for dangerous capabilities
#5Why build separate frameworks for this kind of thing when your operating system is right there? You can make a file called "orders" and you can run your agent as a user with write access to that file, or as one that doesn't, and then you don't need scans or audits to tell you whether the agent can create orders or not, you can just take your operating system's word for it. Is there anything all this bolt-on AI securi…
> Is there anything all this bolt-on AI security stuff does that can't instead be handled by donning a sysadmin hat and managing your agents as separate users?
Like everything else, the packaging and ergonomics matter. Do we need podman or docker when we could just don our sysadmin hats and manage namespaces and cgroups directly instead?
Re: Show HN: Scan your AI agents for dangerous capabilities
#6Why build separate frameworks for this kind of thing when your operating system is right there? You can make a file called "orders" and you can run your agent as a user with write access to that file, or as one that doesn't, and then you don't need scans or audits to tell you whether the agent can create orders or not, you can just take your operating system's word for it. Is there anything all this bolt-on AI securi…
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
Re: Show HN: Scan your AI agents for dangerous capabilities
#7Hey all :) 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. You can run it with: npx @makerchecker/scan Would love to get any feedback!
oopsie doopsie, release pipeline failed fixing now...
should be fixed and released now :)
Re: Show HN: Scan your AI agents for dangerous capabilities
#8Why build separate frameworks for this kind of thing when your operating system is right there? You can make a file called "orders" and you can run your agent as a user with write access to that file, or as one that doesn't, and then you don't need scans or audits to tell you whether the agent can create orders or not, you can just take your operating system's word for it. Is there anything all this bolt-on AI securi…
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…
So Linux can prevent an agent from opening /etc/passwd.
Linux cannot stop an agent from calling:
POST /wire-transfer amount=5,000,000
Re: Show HN: Scan your AI agents for dangerous capabilities
#9haha! WHAT!? So, we had agents that came with a default setting to request for specific permission to perform an action, then we said "screw it!", we need speed and everybody started coding and releasing agents out in the wild to do whatever they want unchecked... and now we have a product that brings back the safeguards... A few years ago we have abstraction after abstraction coming in the way of blocking actual development (js ecosystem bloat), and now we have layer upon layer for coding with AI...
Re: Show HN: Scan your AI agents for dangerous capabilities
#10haha! WHAT!? So, we had agents that came with a default setting to request for specific permission to perform an action, then we said "screw it!", we need speed and everybody started coding and releasing agents out in the wild to do whatever they want unchecked... and now we have a product that brings back the safeguards... A few years ago we have abstraction after abstraction coming in the way of blocking actual dev…
[dead]