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

101–110 of 140 posts

Re: The agent harness belongs outside the sandbox

#101

Post by 3form »

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…

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).

Re: The agent harness belongs outside the sandbox

#102

Post by bsenftner »

aluzzardi wrote: post #57
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…

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

You have some very innovative thinking in your organization. Impressed.

Re: The agent harness belongs outside the sandbox

#103

Post by keepamovin »

tptacek wrote: post #42

There are other models. Eschew the sandbox. Give the agent a computer, with all the trimmings, but keep that computer segregated from sensitive resources. Tokens are a solved problem: tokenize them[1] or do something equivalent with a proxy. The same thing goes for secrets. A lot of this post presents false dichotomies. It assumes the existence of a sandbox that is by definition ephemeral or "cattle-like". Why? There…

Yes, or just run it inside GitHub actions. On your free minutes. With what you already have.

Re: The agent harness belongs outside the sandbox

#104

Post by zozbot234 »

spankalee wrote: post #29

This is angling in the right direction, but I think it has two problems: 1) It's still assuming agents have CLIs. This is a very developer-centric concept of agents, and doesn't map well to either consumer or enterprise agents that aren't primarily working with files. Skills, plans, TODO lists, and memory are good, but don't have to be modeled as raw file access. Many harnesses have tools for them. 2) It's talking ab…

> It's still assuming agents have CLIs. This is a very developer-centric concept of agents, and doesn't map well to either consumer or enterprise agents that aren't primarily working with files. Skills, plans, TODO lists, and memory are good, but don't have to be modeled as raw file access. Many harnesses have tools for them.

Why can't it just be a simple CLI? Even small AI models are plenty smart enough to think "It's a *nix system, I know this!"

Re: The agent harness belongs outside the sandbox

#105

Post by intrasight »

jdw64 wrote: post #39
aluzzardi wrote: post #38

Earlier quoted context omitted.

Author here. In my opinion, the main driver here is how fast models have evolved in the past 12 months. It makes the architecture of everything around them obsolete, very fast. We went from using models as a building block, wrapping them in heavy workflow code, to now models being smart enough to drive their own workflows and planning.

Really enjoyed your post, by the way. The idea of putting skills and memories in a database while keeping the file shaped interface for the agent is clean. One read/write surface, two backends, invisible to the modle that's a nice piece of design, and the candor in the "what's still hard" section made me trust the rest of the post. My comment above was meant as a joke, not about your architecture. If this pattern bec…

> putting skills and memories in a database

I assume by database he meant a relational database. But I don't see the advantage of that over just having skills and memory it in our source control database. Am I missing something?

Re: The agent harness belongs outside the sandbox

#107

Post by dropofwill »

TeMPOraL wrote: post #86
redanddead wrote: post #61

Earlier quoted context omitted.

My 2c: The word harness brings the truth of LLMs back down to Earth. it really felt like between 2018 and 2022ish like LLMs had this magical aura, like the orchestration layer was intelligent, maybe even recursive, beyond what simple functions could do. It was assumed that this was a solved problem. The word "orchestration" denoted it, the words we used were full of optimism. When you lift the veil, it really is just…

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.

Re: The agent harness belongs outside the sandbox

#110

Post by wswope »

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…

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, the agent runs in a split pane tmux session with a host shell on the left and the chat interface on the right. The rpc whitelist includes the proper `tmux capture-pane` invocation to pull from the host shell, so I can easily let it see what I’m doing if I want it to help debug something.

I’m using pi as my harness and have custom extensions that give Yes/No confirmation gates for any writes the agent makes and that pass all bash commands/file writes to a deepseek subagent for review.

Still early days, but as someone with a similarly paranoid mindset around running LLMs securely, I think the future is promising and we’ll see some new “best practices” and related tooling popping up shortly.

Post reply on HN