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).
The agent harness belongs outside the sandbox
111–120 of 140 posts
Re: The agent harness belongs outside the sandbox
#112I 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
Re: The agent harness belongs outside the sandbox
#113Earlier 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.
Re: The agent harness belongs outside the sandbox
#114Earlier 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…
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
#115To 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[0]: https://www.vita-ai.net (AI agent for content creation & social media management)
Re: The agent harness belongs outside the sandbox
#117Earlier 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
Yes... That's the harness!
Re: The agent harness belongs outside the sandbox
#118The use cases will evolve so much more in coming weeks and months that the boundaries will blur. You can still contain the agent outside in a sandbox though.
Re: The agent harness belongs outside the sandbox
#119Re: The agent harness belongs outside the sandbox
#120Earlier 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.