LanternDOCS

Identity & Secrets

Every headless agent spawn gets its own cryptographic identity, and secrets are vended to it at execution time over a mutually-authenticated channel — never baked into the image, never sitting in an environment variable on disk. The two are linked: the per-instance identity is what authenticates the secret-vending call.

Per-instance Ed25519 identity

At spawn, the runtime issues the instance its own Ed25519 keypair. The identity is scoped to that single spawn — two runs of the same agent have different keys — and it is what the observability layer uses as agent_instance_id to keep traces from colliding.

Externally verifiable

The instance's public identity is verifiable at a well-known endpoint, so a downstream service can confirm it is talking to a genuine Lantern-issued instance:

GET /.well-known/lantern-agent-identity

Short-TTL secret vending

The workload never ships with secrets. Instead it requests them at runtime via VendSecret, authenticating with a Bearer credential tied to its per-instance identity. Vended secrets are short-TTL — they expire quickly, so a leaked value has a small blast radius — and the channel is mTLS, so both ends are authenticated.

  • Bearer on VendSecret. The instance presents a credential derived from its spawn identity; an unauthenticated request gets nothing.
  • Short TTL. Secrets are vended just-in-time and expire, rather than living for the life of the pod.
  • mTLS transport. The vending channel is mutually authenticated; the secret never crosses an unauthenticated hop.

The lantern.secret/... ref form

In the spec you reference a secret, you do not embed it. The runtime resolves the reference at execution time and hands the value to the workload — typically at a path like /run/lantern/secrets/<NAME> — so the raw value never appears in the image, the environment, logs, traces, or run state. From demo 02:

secrets:
  - env_name: USER_AGENT
    secret_uri: lantern.secret://__tenant__/key/scraper-user-agent
Note: The lantern.secret/... ref form is the same convention used across the platform — see Security. The runtime is where it is resolved, inside the isolation boundary, at the moment the workload needs it.
Important: Pair secret vending with the right isolation class. A workload that loads internet packages and also holds a secret should be untrusted with an egress allowlist, so a compromised dependency can't exfiltrate the vended value to an arbitrary host.

What you get

  • Per-spawn Ed25519 identity, externally verifiable at /.well-known/lantern-agent-identity.
  • Bearer-authenticated, short-TTL secret vending over mTLS.
  • Reference-form secrets resolved inside the isolation boundary — raw values never touch the image, env, logs, or run state.