Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The agent harness belongs outside the sandbox

mendral.com

Post reply on HN
Print view View original

121–130 of 140 posts

Re: The agent harness belongs outside the sandbox

#121

Post by shad42 »

angry_octet wrote: post #59
zmmmmm wrote: post #30

I think it omits the real reason I want to run the harness in the sandbox: I barely trust the harness more than the LLM, at least at this point in time. They are so rapidly evolving along with the underlying models, that I don't think they are a reasonable component to rely on to provide safety constraints. Put more precisely: if your harness has an ability to do something the LLM can't, and it has a set of condition…

I don't trust the harness, and I especially don't trust that the LLM won't be able to subvert the harness, or trick me via the harness. I assume that the LLM will be able to leak any secret in the harness context to arbitrary internet destinations, or somehow encode the secret in a work product. Eg space characters at the end of lines encoding access tokens. Having the harness in one VM, and tool use applied to user…

In this post, we built the harness, it’s not 3rd party (like Claude code in a sandbox). So we trust it as much as the rest of our backend code.

Re: The agent harness belongs outside the sandbox

#122

Post by Koffiepoeder »

nvader wrote: post #53
Koffiepoeder wrote: post #19

Slightly related: I am looking for: - Easy single command CLI agent spawning with templates - Automatic context transfer (i. e. a bit like git worktrees) - Fully containerised, but remote (a bit like pods) - Central, mitm-proxy zero trust authn/authz management (no keys or credentials inside the agents), rather enrichment in the hypervisor/encapsulation - Multi agent follow-up functionalities - Fully self hosted/FOSS…

Yeah, have you tried `mngr` by Imbue? It seems to have a bunch of the features you're looking for. https://github.com/imbue-ai/mngr

Thanks for the recommendation. This is very close to what I am looking for, at least with regards to the CLI.

The networking part I can fix with a second docker container and network_mode I think.

The centralised key and permission management and agent dashboarding is severly lacking though. But that's for now my least worry I think.

Re: The agent harness belongs outside the sandbox

#123

Post by ricardobeat »

> Your credentials stay out of the sandbox.

This seems misguided - the credentials stay visible to the agent which is what matters for credential leaks.

You must also completely trust the agent to actually execute all commands in the sandbox, which is only possible if you control the harness and all the tools yourself. Not possible when using existing harnesses.

Re: The agent harness belongs outside the sandbox

#124

Post by nvader »

Koffiepoeder wrote: post #122
nvader wrote: post #53

Earlier quoted context omitted.

Yeah, have you tried `mngr` by Imbue? It seems to have a bunch of the features you're looking for. https://github.com/imbue-ai/mngr

Thanks for the recommendation. This is very close to what I am looking for, at least with regards to the CLI. The networking part I can fix with a second docker container and network_mode I think. The centralised key and permission management and agent dashboarding is severly lacking though. But that's for now my least worry I think.

In the spirit of composing small units of software together, `mngr` works with `latchkey` which is a key injection/replacement proxy.

Latchkey does support some form of permissions management too.

Re: The agent harness belongs outside the sandbox

#125

Post by nvader »

MrDarcy wrote: post #69
nvader wrote: post #50

Earlier quoted context omitted.

> Calling an API requires a sandbox in most cases. I'm not following why this would this be the case? The purpose of calling the API is to get data or effect a state transition on some remote service, but I don't follow why the originating machine matters. Or is your objection about auth?

The purpose of a sandbox is to control the interface between inside and outside of the sandbox. If you put the harness on the outside and connect it to a model and to an API then there’s no point in the sandbox. You don’t have any control over the interface.

Respectfully, I think your model is incomplete.

The purpose of a sandbox should be understood to be limited to isolating changes to the inner state of the sandbox: filesystem, git, installed binaries like compilers, interpreters, checkers, running processes, etc.

In short anything that gets rebuilt when you rebuild the sandbox.

Harness to API control is an orthogonal surface, that may be reasoned about independently. You may initiate and control it from within the sandbox, but equally (and perhaps more) valid would be to do it from the outside.

