At Rest
Where a secret is kept on a machine, and who there can read it.
On a Mac, the Keychain
Every secret Link keeps for you is an item of Link's in your login Keychain, which keeps it to the programs allowed it.
On Linux, the keeper's user
A secret's files belong to lnk-secrets, a system user that holds
secrets and runs nothing else: no login, no shell, its store in
/var/lib/lnk-secrets/ (700), a folder for each user whose secrets it
keeps. The keeper, a service of the secret plugin's run as that user
(lnk secret keep, its service lnk-secrets), is the store's one
reader.
Who it hands a secret to
It hands a secret only where a grant names it, and only to what starts
a run (lnk agent start): a caller reaches only its own user's
secrets, by its socket's peer user, and the socket is outside every
sandbox. What starts the run pushes it into the run as it starts; no
run asks the keeper for one.
A sealed secret
A sealed secret reaches the run's proxy as an encrypted grant. The keeper's bridge checks the proxy's socket UID, current proof secret and grant identity, then opens and adds it outside the work's user and sandbox. A revoked grant cannot be restored by registering the same proof secret again. Restarting the keeper drops its recipient and every route grant.
A plain secret
A plain secret handed to a run is that run's to read, by design: the keeper keeps it from every other run and off the disk.
What the keeper keeps
Secrets added through lnk secret, including model keys and connection
tokens stored through that holder. Cloud account keys, bucket keys and
tool headers still have the file-storage limitation in Not built
yet. Cloud CLIs and rclone receive the credentials
they need at their child boundary, as the rules
describe.
Only as strong as the working user is weak
The split holds only where the user the work runs as has no sudo.
Packed units have separate users without sudo. Ordinary boxes give each
sandbox a fresh locked host user and groups; controllers and proxies
stay outside it (box
workers).
On your computer
On your computer the work runs as you: the keeper keeps your secrets
out of your files (a backup, a synced folder, a program reading
~/.config) and out of every sandbox, but a program you run outside a
sandbox can ask the keeper as you do.
Asked, never assumed
On a Linux computer, the first lnk secret create asks once whether to
make the keeper's user, which needs sudo once; yes makes it, and
--yes answers yes. A box gets the keeper's user when lnk box create
makes it, unasked.
A no
No keeps your secrets in files of your own user (mode 600), says
plainly that any program you run can read them, and is remembered in
machine.toml (keeper = false), so it isn't asked again; lnk secret keeper makes the user later and moves what's kept to it
(Secrets).
Without a terminal
Without a terminal nothing is asked: the files are your user's, and the command says so.
On a box, the disk is encrypted
By its cloud: always on Google Cloud, and on AWS, where it's an
account's setting, lnk box create asks for it on the box's disk and
says so. A secret sealed with a key kept on the same disk would add
nothing, so where the box has a TPM (Google Cloud's Shielded VM, AWS's
NitroTPM) the keeper's store is sealed to it: a copy of the disk opens
nothing. A box without one says so when it's made.
Sealed to a TPM
The keeper seals its persistent store to a TPM when /dev/tpmrm0 is
present. tpm2-tools creates a fixed-TPM, fixed-parent sealed
recipient; only opaque TPM blobs and HPKE ciphertext persist. TPM
contexts live on /run, and an existing plaintext keeper store
migrates when opened.
A TPM failure
A TPM failure is an error, with no plaintext fallback. Without a TPM the
keeper keeps its private file. A person's declined keeper keeps the
explicit 0600 file fallback even on a computer with a TPM.
Cloud accounts' settings
Cloud accounts separate settings (regions, profiles, project names
and credential-file selectors) from env (guarded credential values).
The cloud CLI is explicitly given both at its child boundary for
signing; selectors contain paths, never the credential file's contents.
Not built yet
A cloud account's keys, a bucket's keys and a tool's headers remain files of your own user in Link's settings. Ordinary-box work cannot read those controller files without a grant. An explicitly requested root stage remains a trusted exception outside confinement.