Decrypt-side compatibility is narrower than sealing and stays explicit: the

pairing vault opens with its dedicated key first and falls back to the GitHub

keyring — active key plus `:github_token_decryption_keys` — because that is

the only key material its historical records were sealed under, and because

`config/runtime.exs` deliberately bridges an unset

`MACHINE_TOKEN_ENCRYPTION_KEY` to the GitHub key until the operator

provisions the dedicated secret. The fallback never rewraps: the only reader

the only key material its historical records were sealed under, including

every record sealed while `config/runtime.exs` bridged an unset

`MACHINE_TOKEN_ENCRYPTION_KEY` to the GitHub key. That bridge is no longer the

production configuration: the dedicated secret is provisioned, and the bridge

is now only the fallback for a node that comes up without it. It cannot stay

load-bearing unnoticed, because `RuntimeConfig.validate/1` refuses a staging or

production boot in which any two vault keys are equal — presence alone never

distinguished a provisioned key from a bridged one, which is how the bridge

outlived by a week the single deploy it was written for (#253). The bridge

survives in `config/runtime.exs` so configuration still assembles; what it can

no longer do is serve. The fallback never rewraps: the only reader

nulls `token_ciphertext` in the same transaction as a successful open

(IDENTITY-011), so no record survives a read, and every fallback-sealed

record is claimed or expired within one ten-minute pairing lifetime.

contract migration removes them the way `machine_pairings.user_id` was removed

a release after its last reader.

Amended 2026-08-25 (issue #253). "Its own key" is now checked rather than

described. `RuntimeConfig.validate/1` compares every configured vault key and

refuses a staging or production boot on any duplicate, naming the borrowing

setting and the setting it borrowed from. Distinctness is the predicate rather

than "did the boot bridge fire", so it also refuses a dedicated secret

provisioned by hand with another vault's value. Development and test are

exempt: both already configure distinct keys, and a shared key there strands

nothing a person would retry.

Evidence: `OpenAgents.Machines.TokenVault`, `OpenAgents.Accounts.TokenVault`,

`OpenAgents.Voice.RecordingVault`, `OpenAgents.ContentVault`,

`OpenAgents.Forge.AtRest`,

production. That is a fact rather than a defect, and it is the reason this

rehearsal's live half is an inventory instead of a rotation.

> **Later the same day (2026-08-25):** the pairing-vault row above is no longer

> current. `MACHINE_TOKEN_ENCRYPTION_KEY` is provisioned in Secret Manager,

> `ops/deploy/fleet-startup.template.sh` exports it, and a re-read of all three

> fleet nodes answers `machine_set=true` and `same_as_github=false`, with all

> four vault keys set and pairwise distinct. `RuntimeConfig.validate/1` now

> refuses a staging or production boot on a duplicate vault key, so the reading

> above cannot recur unnoticed. #253 records the gap and its close. The rest of

> this inventory stands: no key has been rotated here.

**No attestation has been signed here.** `OpenAgents.Reputation.keys()` returns

none on the live node, so the issuer rotation path has no production

population. The ordering rule is proven in the test process and has never been

    ten-minute window of unclaimed pairings becomes unreadable, and a person

    retries the pairing. There is no keyring because no record outlives the

    window. The code no longer reaches the GitHub key, which is #192's fix,

    but production has not provisioned `MACHINE_TOKEN_ENCRYPTION_KEY`, so the

    boot bridge in `config/runtime.exs` still configures this vault with the

    GitHub vault's active key. Until that secret is set, a GitHub key rotation

    does move this vault's key. #253 carries it.

    and since 2026-08-25 production provisions `MACHINE_TOKEN_ENCRYPTION_KEY`

    with its own value on every fleet node, so a GitHub key rotation no longer

    moves this vault's key. The boot bridge in `config/runtime.exs` survives as

    a fallback for a node that comes up without the secret, and

    `OpenAgents.RuntimeConfig.validate/1` refuses a staging or production boot

    whose pairing key equals the GitHub key, so the bridge can no longer be

    load-bearing without something failing. #253 closed on that.

  - `OpenAgents.Voice.RecordingVault` (call audio,

    `VOICE_RECORDING_ENCRYPTION_KEY`) rotates with permanent loss: one key,

    no key id, no keyring, so recordings sealed under the retired key never

neither rotation has ever run here.

`docs/2026-08-25-forge-exit-rehearsals-2-to-6.md` records the inventory.

**The gap is closed, 2026-08-25.** A later read the same day, again without

printing key material, answers `machine_set=true` and `same_as_github=false` on

all three fleet nodes, and all four vault keys are set and pairwise distinct.

`MACHINE_TOKEN_ENCRYPTION_KEY` is provisioned in Secret Manager and exported by

`ops/deploy/fleet-startup.template.sh`, and the fleet has rolled onto a revision

that carries it. `OpenAgents.RuntimeConfig.validate/1` now refuses a staging or

production boot on a borrowed vault key, so the next reader does not have to

compare two configured values by hand to learn whether the bridge is

load-bearing. The retired GitHub keyring is still empty and no reputation

issuer key is admitted; neither rotation has run.

## 5. Operator loss

**Proves:** that the source and the receipts come back from the WAL alone.

| `GITHUB_CLIENT_SECRET` | `openagents-staging-github-client-secret` | web, fleet | OAuth app rotation |

| `GITHUB_TOKEN_ENCRYPTION_KEY` | `openagents-staging-github-vault-active` | web, fleet, migrator | Scheduled vault rotation or suspected exposure |

| `GITHUB_TOKEN_DECRYPTION_KEYS_JSON` | `openagents-staging-github-vault-previous` | web, fleet, migrator, only during rewrap | Delete after every row uses the active key ID |

| `MACHINE_TOKEN_ENCRYPTION_KEY` | `openagents-staging-machine-vault-active` | web, fleet | Scheduled vault rotation or suspected exposure; rotation strands at most one ten-minute window of unclaimed pairings (VAULT-001). Until this secret exists, `config/runtime.exs` bridges the machine pairing vault to `GITHUB_TOKEN_ENCRYPTION_KEY` |

| `MACHINE_TOKEN_ENCRYPTION_KEY` | `openagents-staging-machine-vault-active` | web, fleet | Scheduled vault rotation or suspected exposure; rotation strands at most one ten-minute window of unclaimed pairings (VAULT-001). `config/runtime.exs` bridges an unset value to `GITHUB_TOKEN_ENCRYPTION_KEY`, and a staging or production boot then refuses on the duplicate rather than serving two vaults from one key (#253) |

| `OPENAI_API_KEY` | `openagents-staging-openai-api-key` | web, fleet | Provider rotation or suspected prompt/log exposure |

| `VOICE_RECORDING_ENCRYPTION_KEY` | `openagents-staging-voice-recording-key` | web and fleet when recording is admitted | Scheduled recording-key procedure or suspected exposure |

| `CONTENT_ENCRYPTION_KEY` | `openagents-staging-content-vault-active` | web, fleet, migrator | Scheduled vault rotation or suspected exposure; the content vault has no keyring, so rotation strands every sealed voice transcript, compaction summary, preference observation, and project note (VAULT-001) |

  rotation procedure moves a retired key into that keyring rather than

  deleting it. The fallback covers two bounded populations: pairings sealed by

  the previous release during a deploy, and pairings sealed while

  `config/runtime.exs` still bridges `:machine_token_encryption_key` to the

  GitHub key pending `MACHINE_TOKEN_ENCRYPTION_KEY` provisioning.

  `config/runtime.exs` bridged `:machine_token_encryption_key` to the GitHub

  key. That bridge is no longer production's configuration — the dedicated

  secret is provisioned — and `OpenAgents.RuntimeConfig.validate/1` refuses a

  staging or production boot whose vault keys are not distinct, so the bridge

  cannot become load-bearing again without failing (#253).

  The fallback deliberately never rewraps. The only reader is

  `OpenAgents.Machines.claim_locked_pairing/1`, which nulls

         :ok <- validate_endpoint(settings, environment),

         :ok <- validate_database(settings, environment),

         :ok <- validate_github(settings, environment),

         :ok <- validate_vault_separation(settings, environment),

         {:ok, features} <- validate_features(settings, environment, staging_gate),

         :ok <- validate_staging_cleanup(settings, environment, staging_gate),

         :ok <- validate_providers(settings, features),

         # it historically borrowed from. `config/runtime.exs` bridges an

         # unset `MACHINE_TOKEN_ENCRYPTION_KEY` to the GitHub key, so an

         # absent value here means both are missing (VAULT-001, #192).

         # Presence alone cannot tell a provisioned key from a bridged one;

         # `validate_vault_separation/2` is what does (#253).

         :ok <-

           ensure(

             encryption_key?(machine_token_key),

    end

  end

  # The vaults VAULT-001 keeps apart, in the order a collision is reported.

  # The GitHub vault comes first because it holds the key the others

  # historically borrowed, so a duplicate is named against the borrower.

  @vault_key_settings [

    :github_token_encryption_key,

    :machine_token_encryption_key,

    :voice_recording_encryption_key,

    :content_encryption_key

  ]

  # Each vault seals under its own key (VAULT-001), and until this check

  # nothing enforced the "own" half. `config/runtime.exs` bridges an unset

  # `MACHINE_TOKEN_ENCRYPTION_KEY` to the GitHub vault's active key so the

  # deploy that introduced the variable could boot before an operator

  # provisioned the secret. A bridged boot presents a perfectly valid

  # 32-byte key that belongs to another vault, so the presence check above

  # passes and a GitHub rotation quietly moves the pairing vault with it —

  # correct on the day it shipped, wrong a week later, and indistinguishable

  # from correct without reading two values by hand (#192, #253).

  #

  # Distinctness is the predicate rather than "did the bridge fire", because

  # it also catches an operator who provisions the dedicated secret with the

  # GitHub vault's value, which is the same defect by a different route.

  #

  # This lives here rather than in `config/runtime.exs` on purpose. The

  # bridge is deliberate and still assembles a complete configuration, so

  # configuration evaluation keeps working everywhere; what changes is that

  # a staging or production node refuses to *serve* on a borrowed key, at

  # the declared fail-closed boundary, with the setting named. Development

  # and test are exempt: both already configure distinct keys, and a shared

  # key there strands nothing a person would retry. That is the same posture

  # the content vault's key already takes in `validate_features/3`.

  #

  # Only configured keys are compared. An absent key is another check's

  # error, and a vault whose feature is off has none.

  defp validate_vault_separation(settings, environment)

       when environment in [:staging, :production] do

    @vault_key_settings

    |> Enum.map(&{&1, Map.get(settings, &1)})

    |> Enum.filter(fn {_setting, key} -> encryption_key?(key) end)

    |> Enum.reduce_while(%{}, fn {setting, key}, seen ->

      case Map.fetch(seen, key) do

        {:ok, owner} -> {:halt, {setting, owner}}

        :error -> {:cont, Map.put(seen, key, setting)}

      end

    end)

    |> case do

      {setting, owner} ->

        error(setting, "must differ from #{owner}: no vault seals under another vault's key")

      seen when is_map(seen) ->

        :ok

    end

  end

  defp validate_vault_separation(_settings, _environment), do: :ok

  defp token_key_id?(key_id) when is_binary(key_id),

    do: String.match?(key_id, ~r/\A[a-zA-Z0-9][a-zA-Z0-9._-]{0,63}\z/)

             RuntimeConfig.validate(settings)

  end

  test "a staging or production release refuses to serve on a borrowed vault key" do

    # VAULT-001, issues #192 and #253. The presence check above passes for a

    # bridged boot, because `config/runtime.exs` hands the pairing vault the

    # GitHub vault's key, which is a valid 32-byte key. Distinctness is what

    # separates a provisioned key from a load-bearing bridge.

    settings = staging_settings()

    github_key = Map.fetch!(settings, :github_token_encryption_key)

    assert {:ok, _config} = RuntimeConfig.validate(settings)

    bridged = Map.put(settings, :machine_token_encryption_key, github_key)

    assert {:error, %{setting: :machine_token_encryption_key, reason: reason}} =

             RuntimeConfig.validate(bridged)

    assert reason =~ "github_token_encryption_key"

    # The same rule holds for every other vault, and names the borrower.

    assert {:error, %{setting: :content_encryption_key}} =

             settings

             |> Map.put(:content_encryption_key, github_key)

             |> RuntimeConfig.validate()

    assert {:error, %{setting: :voice_recording_encryption_key}} =

             settings

             |> Map.put(

               :voice_recording_encryption_key,

               Map.fetch!(settings, :machine_token_encryption_key)

             )

             |> RuntimeConfig.validate()

    # Development boots the bridge without complaint: a shared key there

    # strands nothing a person would retry.

    assert {:ok, _config} =

             bridged

             |> Map.put(:runtime_environment, :development)

             |> Map.put(:migrate_on_boot, false)

             |> Map.put(:secure_cookies, false)

             |> update_oauth(:redirect_uri, "http://localhost:4000/auth/github/callback")

             |> Map.put(:github_token_encryption_key_id, "development-2026-08")

             |> RuntimeConfig.validate()

  end

  test "forge mirror remotes refuse credential-bearing URLs" do

    for url <- [

          "https://operator:secret@mirror.example/openagents.com.git",