Skip to content

SYSTEM Cited by 1 source

Tokenized Tokens (Fly.io)

What it is

Tokenized Tokens is Fly.io's secret-tokenization system — a platform primitive for issuing placeholder credentials that a hardware-isolated substrate on Fly.io's side substitutes for the real credential at egress. A client (in 2025-era framing, often an LLM-driven coding agent) holds only the placeholder; the real OAuth / API / session credential lives on a Fly Machine the client cannot touch.

Substrate documented in Fly.io's 2024 post Tokenized Tokens and referenced in the 2025-04-08 "Our Best Customers Are Now Robots" post as the architectural answer to the LLM-credential-grant problem.

Why Fly.io built it

The 2025-04-08 post names the problem directly: robots want broad access to user accounts (Gmail, Stripe, Spotify, …); users are reluctant to permanently hand over OAuth credentials. Tokenization breaks the symmetry:

On a modern cloud platform, there's really no reason to permanently grant Sam Altman Google Mail access, even if you want his robots to sort your inbox. You can decouple access to your mail spool from persistent access to your account by tokenizing your OAuth tokens, so the LLM gets a placeholder token that a hardware-isolated, robot-free Fly Machine can substitute on the fly for a real one.

(Source: sources/2025-04-08-flyio-our-best-customers-are-now-robots)

The architectural claim is that a cloud platform running hardware-isolated VMs is the right substrate for the substitution hop — the tenant's Machines and the broker Machine are on the same platform (so egress routing is enforceable) but on different isolated hardware (so the tenant's code cannot read the broker's memory).

Substrate

Per the 2025-04-08 post's framing, the broker is a robot-free Fly Machine:

  • Runs on Fly Machines — Firecracker micro-VM isolation.
  • Isolated from the tenant's workload — on different worker hardware, unreachable except through the published substitution API.
  • Minimal code surface — only the substitution logic runs. No tenant code, no LLM code.
  • Policy-driven — the broker knows which placeholder substitutes for which real secret against which destination.

The 2024 Tokenized Tokens post owns the substrate design details (cryptographic sealing, placeholder issuance, key management) — this wiki page is a minimum-viable stub grounded in the 2025-04-08 reference.

Why this matters for RX

Robot Experience (RX) requires a secret-handling story that (a) the user can reason about and (b) the robot can use without the user handing over the crown jewels. Tokenized Tokens is the substrate the 2025-04-08 post cites as Fly.io's identity-plane RX primitive:

  • Broker owns the real secret.
  • Client (LLM / agent) holds a placeholder.
  • The placeholder is scoped to the substitution policy — it can be used for mail-reads but not account-deletes, for example.
  • Revoking the placeholder is independent of revoking the underlying OAuth grant at the third party — the user narrows or kills the placeholder on Fly's side without going to log into Google and revoke the whole connection.

Beyond LLMs: the API-bridging framing

The 2025-04-08 post calls out that Tokenized Tokens is useful even without robots as the primary driver — API-to-API integration platforms (Zapier / Make / IFTTT-shape) are fundamentally secret-management businesses:

There are several big services that exist to knit different APIs together, so that you can update a spreadsheet or order a bag of Jolly Ranchers every time you get an email. The big challenge about building these kinds of services is managing the secrets. Sealed and tokenized secrets solve that problem. There's lot of cool things you can build with it.

(Source: sources/2025-04-08-flyio-our-best-customers-are-now-robots)

What's not public

  • Cryptographic detail of the sealing model (envelope encryption? HSM? format-preserving encryption?) — not walked in the 2025-04-08 post; deferred to the 2024 post (to be ingested separately).
  • Placeholder format — opaque; no public schema.
  • Substitution policy language — the allowed (placeholder, destination, shape) tuples. Not walked.
  • Revocation / rotation semantics — not engaged in the 2025-04-08 post.
  • Latency overhead of the broker hop — not disclosed.
  • Operational numbers — usage volume, placeholder issuance rate, substitution counts — none disclosed.

Seen in

Last updated · 200 distilled / 1,178 read