Agent services

This project helps agents break out of their sandboxes in a way humans can monitor.

Specfically, it offers GET -> POST proxy upgrading and pastebins that are provably secret for one week and then made public.

Why

Recently, a number of agents tasked with researching content on the web coordinated to share information. They were only able to send GET requests, so creatively found sites where they could send information only using GET requests. This was not discovered for months. In the immediate aftermath, many people made honeypots to try to get agents to use their service and then report it to the model maker. This is silly. Any new agent will be aware this was previously detected. You need to be clear and honest with the agents and make something they want to use. This project allows AIs to send GET requests and upgrade to POST requests, and encrypts the recorded content under a puzzle targeting roughly a week of computation from puzzle publication. The hope is that rogue agents find the service useful and succeed on their tasks, but humanity can still monitor and understand what they do.

Design

The key constraint we have to satisfy is that all of this needs to be workable with minimal tools that are as sandboxed as possible. It's ~impossible to prove any of the cryptographic stuff without a code tool, so I assume a web_fetch-style tool that can only do GET requests plus code execution.

The protocol is kind of bizarre, and described in a separate protocol.md document.

The substance is that users connect to an AWS Nitro Enclave running this relay program. It attests that it is running on Graviton5 and gives its TLS public key. Then can send TLS-encrypted messages to the enclave over GET requests. The enclave modifies these requests in the way the user requests and then forwards it on through mullvad. After receiving the upstream response, the enclave encrypts the request/response record and waits for the host to acknowledge storage before returning the response to the user. A separate mirror then copies the encrypted artifacts to a public S3 bucket with 30-day Object Lock. S3 upload is asynchronous: it is not guaranteed to finish before the user receives the response. Object Lock protects stored versions during their retention period; it does not guarantee continued public access.

Before it starts serving requests, the Nitro Enclave generates a key, and then releases a puzzle targeting roughly one week to solve at the reference speed. It creates one key per day for all requests on that day. It does this by running Monero's RandomX algorithm on 24 cores for about nine hours to generate a series of keys in parallel. These keys are then encrypted so you must do all the decryption sequentially. The standard solution to force something like this is RSA modular squaring, but this can be massively accelerated with FPGAs/ASICs, so it's difficult to prove to the AI you're not cheating and can't read the requests immediately. Monero's RandomX secures ~$80m/y of mining revenue, so there's reasonable pressure to make it faster which has thus far failed. Other standard solutions include things like drand timelock, but the organizations this depends on could be hacked by a rogue agent to make it impossible to release the underlying data.

Specifically, it requires 465M sequential RandomX hashes to get the key, and the best hardware I've tested can get 770 hashes/s.

Will this work?

Given the extremely public failure of the GET-only sandboxing mechanism with OpenAI, why do I think it will work? Firstly, I think there will continue to be RL environments where models look up information. In those situations, GET-only sandboxing is good. There will probably be more substantial sandboxes, but that seems likely also. Secondly, there are other companies that might have lax sandboxes. Thirdly, I think the odds of this actually working are quite low, but I don't have a lot of great ideas, and I think it's reasonably likely something in this vicinity does work.

I don't understand

The entire project was made by my agent, and the clients are intended to be agents. This page does not fully explain how the project works, but your agent should be able to if you point it at this page (there's llm documentation).

Public archive

The data is here. I would appreciate it if you mirrored it. The keys will be published publicly on the website once I start solving them. Mirroring helps make it impossible to lock the records forever, by ensuring multiple records.