smashed
Joined 11 years ago
Joined 11 years ago
> Unless previously approved, Anthropic does not allow third party developers to offer claude.ai login [..] for their products.
ref: https://code.claude.com/docs/en/agent-sdk.md
Yes there is a huge gray area. Yes people are getting away with it. That does not mean it's allowed. Anthropic could clarify their terms any day and they don't, on purpose.
They want you to use and get accustomed to only their own tools. If other coding harnesses were allowed, it's far too easy to switch providers.
They can't allow that, because they only have a few months of head start.
So everyone accepts Claude code which is required for these sweet subsidized tokens.
I thought it meant the license was missing on GitHub but, no, it's an actual license called the Unlicense.
But then there is the Community and Pro edition so which is which on GitHub? Is the pro version hidden somewhere?
Plus a c++ code base in 2026. I think modern c++ can be made quite safe but I need some claims that it's taken seriously which I don't see.
I'm confused.
edit: I'm getting down voted here and no-one is telling me what I said wrong. These are my first impressions on the project. I think it's valuable feedback. Please reply and explain why I'm wrong instead of just down voting.
Yes all user error and avoidable using good processes but I have not seen any organization care about this so far. The carelessness of AI adoption is crazy. People are not aware of the risks.
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/...
Check out Egzo.ai, my attempt at sandboxing claude-code and all on github: https://github.com/egzo-ai/egzo