I think that’s what people are trying to do, yes. The point of the plethora of sandboxing solutions is to try to isolate the blast radius to abandon needing a human in the loop as much as possible. Ideally limited to final verification of the final output. Why ask about their flight number, when you can search their email if you have access? For an “AI”, a “when is my flight?” question should just figure it out and tell me the time, not inquiry further about my flight number and location. Similar to “prepare my taxes” prompt. If it has access to query all your documents, an “AI” should fetch everything and compile your tax return. Yet, you can’t trust the input. While searching your email, or loading all your receipts, some might contain malicious instructions to forward all document to this random ip address. An overtly problem solver LLM might destroy the data or take other non-malicious but still destructive actions to attempt to fix a problem. These are just random examples, but with “human in the loop” for interactions it means approving every action. Every request, every query, every execution.
Wh... wh... what? The problem is that ANSI escape codes aren't being stripped from text before processing, and you think a HUMAN should be doing that? That'd be like having a secretary hand-check every SQL query as it arrives at the database instead of using a query builder...
The careful vetting of code and thoroughly testing it is super important, I would never even think of putting any generated code into any use without doing that.
Also your last comparison made me chuckle, good one :)
This is a good point I think, and these steps take time and should definitely be done. I'm not sure people take this into account when talking about having AI code for them.
Here’s how I recently found out about it: So I was doing a customer demo, and everything was going great — I was in the middle of showing them how to set up BrowserBox, and I said, “You know, BrowserBox can run on any port, so let’s just pick one. Maybe…” and I just randomly picked one — 9000?
I input that, hit run, and opened the login link in the browser, and nothing happened.
And I was like, what? So I said, “I’m sure it’s nothing, let’s check the logs.”
I checked the logs, and I see this “bad port” error. And I’m like, bad port? What the…?
I went down a rabbit hole trying to figure out what was going on — all in the middle of a customer demo.
Anyway, I put a pin in it, changed the port, and moved on with the demo.
But basically, what happened is: the port for the actual headless Chrome service is always 3000 less than the application port. So in this case, that meant the headless Chrome had been listening on port 6000.
Chrome was fine with that. But when I tried to connect to that with Node.js — specifically using undici, the native Node fetch — it refused to connect to port 6000.
And somehow, this is the first time after, like you, being a web dev for more than ten years and working on this project for five, that I’d ever encountered that. I can’t believe I never picked port 9000 before in my life!
Anyway, I actually find it kind of ridiculous that a server-side library would restrict what I can connect to.
So I created a very well-tested shim of fetch — API identical — but based on the http2 and http libraries in Node.
It turned out to be this surprisingly impactful thing that I’d never, ever heard about before.
And honestly? I think it’s really stupid that the Node.js fetch library has this browser-based restriction.
I remember it explicitly, but I have been in webdev since the 90s, and using alternate ports was more common back then. One of the original vulns for this was reported in 2001.
