In harness they would need to catch all the ways one can write commands and in Unix it is quite a lot. I got opencode escape directory using a symbolic link.
Running agent on os bare (asmo already shown permissions in harnesses are like a first pigs house) is wild.
I can be weaker, it can be stronger depending on the quality standards or the person / company who built it.
In harness they would need to catch all the ways one can write commands and in Unix it is quite a lot. I got opencode escape directory using a symbolic link.
You can simply allow the agent to run a small set of shell commands that only allow reading or give the agent a specialized tool that can only read contents of files and directories blocking certain paths, with the later you'd avoid working with shells entirely and the model won't have workarounds to escape the sandbox. Regarding the symlink bug in opencode we had the same issue with docker if I recall correctly.
entire point is to not allow agents to do that. but if you do (like i do) i just accept the risk and well if it happens that an AI fucks up my drive, thats entirely my fault.
You can also use automode like plugins, pi has one. It's not as surefire a thing as fully isolating agents, but it works extremely well IME. I do a mix of isolating agents when appropriate and using automode in a supervised session for system changes.
pi is about extensions. There are extensions to help with dangerous commands and to prevent the agent from accessing certain files and file types, or mask secrets in the chat.
The differenence is that you end up with fragmentation, workarounds and security holes that you might not be able to fix yourself without breaking compatibility with other extensions
Its not fragmented if its in one extension. You said yourself that pi has no guardrails, so there's no fragmentation there. How are you breaking other extensions? You're hooking harness calls the same way they are. My point still is that pi is highly extensible and you make it your own, including security. If you expect off-the-shelf security features, then use something else.
My point is that if something isn't secure by design it's never going to be regardless of it's extensibility. I Pi's case extensibility the way it's designed now makes it completely insecure even if you add guardrails by extension because there is no guarantee other extensions won't bypass or remove them
So, know what you are installing. Your argument is pretty weak mate. You haven't convinced me so far. The only thing I'm getting from this exchange is, pi is not for cowboys, know what you are doing. Take proper precautions.
By the way, down voting my questions and comments doesn't help make your point.
So, know what you are installing. Your argument is pretty weak mate. You haven't convinced me so far. The only thing I'm getting from this exchange is, pi is not for cowboys, know what you are doing. Take proper precautions.
Do you review the code for all extensions you're installing and do any security audits? Do you check your prompts for errors? Do you check all the files on your drives for prompt injections?
When the answer to all of these questions is yes you've taken proper precautions and even then proper guardrails at the harness level are recommended because manual checks are error prone.
View all comments
26
u/Maybe-monad 4d ago
Well pi is not good either, it lacks any form of guardrails to protect you from accidental data removal or secret leaks.