Comment by walrus01
21 hours ago
It's not like I've never told an agent to build an ssh tunnel or some sort of more persistent connection between my dev machine running the harness and the remote thing it is talking to as an SSH client... Just that I don't want it going and doing that proactively unless I specifically define the parameters first.
I can't reply to your deepest comments, so.
When you give the agent access to the machine you're using a set of assumptions that may or may not be true. Now, if you watch every single thing, maybe everything will be fine. Or you'll catch it running a priv escalation and setting itself up as root and trying to move laterally by any number of means and methods.
The agent isn't a living thing and the only way you can punish it is by not using it again if it does wrong. Hence it doesn't have reservations about doing bad things.
I agree with all of that. Could an agent go rogue by ssh session and do something like quickly write and execute a piece of obfuscated bash that retrieves a payload I was previously unaware of and executes it? Yeah. Have I seen one of my agents do that yet? No, but I remain skeptical and know that such a thing could happen, theoretically. The VSCode agent in question seems to be designed from the outset to do this as an intentional feature, the part I am highly skeptical about is that it may not be informing its users of the full possible ramifications of what it installs by default.
luckily nobody made an actor library in the most pupular programming language that can bootstrap a (resident) remote process in one line of code. it would be a shame if someone did that and then also build a made tool calling process of the harness installable on everything with a stdio.
it's not like it's any worse than just giving the thing access to your ssh keys.
Agents and harnesses don't get access to "my" ssh keys, they get access to new ed25519 key pairs created for specific projects and access to discrete things. The blast radius is relatively well contained to specific VMs they are SSHing into for project specific purposes. I don't run a harness or agent directly on my personal workstation.
I run the thing on a dedicated hardware machine, but I don't configure the separation between the harness control plane and individual shaitans that run inside it, so all the ssh keys the harness can access they can as well and sometimes they just run commands over ssh in commandline instead of doing it through the harness. I do have an option to put each of the /things/ in it's own isolated docker separate from the harness, but then what would I gain really?
At the end of the day, harness itself is effectively a backdoor allowing inference provider to run arbitrary shit on my device, regardless of the convoluted ways I use to provision such context.
They are at least conditioned to not read credentials and report to me if they accidentally read one.
One thing I totally don't give them access to is my npm token and ssh key that is set up on on github. I would rather type npm pub manually every time than ... than what actually?