security(engine): FCM service-account private key is a plain env var readable by every agent session

[thedancingdeveloper]

Summary

The engine container's environment carries the Firebase Cloud Messaging service account JSON, including its RSA private key, as a plain environment variable (MYDEVENV2_FCM_SERVICE_ACCOUNT_JSON, legacy name of ENGINE_FCM_SERVICE_ACCOUNT_JSON). The engine runs as the same uid as every agent session it spawns, so any process in a session can read it from /proc/<engine pid>/environ.

Verified on prod 2026-09-05 from inside an ordinary Claude Code session:

$ ls -l /proc/10/environ          # pid 10 = vogt-engine
-r-------- 1 sprooty sprooty 0 ... /proc/10/environ
$ tr '\0' '\n' < /proc/10/environ | grep -c FCM_SERVICE_ACCOUNT
1

The value is the complete service_account document (private_key_id, private_key, client_email, ...). I have not copied it anywhere; it was seen while dumping the engine's environment during the 0.5.3 incident investigation, which is exactly the kind of routine action that leaks it.

Every other secret in the same environment is either a file secret under /run/secrets (vogt_core_token, github_token, vogt_engine_token) or a name-only breadcrumb (ENGINE_AGENT_AUTH_SECRETS, ..._TOKEN_PROJECT_ID). This one is the exception, and it is the one that grants push-notification signing for the whole project.

Why it matters

• Any agent session, any MCP bridge, any tool an agent runs, and any transcript that happens to include an env dump can exfiltrate a long-lived Google service-account key.
• The brokered-credential model (security(engine): spawned PTY/GUI/agent processes inherit all engine secrets from the environment [high] #511, engine: #511 secret-strip leaves agent sessions with no on-demand secrets-manager access and no signposting #566) exists precisely so sessions hold only the tokens they were granted. This variable bypasses it.
• The key is not scoped or short-lived; leaking it means rotation, not revocation.

Proposed fix

1. Load the FCM service account from a file secret (ENGINE_FCM_SERVICE_ACCOUNT_FILE, bind-mounted at /run/secrets/fcm_service_account, mode 0400) and stop accepting the JSON via env. Mirror how VOGT_CORE_TOKEN_FILE is handled.
2. Have the engine read it once at startup and drop it from its own environment, or better, read it lazily only in the push sender.
3. Rotate the exposed key in the Google project once the file path is deployed, and delete the old key id.
4. Add a startup check that refuses to run if any *_JSON/*_KEY/*_SECRET env var holds a value longer than a token (or a denylist for this specific name) so the regression cannot come back quietly.
5. Consider running sessions under a different uid from the engine, so /proc/<engine>/environ is unreadable regardless of what it holds.

Related: #265 (committed Firebase config rotated), #511 / #566 (brokered credential contract).

Implementation/closure plan

1. Complete deployment of ENGINE_FCM_SERVICE_ACCOUNT_FILE; do not expose the document through the engine environment.
2. Rotate and revoke the historically exposed Firebase service-account key.
3. Verify vogt-dev and vogt-prod use the file-backed credential and that child sessions cannot read it from /proc or inherited environment.
4. Add a regression test that rejects inline service-account JSON in the shipped deployment path.
5. Send a real push after rotation and attach the evidence.

This remains a private-estate security task; no FCM credential or estate configuration belongs in the public AIO image.

[thedancingdeveloper]

Found while investigating #580; independent of it.

[thedancingdeveloper]

Engine side landed on dev in PR #587 (ecb8573): ENGINE_FCM_SERVICE_ACCOUNT_FILE / fcm_service_account_file is the documented form; the inline variable is scrubbed from the engine process environment at boot (sessions no longer inherit it) and warned about. Leaving this open for the estate steps: point the vogt-dev/vogt-prod stacks at a file secret (bind-mount like vogt_core_token), then rotate the exposed key in the Google project and delete the old key id. /proc/<engine pid>/environ keeps showing the original value until the stack stops passing it.

[thedancingdeveloper]

Status: partially done. The engine fix shipped in 0.5.4 (PR #587): it reads the FCM key from ENGINE_FCM_SERVICE_ACCOUNT_FILE (/run/secrets, mirroring VOGT_CORE_TOKEN_FILE) and scrubs the inline JSON from its own environment at boot, so sessions no longer inherit it.

Remaining, estate-side (per the 2026-09-05 comment): switch the vogt-dev/vogt-prod stacks to pass the file secret instead of ENGINE_FCM_SERVICE_ACCOUNT_JSON, then rotate the exposed key in the Google project and delete the old key id — until the stack stops passing the inline value it is still readable via /proc/<engine>/environ. Keep open until the stacks are cut over and the key is rotated.

[thedancingdeveloper]

Reframed closure criteria (aligned with #637)

Updating this issue's goalposts, because #637 changed the surrounding model and the original "sessions cannot read it" criterion is no longer the right test.

The principle these two issues share:

Credentials are reachable on purpose (via the #637 vault identity), never sitting in process memory by accident (in an env var / /proc/<pid>/environ).

#637 is an explicit operator decision to give sessions the full Infisical identity (AGENT_AUTH_MODE=identity) so agents don't hit brick walls — a session can read any secret from the vault, on purpose and auditably. That means #583 is not about denying agents the FCM key. It's about eliminating the ambient copy: the RSA private key was sitting in the engine's environment, where a routine env//proc dump during the 0.5.3 incident scooped it into a transcript. That accidental-leak vector is real and worth closing regardless of #637.

So under #637, this fix is hygiene against accidental spillage, not a boundary against deliberate access — and that's the correct, honest scope.

Done

• Engine reads the key from a file and scrubs any inline copy from its own environment at boot — ecb8573, on dev/main/prod branches.
• Shipped stack delivers it as a /run/secrets/fcm_service_account file secret, never inline — security(deploy): deliver the FCM signing key as a file secret, never an env var (#583) #644 (merged to dev), with a regression test that fails if the inline JSON env key ever returns.
• The exposed Google service-account key has been rotated and revoked (operator, 2026-09-07): a fresh key was generated, deployed to both Infisical entries (HOMELAB_MYDEVENV2_FCM_SERVICE_ACCOUNT_JSON + ..._COMPACT), and the old keys deleted in the Cloud Console.

Remaining (the honest closure criteria)

• Estate delivery: the vogt-dev / vogt-prod ops overlays stop setting MYDEVENV2_FCM_SERVICE_ACCOUNT_JSON inline and mount /run/secrets/fcm_service_account with ENGINE_FCM_SERVICE_ACCOUNT_FILE pointing at it (dev first, then prod).
• Verify the ambient leak is closed: from an ordinary agent session on dev and prod, tr '\0' '\n' < /proc/<engine>/environ | grep -c FCM_SERVICE_ACCOUNT is 0, and the mounted file is mode 0400.
• Push evidence: one push per environment after the file-secret cutover, confirming push still works on the rotated key delivered by file.

Deliberate vault access via the #637 identity is expected and fine — it is not a regression against this issue.

Related: #637 (identity passthrough — the sanctioned deliberate-access path), #511 / #566 (the brokered-credential contract #637 opts out of), #644 (the shipped-stack file delivery).