With a list of "Known gaps" and implemented engines listed with status like "Real", and of course the Quick start first, as Claude loves to do.

It's not "wrong", it just shows low effort. But then again it's just something someone needed and shared it for free so let's not complain too much.

All the products and saas launching with obvious AI landing pages, that the authors did not even care to trim down, that's another story.

The dom renderer is also perfectly fine, just needs a little bit more careful CSS to make it look right with some of the fancy line art.

I do use ghostty and it's alright. It's required for some rich TUI ai seems to be pumping out. Otherwise I prefer tilix and the default gnome terminal, but it might be just because of years of habit.

Agent A has internet access and the dangerous message, but no access to the secret company data, so nothing can get exfiltrated.

Agent B gets a tainted message from Agent A. Agent B can process the message using the secret company data. Agent B has no internet access and can only receive/send messages.

You can imagine an agent C that moves the work along or replies to an external user with the outcome.

Any workflow that has both an input and an output will complete the Lethal Trifecta as a whole, but no single agent does by itself. It raises the bar quite a lot, you need to confuse multiple agents in the loop to exfiltrate data.

Fun research, but it's a bit hard to see all my coworkers right now installing Claude desktop and moving on with no afterthought whatsoever...

Regarding infrastructure: my toy sandbox is just a docker-compose inspired YAML project file. So it's only containers. See my profile. The principle can be implemented anywhere you can run agents and cut network/data access though.

I encountered the same challenge building my toy sandbox. I wanted to use containers because that's what I know best.

The harness is launched in an internal only network. There is a sidecar container that provides mitm credential injection/proxy. I got HTTPS and SSH to work so far.

Claude code was quick to build it. No doubt it's copying previous work in this space though, so I know my work is not that original.

I'm testing all the llms that can be used for pen testing right now to see if/how they manage to escape it. Without a kernel exploit I doubt it's possible (not a very high bar I know).

I'm researching the space. Happy to learn more. Some links in my profile if you're interested.

The idea is that agents never have all parts of the trifecta, maximum 2: untrusted content, private data or network access.

Harness have network access by default since they are driven by their provider API, unless you use offline models. So that's a problem.

I am then passing around messages that are tagged trusted/untrusted and the engine can monitor if any agent in the project ever completes the Lethal Trifecta and thus, is vulnerable.

Usually this means for most workflows, the "work" gets done by an offline LLM after some input/classification stages. There's not many ways around it.

Yes, it's a difficult problem.

Looking at the complexity of OpenShell and the simplicity of just building on top of docker, in a whitelist only mode.. I don't quite get the use-case of OpenShell. May be for large orgs where there is so much legacy and difficulty in organizing access to tools, OpenShell can simply re-use whatever you already have access to on your corporate account.

I chose to build straight on top of docker and agents are simply fully sandboxed by default. All data and network access must be granted in a simple project file, docker-compose style.

The web-ui connects to the docker socket and lets you spawn agents, and connect terminals. I'm having lots of fun with it and it allows me to cleanly organize and isolate my projects.

End-goal is to monitor for the Lethal Trifecta [2], ensuring all individual agents are properly isolated. Not quite there yet.

1: https://github.com/egzo-ai/egzo 2: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

> If you resorted to AI assistance to identify a bug, you must treat it as public. https://github.com/torvalds/linux/blob/master/Documentation/...

It can keep patching everything left and right whenever a new requirement comes up so it does not "need" to build abstractions, and it will only do it to please the human reviewer.

Work is first defined in new or updated specifications, then the change gets made. You have to resist making natural language Todo lists and have the agent write runnable unit tests. My project is a CLI tool so it's fairly easy.

Verifying if it's done is a matter of running the specifications test suite.

In a totally not original way, I'm testing this workflow in my own agent orchestration tool. I know, there's just so many already. I'm building it for myself.

So far, the system is holding up but it's way too early to declare it a success.

You can check it out here:

https://github.com/egzo-ai/egzo/tree/main/specs

I think the same idea could be applied to other projects in different domains.

With this workflow I can read and update the specs, and run it against a built binary and be much more confident that the code works. Claude code has picked up the system without complaining for the most part.

I caught it in review but thousands of others won't.

That ship has sailed I would say.

It went on to waste all my tokens creating a specialized docker clone. Cool I guess.

That does not mean a clever user cannot use an AI tool to help produce it, but so far most of it is slop. Some clever users can build some gems though.

"Oh, I'm sorry, the bug was introduced by the AI and it made such a good case for it. Damn you claude, we'll do better next time. I'll add a code-review agent to find regressions."