upvote
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.
reply
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
reply
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?

reply
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
reply
[dead]
reply
[flagged]
reply
[flagged]
reply