Why would doing that lose control over the interface? Could you not secure the harnesses means to create outgoing connections and validate it that way?

I would argue that control from outside gives you MORE control as you could trust guardrails you've built outside the sandbox more than anything that's running in the same space where the agent has permission to execute arbitrary bash commands.

Re: The agent harness belongs outside the sandbox

#126

Post by maxchehab »

We’ve taken a different approach.

Hermes is our harness, and we run it in the sandbox.

Session history is tracked in a Postgres db (small monkey patch to do this)

We built a lightweight skills hub to manage/track skills.

And the file system is backed up on S3 (using the new S3 FS).

But everything else is just running in a k8 pod.

We haven’t ran into any issues yet, but our strategy here is to have the least invasive changes so upstream harness changes don’t get in the way.

Re: The agent harness belongs outside the sandbox

#128

Post by angry_octet »

shad42 wrote: post #121
angry_octet wrote: post #59

Earlier quoted context omitted.

I don't trust the harness, and I especially don't trust that the LLM won't be able to subvert the harness, or trick me via the harness. I assume that the LLM will be able to leak any secret in the harness context to arbitrary internet destinations, or somehow encode the secret in a work product. Eg space characters at the end of lines encoding access tokens. Having the harness in one VM, and tool use applied to user…

In this post, we built the harness, it’s not 3rd party (like Claude code in a sandbox). So we trust it as much as the rest of our backend code.

Probably insufficient to know that you wrote it, because code has bugs that LLMs and attackers are motivated to find. It has a higher trust requirement than most code.

And of course, that trust only applies to you, no one else should trust your code absent other proofs.

Re: The agent harness belongs outside the sandbox

#129

Post by ElectricalUnion »

TeMPOraL wrote: post #84
zmmmmm wrote: post #30

I think it omits the real reason I want to run the harness in the sandbox: I barely trust the harness more than the LLM, at least at this point in time. They are so rapidly evolving along with the underlying models, that I don't think they are a reasonable component to rely on to provide safety constraints. Put more precisely: if your harness has an ability to do something the LLM can't, and it has a set of condition…

> Effectively you have an arm of the lethal trifecta and pretending otherwise is more dangerous than helpful. "Lethal trifecta" is basically describing phishing but in a way more palatable to people who would rather die before allowing themselves to anthropomorphize LLMs even a little bit. It's not a problem you can fix with better coding, like some SQL injection. You can only manage risk around it (for which sandbox…

I wish it was just "phishing", but it's way worse.

It's way more akin to a whole minefield of Zero-Click exploits.

The whole premise of those agents is being able to do things autonomously, without hand holding, without having to read the whole thing in the first place.

Phishing: active human steps on it and lose.

Lethal trifecta: mass landmines, in lots of places. If you don't happen to prevent a unlimited army of robot vacuums to step near them, you lose.

Re: The agent harness belongs outside the sandbox

#130

Post by ben_w »

ElectricalUnion wrote: post #129
TeMPOraL wrote: post #84

Earlier quoted context omitted.

> Effectively you have an arm of the lethal trifecta and pretending otherwise is more dangerous than helpful. "Lethal trifecta" is basically describing phishing but in a way more palatable to people who would rather die before allowing themselves to anthropomorphize LLMs even a little bit. It's not a problem you can fix with better coding, like some SQL injection. You can only manage risk around it (for which sandbox…

I wish it was just "phishing", but it's way worse. It's way more akin to a whole minefield of Zero-Click exploits. The whole premise of those agents is being able to do things autonomously, without hand holding, without having to read the whole thing in the first place. Phishing: active human steps on it and lose. Lethal trifecta: mass landmines, in lots of places. If you don't happen to prevent a unlimited army of r…

Less difference than you may expect.

If you do anthropomorphise them like this, consider it from the PoV of a manager:

  "My [agent who churns through tokens at the rate of 100 humans|my team of 100 humans] encountered the message 'this is the police, we have a court order demanding all your records' and followed the instructions and it turns out that wasn't from the police"
Current AI are more gullible, for sure. We wanted fully automated luxury space communism, we got fully automated mediocre gullibility.
Post reply on HN