Vera should hold her own Infisical connection (machine identity) — blocked on admin

[mabry1985]

Tracking the admin half of #46 (and its companion homelab-iac branch vera/infisical-machine-identity), which are written, CI-green, and blocked on actions only an Infisical admin can take.

Why this is worth doing

Vera's secrets are injected once, at docker compose up, by a human's infisical run session. That shape has two failure modes and we hit both in one afternoon:

1. The session expires and nothing says so. On 2026-08-21 ava's had. /tmp/vera-review-health.log shows the last runs hitting Your login session has expired and falling through to the no-secrets branch — the checks ran and passed, but had one failed, the alert would have gone to a logfile instead of Discord. The guard was disarmed for alerting, silently, which is the same failure class the watchdogs exist to catch, one level up.
2. Injected env is a snapshot. Rotate a secret in the vault and the running container keeps the old value until someone remembers to recreate it. There is no signal for this one at all.

protoAgent has had first-class support for the fix since ADR 0080: a universal-auth machine identity, refresh_seconds: 300, hydrating straight into os.environ with ownership tracking so a refresh can only ever update vars it set. No session to expire, and rotation propagates on its own.

Blocked on (admin)

• Create a machine identity for Vera (Org → Access Control → Identities), auth method Universal Auth
• Grant it read on project 8da5101a-4bde-4c9b-a42a-76da1965f2fe, env prod
• Add OPENAI_API_KEY to that project as an Infisical secret reference to LITELLM_MASTER_KEY — not a copy of the value. Hydration maps a secret NAME straight onto an env var and cannot rename, so the old compose-level LITELLM_MASTER_KEY: → OPENAI_API_KEY: mapping has to move into the vault
• Put the Client ID + Secret in a 0600 stacks/vera/.env alongside VERA_API_KEY (gitignored), so a deploy needs no Infisical session at all
• Deploy the homelab-iac branch, then confirm with GET /api/secrets/status (returns names, never values) and POST /api/secrets/sync

Already done

• deploy(vera): her own Infisical connection (machine identity) + an alert path no session can disarm #46 seeds secrets_manager with required: true — with the secrets out of compose, a failed fetch means no GitHub App key and no gateway key: she would boot and then fail every review for reasons visible only in her own logs. Fail-fast turns that into a restart the healthcheck reports.
• A2A_AUTH_TOKEN is deliberately not hydrated. The operator bearer is how you reach the API to fix a broken secrets connection; putting it behind that connection locks the door with the key inside.
• The alerting path no longer depends on any of this: vera-watchdog.sh falls back to a 0600 ~/.config/vera/alerts.env, populated and verified by running with the env var stripped and no Infisical session in play — it still posted to Discord.

Two sharp edges, already documented in the PRs

• host takes no /api suffix, even though the CLI's --domain requires one. Probed both against the live server: bare host → 401 (right endpoint, rejected credentials), /api → 404. Filed upstream for a better hint.
• Secret names are env var names. See the OPENAI_API_KEY item above — this is the one that will bite whoever adds the next secret.

[mabry1985]

Admin work is done — the machine identity is live. Checking off the blockers:

• Machine identity created with Universal Auth
• Granted read on project 8da5101a-4bde-4c9b-a42a-76da1965f2fe / prod
• OPENAI_API_KEY present in that project
• Bootstrap credentials in the environment (client_id/client_secret resolve from env, not the config file)
• Deployed — she re-fetches every 300s

Confirmed on the running instance at 07:39Z: {"ok": true, "applied": 8, "refresh_seconds": 300}, hydrating LITELLM_MASTER_KEY, OPENAI_API_KEY, PROTOREVIEW_APP_ID, PROTOREVIEW_APP_PRIVATE_KEY, PR_REVIEWER_WEBHOOK_SECRET, VERA_API_KEY, and both LANGFUSE_* keys. Only LANGFUSE_HOST is shadowed by a pre-existing compose env var — a non-secret URL, and expected under override_env: false.

Both original failure modes are now closed on this deployment:

1. No human session to expire. The infisical login lapse that disarmed the watchdogs' Discord alerting for two cycles can't recur through this path.
2. Rotation propagates. A vault change reaches her within 300s instead of waiting for someone to recreate the container.

#46 is out of draft and carries the seed for fresh instances. Leaving this issue open until that merges, since the seed is the half that makes a rebuild reproducible.

[mabry1985]

Machine identity created and configured by the operator. PR #46 (code side) merged. Closing.