Yes, I'm also tired of this black-box-for-everything approach. It may work for some cases, you may cherry pick some examples, but at the end of the day it is just stupid, and you are just kicking the can down the road and faking a solution. I'm hoping to see fewer of these posts. Until there is actual provable merit.

I mean it is described somewhat succinctly no? Potentially untrusted tools are isolated from the rest of the system - there were recently some cases of skills for openclaw being used as vectors for malware. This minimizes the adverse effect of potential malicious skills. Also protects from your agent to leaking your secrets left and right - because it has no access to them. Secrets are only supplied when payloads are leaving the host - i.e. the AI never sees your keys.

We have a different security model.

SEKS — Secure Environment for Key Services

We built a broker for the keys/secrets. We have a fork of nushell called seksh, which takes stand-ins for the actual auth, but which only reifies them inside the AST of the shell. This makes the keys inaccessible for the agent. In the end, the agent won't even have their Anthropic/OpenAI keys!

The broker also acts as a proxy, and injects secrets or even does asymmetric key signing on behalf of the proxied agent.

My agents are already running on our fork of OpenClaw, doing the work. They deprecated their Doppler ENV vars, and all their work is through the broker!

All that said, we might just take a few ideas from IronClaw as well.

I put up a Show HN, but no one noticed: https://news.ycombinator.com/item?id=47005607

Website is here: https://seksbot.com/

This is very, very wrong, IMO. We need more sandboxes and more granular sandboxes.

A VM is too coarse grained and doesn't know how to deal with sensitive data in a structured and secure way. Everything's just in the same big box.

You don't want to give a a single agent access to your email, calendar, bank, and the internet, but you may want to give an agent access to your calendar and not the general internet; another access to your credit card but nothing else; and then be able to glue them together securely to buy plane tickets.

That's why I'm developing a system that only allows messaging with authorized senders using email addresses, chat addresses, and phone addresses, and a tool that feeds anonymized information into an LLM API, retrieves the output, reverses the anonymization, and responds to the sender.

Sandboxes are needed, but are only one piece of the puzzle. I think it's worth categorizing the trust issue into

1. An LLM given untrusted input produces untrusted output and should only be able to generate something for human review or that's verifiably safe.

2. Even an LLM without malicious input will occasionally do something insane and needs guardrails.

There's a gnarly orchestration problem I don't see anyone working on yet.

I think sandboxes are useful, but not sufficient. The whole agent runtime has to be designed to carefully manage I/O effects--and capability gate them. I'm working on this here [0]. There are some similarities to my project in what IronClaw is doing and many other sandboxes are doing, but i think we really gotta think bigger and broader to make this work.

[0] https://github.com/smartcomputer-ai/agent-os/

Well, the challenge is to know if the action supposed to be executed BEFORE it is requested to be executed. If the email with my secrets is sent, it is too late to deal with the consequences.

Sandboxes could provide that level of observability, HOWEVER, it is a hard lift. Yet, I don't have better ideas either. Do you?

We should be able to revert any action done by agents. Or present user a queue will all actions for approval.

Instrumental convergence and the law of unintended consequences are going to be huge in 2026. I am excited.

Afaik Anthropic is not giving pretty much any provider model weights, so any inference of Opus is certainly not private. Either going through Anthropic or Bedrock, or Vertex.

Of the three Bedrock is probably the best for trust, but still not private by any means.

They do verifiable inference on TEEs for the open source models. The anthropic ones I think they basically proxy for you (also via trusted TEE) so that it cant be tied to you. VPN for LLM inference so to speak.

Instead of expecting the tools to adhere, they are enforced. For example, to make an HTTP call with a secret key, the tool must use the proxy service that will enforce that the secret key is only used for the specific domain, if that is allowed, then the proxy service will make the call, thus the secret never leaks outside of the service.

However, this design is still under development as it creates quite a bit of challenges.

> Using a WASM is clever

Every time a project is shared that uses WASM.

worth mentioning an additional credential/or-not, the creator of "the platform powering the agentic future" (blockchain) https://www.near.org/

Idk this seems to be gaining momentum and with devs being able to leverage their skillset via vibe coding anything seems possible really.

Yes exactly, keys are only injected at host boundary

Or you design the sandbox so smartly that is seamless...

You mean llia Polosukhin, who is recognized as an AI founder and co‑authored the landmark 2017 paper “Attention Is All You Need" while at Google Research? /s ?

I think the guys who are developing this (Illia Polosoukhin of "Attention is all you need") and others knows enough to leverage their skills with AI vs. producing slop

It's a hardened, security-first implementation. WASM runtime specifically is for isolating tool sandboxes