Tier C key wiring

@@ -21,7 +21,7 @@ The universal principle is that API keys live at the gateway only — never in a

## Where keys live

Provider API keys are held in systemd unit drop-in files on the workspace virtual machine. The drop-in path follows the standard systemd pattern for extending a service unit without modifying the unit file itself. Each provider may have its own drop-in file, which makes per-provider rotation atomic: rotating the key for one provider does not require touching any other provider's configuration.
Provider API keys are held in systemd unit drop-in files on the workspace virtual machine. The drop-in path follows the standard systemd pattern for extending a service unit without modifying the unit file itself. Each provider may have its own drop-in file, which makes per-provider rotation atomic: rotating the key for one provider does not require touching any other provider's configuration. (Correction, 2026-08-02, verified against canonical `origin/main`: the real config, `service-slm/docs/deploy/local-doorman.env.example`, holds Anthropic, Gemini, and OpenAI keys together in one shared env file, loaded via a single `EnvironmentFile=` override applied to the whole unit — not one drop-in file per provider. Per-provider rotation is not atomic as described. The four permitted Tier C call purposes described elsewhere in this article — editorial refinement, citation grounding, entity disambiguation, initial knowledge graph construction — are independently confirmed accurate. Flagged, not resolved.)

Drop-in files are owned by root and readable by the service user running the Doorman. They are not tracked in any version-control repository, not included in any backup that publishes outside the virtual machine, and not present anywhere in the Git history. The `.gitignore` at the workspace root does not need to mention them because they live outside the repository entirely.