I have been working on putting agents into full gVisor isolation with a default deny egress proxy that includes secret injections. When an agent tries to connect outbound, by default it suspends the gVisor, holds the proxy connection open, and lets the user choose.
I am adding external judges now. But, there is a hypervisor key you press to deny/allow hosts without switching terminals.
I just can't get behind relying on the harness tool boundry to protect me.
Are putting the agent core and the workspace in separate containers? I do a limited version of that to prevent runaway tests etc from stopping jobs but making it a stronger boundary seems like a good idea.
You could cover a lot more adversarial scenarios with an ebpf backend. It needs linux, but with all the patches going around, you should be doing all your dev in a VM anyway.
https://eunomia.dev/agentsight/
I've built project that helps to protect your computer from dangerous commands that your ai agent might execute. Have you noticed how often dont even check what our agents are actually running? Thats why I created Stroq.
Try it locally npx @stroq/cli
> helps to protect your computer from dangerous commands that your ai agent might execute
How does "a local audit of what your coding agent did and why" help prevent dangerous commands? Sounds like your solution comes too late, innit? Sure, I can see that at 16:48 the agent ran "rm -rf --no-preserve-root" but if it already executed it on my personal computer, isn't it too late then?
Personally, I think this solves the wrong problem. If you're one stray "rm" away from letting the agent delete stuff on your personal computer, you're running the agent harness the wrong way. At least give it its own user, ideally limit what paths/network it can use, but don't rely on "auditing" to prevent dangerous commands, it'll bite you in the future.
You are correct, but it's generally very hard to come up with good access control policies up front. Also, as you grant more access the system tends to become over-permissioned over time, and often you don't really find out until so wrong that it hurts. The ability to audit is necessary to maintain good policies. It allows you to discover gaps in your policy even when things didn't break terribly.
You’re right
the command from my comment only generates a report and doesn’t actually prevent anything. stroq init sets up hooks that prompt for confirmation before a dangerous command is executed—but that’s a filter, not a sandbox
I have received two pre-interview repos from recruiters on LinkedIn (NK hackers targeting crypto people), and both would be hard cases for this. Almost all offers there in DMs are now fake recruiters, and it's not trivial to figure out if the account is fake.
One had an eval() hidden inside a controller function named getCookie(), running whatever a remote server sent back. npm start, npm build and npm test all triggered it. Cursor didn't catch it when I asked "is this repo safe to run?" and then told it to check all dependencies.
Other one came as a bunch of Solidity files in a zip file with an issue to resolve as the interview task, nothing suspicious at first sight. However, that zip carried the whole .git folder, hooks included, which a git clone never copies, and the folder is hidden by default in Finder. Of course, there was a hook that fires on any commit or push, again eval() on some remote address.
In both cases the agent only runs npm test or git commit. Would Stroq see anything in these situations?
to be honest, in the first scenario, the hook will only detect 'nom test' command itself. in the second scenario 'stroq inspect' will identify the hook before the folder is opened and issue a warning. thanks for these examples :) I'll use them to improve product
Doing it with a high-performance LLM would be best, but I think the token and time cost would be big, and just doing it code-based seems like it could work to some extent. But later, if LLM alignment gets good, it might not even be needed.
Yes, the rules dont catch everything but since this is an open-source project, anyone can add new rules, and I'll be looking for new approaches.
as for the llm, it reads the same text as the agent, so it can be fooled as well)
This is cool. I am working on a similar project but to remove PII and other sensitive info while talking with AI providers in an transparent manner. I started this because I am not comfortable sharing all this info with AI.
I'm wondering if that could be part of a prompt injection warn system in the future. Did I get it right, that it does not need an LLM to evaluate sessions?
I have been working on putting agents into full gVisor isolation with a default deny egress proxy that includes secret injections. When an agent tries to connect outbound, by default it suspends the gVisor, holds the proxy connection open, and lets the user choose.
I am adding external judges now. But, there is a hypervisor key you press to deny/allow hosts without switching terminals.
I just can't get behind relying on the harness tool boundry to protect me.
Are putting the agent core and the workspace in separate containers? I do a limited version of that to prevent runaway tests etc from stopping jobs but making it a stronger boundary seems like a good idea.
Yes. Very alpha. https://hshrun.org
Would love to collaborate with you on this since we’re building something analogous internally.
You could cover a lot more adversarial scenarios with an ebpf backend. It needs linux, but with all the patches going around, you should be doing all your dev in a VM anyway. https://eunomia.dev/agentsight/
I've built project that helps to protect your computer from dangerous commands that your ai agent might execute. Have you noticed how often dont even check what our agents are actually running? Thats why I created Stroq. Try it locally npx @stroq/cli
> helps to protect your computer from dangerous commands that your ai agent might execute
How does "a local audit of what your coding agent did and why" help prevent dangerous commands? Sounds like your solution comes too late, innit? Sure, I can see that at 16:48 the agent ran "rm -rf --no-preserve-root" but if it already executed it on my personal computer, isn't it too late then?
Personally, I think this solves the wrong problem. If you're one stray "rm" away from letting the agent delete stuff on your personal computer, you're running the agent harness the wrong way. At least give it its own user, ideally limit what paths/network it can use, but don't rely on "auditing" to prevent dangerous commands, it'll bite you in the future.
You are correct, but it's generally very hard to come up with good access control policies up front. Also, as you grant more access the system tends to become over-permissioned over time, and often you don't really find out until so wrong that it hurts. The ability to audit is necessary to maintain good policies. It allows you to discover gaps in your policy even when things didn't break terribly.
You’re right the command from my comment only generates a report and doesn’t actually prevent anything. stroq init sets up hooks that prompt for confirmation before a dangerous command is executed—but that’s a filter, not a sandbox
I have received two pre-interview repos from recruiters on LinkedIn (NK hackers targeting crypto people), and both would be hard cases for this. Almost all offers there in DMs are now fake recruiters, and it's not trivial to figure out if the account is fake.
One had an eval() hidden inside a controller function named getCookie(), running whatever a remote server sent back. npm start, npm build and npm test all triggered it. Cursor didn't catch it when I asked "is this repo safe to run?" and then told it to check all dependencies.
Other one came as a bunch of Solidity files in a zip file with an issue to resolve as the interview task, nothing suspicious at first sight. However, that zip carried the whole .git folder, hooks included, which a git clone never copies, and the folder is hidden by default in Finder. Of course, there was a hook that fires on any commit or push, again eval() on some remote address.
In both cases the agent only runs npm test or git commit. Would Stroq see anything in these situations?
to be honest, in the first scenario, the hook will only detect 'nom test' command itself. in the second scenario 'stroq inspect' will identify the hook before the folder is opened and issue a warning. thanks for these examples :) I'll use them to improve product
Doing it with a high-performance LLM would be best, but I think the token and time cost would be big, and just doing it code-based seems like it could work to some extent. But later, if LLM alignment gets good, it might not even be needed.
Yes, the rules dont catch everything but since this is an open-source project, anyone can add new rules, and I'll be looking for new approaches. as for the llm, it reads the same text as the agent, so it can be fooled as well)
Of course, I do think it's really great in terms of cost. And since it's open source, it also has the advantage of being customizable.
Could this be used with Agent Safe house? https://agent-safehouse.dev/
This is cool. I am working on a similar project but to remove PII and other sensitive info while talking with AI providers in an transparent manner. I started this because I am not comfortable sharing all this info with AI.
its great that you're interested in this topic, good luck)
same
From the README, matching is text-level and nothing is sent out. So it seems to judge with rules, not an LLM. Is that right?
yes
Interesting. How does it know: rule based, small model, or LLM? Anyway, like the mascot
Thanks, the owl's name is Hoo) Stroq reads sessions logs and command text directly from the computer. There are no LLM models involved
feature suggestion:
background daemon that continuously scans and alerts in a menubar app when a positive match is found
clicking the menubar app shows the offending entry, clicking the entry lets you redact, delete, repair, mark as false positive, etc.
Thanks) good idea
Like the owl. Add citations too.
Thank you. What do you mean by 'citations'? Each item has a 'Stroq show' feature that displays the basis for it
I'm wondering if that could be part of a prompt injection warn system in the future. Did I get it right, that it does not need an LLM to evaluate sessions?
Yes, that’s correct. the rules already flag this kind of text
Is it fully programmatic ?
Everything is performed programmatically, without using a model
homie lets keep building
cool
cool project! ...so is it pronounced, like, stroke? lol
oh no, I hadn't made that connection until now lol