Live data from Hacker News

The agent harness belongs outside the sandbox

mendral.com

111–120 of 140 posts

Re: The agent harness belongs outside the sandbox

#111
post #101

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…

Phishing is only a subset of the issue, so I don't think that name's appropriate, besides being used for other things in other contexts (which would be another reason for me not to try and overload it).

I'm not saying we need to overload phasing, but rather to not treat the trifecta like a regular security vulnerability. As defined originally, the trifecta is analogous to phishing, but of course it's only a small subset of the issue.

Re: The agent harness belongs outside the sandbox

#112
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…

Author here. I should have made it more clear that the article is about agent / harness building (not about running third party agents). > I barely trust the harness more than the LLM Since we built it, I trust it just as much as I trust our API server :) The latter gets untrusted inputs from the internet, while the former gets untrusted inputs from the LLM

[deleted]

Re: The agent harness belongs outside the sandbox

#113

Earlier quoted context omitted.

There were no LLMs between 2018 and 2022, at least not in the sense resembling today. The whole LLM frenzy started in late 2022.

BERT came out in 2018 and that’s a pretty important inflection point. It didn’t cause a pop culture frenzy, but in NLP circles it was a ‘magical’ improvement.

From technical POV that's true, but that was still a niche area at the time, mostly ignored in the broader tech community. So wrt. the broader tech world discussing harnesses, I'd still use November 2022 as the reference point.

Re: The agent harness belongs outside the sandbox

#114
post #110

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…

My approach to this has been a NixOS host with the harness running in a rootless podman sidecar. The host has squid configured with a self-signed CA and networking rules to route all host traffic to the intercepting proxy, so I have a tight firewall and full auditability. Then there’s a python rpc daemon running on the host with a set of whitelisted commands, read-only for pulling logs and diagnostics. By default, th…

NixOS is a great place to start from.

Trusted observability will be key. Why am I giving the harness the ability to read/modify files when the harness lives in the same action space as tools? No, the gates should be controlled elsewhere, and even when I have given carte blanche, I want to see what has been done, step by step. So a controlled CA that allows for inspection of requests is great for logging.

Re: The agent harness belongs outside the sandbox

#115
Many interesting ideas in there.

To move forward, I suggest thinking less about the implementation details and more about the concepts around your approach in this system.

For example a database storing files accessible remotely by multiple users is really a file server and can be implemented in multiple ways. And that's not the problem you're trying to solve here.

Depending on where your sandboxes live, a bind or network mount and a gitwatcher outside of the sandbox would accomplish something very similar with less customization.

You mentioned not having a solution for concurrency. So think about that first, without limiting yourself to a single implementation.

Maybe the storage should not be per file, but be a knowledge graph that is presented as a file to the LLM in the sandbox. Concurrent mutations in knowledge graphs may be easier to solve, especially with the help of LLMs.

Or perhaps it starts to work well already by simply showing the git merge conflicts to an LLM and having it reconcile the separate writes. Maybe even let it "post feedback" to the LLMs in the container, when a concurrent write has happened to a memory or skill to tell it "hey while you were working I also learned this potentially related update".

Re: The agent harness belongs outside the sandbox

#116
Good comparison of the 2 approaches of agent harness. Vita AI[0] also picked the outside model. We used the E2B sandbox solution, and fortunately it supports volume, so we just create volumes for personal skills and organization workspace, and mount them to the sandbox. This elegantly solves the "file system" problem you mentioned.

[0]: https://www.vita-ai.net (AI agent for content creation & social media management)

Re: The agent harness belongs outside the sandbox

#117
post #89

Earlier quoted context omitted.

> if your harness has an ability to do something the LLM can't What does this even mean. The only capability of an LLM is generate text.

We’ve trained models on JSON schemas for “tool calls”, and then built software to interpret and run those calls for the LLMs

> software to interpret and run those calls

Yes... That's the harness!

Re: The agent harness belongs outside the sandbox

#120
post #101

Earlier quoted context omitted.

Phishing is only a subset of the issue, so I don't think that name's appropriate, besides being used for other things in other contexts (which would be another reason for me not to try and overload it).

I'm not saying we need to overload phasing, but rather to not treat the trifecta like a regular security vulnerability. As defined originally, the trifecta is analogous to phishing, but of course it's only a small subset of the issue.

I don't think I've read the original definition, what was it?
Post reply on HN