Provider Auth Boundary
Security boundary for OpenAI, Anthropic, GitHub, xAI, and other provider credentials when running harnesses through Coven.
1 min read
Provider credentials stay with the harness. Coven supervises a PTY; it does not become OpenAI, Anthropic, GitHub, xAI, or any other provider's credential layer.
Rule
Coven never stores, proxies, persists, or mints provider credentials.
| Harness id | Login command | Credential owner |
|---|---|---|
codex | codex login | Codex CLI and OpenAI's local auth flow |
claude | claude doctor | Claude Code and Anthropic's local auth flow |
copilot | copilot login | Copilot CLI and GitHub's local auth flow |
coven-code | /connect inside Coven Code | The engine's own local auth store; see Coven Code providers |
grok (adapter recipe) | grok login, or XAI_API_KEY for headless auth | Grok Build CLI and xAI's local auth flow |
hermes (adapter recipe) | Hermes' own local setup | Hermes Agent CLI |
The XAI_API_KEY environment variable is read by the Grok Build CLI itself, in its own process environment. It is not a Coven setting, and Coven never asks for it.
Credential path
The missing arrow is the important part: the daemon does not read the provider credential store.
What the daemon sees
The daemon sees PTY output and process exits. If the harness prints an auth error, Coven records that output like any other session output. If a user asks a harness to print a secret, that output can land in the event log. This is a user-side safety rule, not provider-token support in Coven.
What clients must not do
Clients should not add provider-token fields to Coven requests. The socket API does not need API keys, OAuth refresh tokens, bearer tokens, or account ids to launch a session.
Use Authentication and local access for the daemon access model and Daemon security posture for the local trust boundary.
Last updated on