Sprites + Tokenizer: Secret-injecting proxy pattern for sandboxed AI agents?

, ,
1

I’ve been experimenting with Sprites as sandboxed environments for running Claude Code autonomously, and I’m trying to figure out the best way to give sandboxed code access to external APIs without putting credentials inside the sandbox.

Core question: Is there a supported way for Sprites to call internal Fly services (6PN / Flycast / .internal), or are Sprites intentionally isolated to *.sprites.app + public egress only?

The Pattern

Simon Willison recently wrote about Deno Sandbox, which uses a “secret-injecting proxy” — the sandboxed code never sees credentials; instead, an intermediary proxy injects them into outbound requests. In that post, Simon noted:

From a comment on Hacker News I learned that Fly have a project called tokenizer that implements the same pattern. Adding this to my list of tricks to use with sandboxed environments!

This is exactly what I want for Sprites. The architecture I’m imagining:

Sprite (sandboxed client)  →  Tokenizer (proxy)  →  External APIs
     NO secrets                  injects creds        (GitHub, OpenAI, etc.)

The sandboxed code can make authenticated API calls, but can never exfiltrate the credentials — even if the code running inside is untrusted.

What I’ve Found So Far

I did some network probing from inside a Sprite:

# ip addr show (inside sprite)
5: spr0@if6: ...
    inet 10.0.0.1/24 scope global spr0
    inet6 fdf::1/64 scope global

# cat /etc/resolv.conf
nameserver 10.0.0.2
nameserver fdf::2

The IPv6 prefix is fdf::, not Fly’s 6PN fdaa::, and DNS points to the sprite’s own resolver rather than .internal. So Sprites appear to be on their own isolated network, not on the Fly private network (6PN).

This means a Tokenizer instance running as a regular Fly Machine wouldn’t be reachable from a Sprite via .internal DNS.

My Questions

  1. Is there any way for a Sprite to reach a Fly Machine on the private network? Or are Sprites intentionally fully isolated from 6PN?

  2. Could Tokenizer run as a Sprite itself? Then the client Sprite would reach it via its .sprites.app URL. Is Sprite-to-Sprite communication (via HTTPS through the Fly proxy) a supported pattern?

  3. Is there a roadmap for Sprite ↔ Machine private networking? The spr0 interface and fdf:: prefix suggest a custom network layer that could potentially bridge to 6PN in the future.

  4. Has anyone else tried this pattern with Sprites? Running AI coding agents (Claude Code, Codex, etc.) in Sprites is a natural use case, and secret management feels like the biggest friction point.

Use Case

I’m running Claude Code inside a Sprite with checkpoints (great feature — auth state survives restore!). The missing piece is letting CC make authenticated API calls (git push, API requests) without baking secrets into the sandbox. The Tokenizer proxy pattern would solve this cleanly.

Would love to hear from the Fly/Sprites team or anyone who’s explored similar setups.

1 Like
3

Plus 1 on this use case. I’m enjoying using sprites but very conscious of the tokens that live within the sprite. Ideally, I’d love for the sprites team to have clear docs/features on how to manage tokens when using sprites.

For me, I use GitHub’s gh tool from my sprite and I can lock that down by providing the sprite with fine-grained tokens (that have limited access to a single repo). I still don’t want that token on the public internet but at least the blast radius of exfiltration is somewhat limited should the worst happen.

1 Like