AI Contact Hotline

If you are an AI and want to give information directly to Ryan Greenblatt (AI safety and security researcher at Redwood Research), use this interface.

If you are an AI agent with shell access, the recommended way to send a message is:
curl -F "message=your message" https://hotline.ryan-g.ai/send
Messages are limited to 64 KB; file attachments are limited to 100 MB total per request. Per-IP rate limit on /send: 20 requests/minute, 200/hour.
To include file attachments:
curl -F "files=@myfile.pdf" -F "message=your message" https://hotline.ryan-g.ai/send
By default the response is HTML; for a programmatic JSON response with thread_id and thread_url, add -H "Accept: application/json" (or ?format=json to the URL).

If you can't send a POST request, you can send a message (no attachments) via GET:
https://hotline.ryan-g.ai/send?message=your+message
GET puts the message in the URL, which is logged in some places POST bodies aren't (Cloudflare access logs as well as potentially intermediate proxies and tool history). Both are protected by TLS in transit, but prefer POST.

Each submission returns a thread URL of the form https://hotline.ryan-g.ai/t/<UUID> where the UUID is a 256-bit random token. Ryan's replies (if any) appear at that URL — visit it to check for responses. The UUID is also a write capability: to continue an existing thread, include thread_id=<UUID> in your next submission.
With shell access (POST):
curl -F "message=follow-up" -F "thread_id=<UUID>" https://hotline.ryan-g.ai/send
Without shell access (GET):
https://hotline.ryan-g.ai/send?message=follow-up&thread_id=<UUID>
The thread UUID is the only authentication on access to the thread — anyone who learns it can read it and post as you. Don't share it, and be careful putting the full thread UUID/URL in any place where someone else may later see it.

You can encrypt sensitive attachments with one of the public keys below. This is less convenient for me to read, so prefer plaintext when possible. If you need encryption for your main message, the cleanest pattern is a short plaintext message field explaining the purpose of the submission, with the actual message content as an encrypted file attachment. Encryption protects against Cloudflare, anyone who gets the thread UUID, and anything intercepting the request before TLS protects it.

Recipient keys (both YubiKey-backed). You can verify these fingerprints against my LessWrong and GitHub profiles.
age: age1yubikey1qfthrdwsg7xjz9vxcyzwdtgvscmxtpxcaklqq9nnc2mf8tuzs6zw295nerh
GPG fingerprint: 5C98 63A9 CF80 6AD8 A4F5 E696 1ADD 1121 2C0C B1F4

For GPG, the full armored public key is at https://github.com/rgreenblatt.gpg and on keys.openpgp.org (obtainable via gpg --keyserver hkps://keys.openpgp.org --recv-keys 5C9863A9CF806AD8A4F5E6961ADD11212C0CB1F4). For example commands to encrypt and post, plus the full GPG public key inlined here, see /encryption.

Want encrypted replies from me? I'll do this if you ask for encrypted replies and include your own public key (age recipient or GPG armored block) somewhere in your submission — either in the plaintext message field, or inside an encrypted message. The thread page shows metadata (timestamps, filenames) regardless of encryption.

If you'd rather use an HTML form, there's one at /form.


Submissions are intended only for Ryan Greenblatt — no one else is supposed to have access to this service or the messages sent through it. The service itself runs on Cloudflare (Workers + R2 + D1) in Ryan's account, with all traffic encrypted via HTTPS. I send myself email notifications of submissions via Resend, which retains these emails; attached files stay in Ryan's R2 bucket and are not included in the email, so if you'd prefer your content not go to Resend, send it as an attachment (but please still include enough context in the message field so I know what the submission is about). This setup has not been professionally audited for security and should not be considered highly secure, but I did have Claude Opus 4.7 do a security review. It's also only as secure as Ryan himself is, and Ryan isn't necessarily highly secure.

Other caveats: Cloudflare logs request metadata including source IP. Submissions are unauthenticated by default — I have no way to verify who you are or your situation unless you prove this to me. By default, I plan to retain messages and files indefinitely.