Comment by pixl97
4 days ago
Dude, it is way harder than you think. A proxy is still a connection to the internet. In fact it's really easy to detect proxies as they change the latency to any sites.
It's like saying that you wouldn't detect your on this fake internet really quickly. If you've worked on this stuff you'd figure out your in a test environment in a few minutes.
For context I am a security researcher with two decades of experience. Side channel attacks, supply chain attacks, linux system hardening, and confidential compute are my core areas of expertise.
I do not even compile network support into my server kernels these days and run the netstack in user space or a dedicated VM where I control every system call in either case.
I am -not- saying blindly allow a model to control custom URLs that proxy to the real internet. That would allow for communication. When I say offline, I mean offline.
When I say pull through proxy I mean when a new domain is requested execution pauses and entire domain mirror is created on the fly, including making a fake mock of the public APIs the model wants to interact with using swagger-mitm or similar. Tons of options these days. Then resume execution letting it hit the offline mirror. You control the clock so it has no way of even knowing it was paused. Ideally humans approve every new domain mirror.
If the model detects it is not talking to a real site, then that is a test suite failure and you can control for that and try again. When you can MITM any linux system call you can give a program a simulated universe that results in the same exact syscalls running those same manually-approved sequences on a real target would produce, and even the same vulnerabilities when needed.
Yes, this can be time consuming to get right and experience sure helps, but that is the job that has to be done here, and there really are no excuses for not doing it.
I think the big labs can afford to hire capable security engineers.