Comment by wren6991
4 days ago
> you cannot have both and be serious about security
Why not? I think DSH does this pretty well with an agent preset that exposes the tools required for the agent to modify the harness.
It's kind of like how the kernel can expose interfaces to allow userspace to load kernel modules at runtime: you "just" have to control which processes can use them.
Between that, and a couple of extra injected bwrap args to make my SSH keys and LLM API credentials unreadable from the agent's shell by default, I'm pretty comfortable using the harness outside of a VM for most things.
> Why not?
If an agent can change the harness it is running in, in real-time, all bets are off
There is semantic ambiguity here. An agent being able to write plugin code for the harness it runs in is related, but orthogonal, to the real-time or not availability of that plugin to the current session.
When I have my agents assist with plugins, I pay closer attention and either do the testing myself or have them run the altered harness in another instance.
Part of this is because they have borked themselves and it can be super annoying to undo their f-ups. Little qwen did this once, breaking its own connection to vllm.
I guess for me there is a distinction between an agent I am using interactively and walking through step-by-step, vs an agent that is running unattended, doing web search, communicating with subagents etc. I am ok with giving greater privilege to the former. But yes Qwen-chan accidentally committing suicide, or OOMing its own inference machine is a canon event.
> Qwen-chan
I'm going to distill that from you :]
It was more I let the agent work on my homelab setup and it wrote a bad config value, but I had to actually look at what it had done to figure it out...