Provider Auth Boundary
Security boundary for OpenAI, Anthropic, GitHub, xAI, and other provider credentials when running harnesses through Coven.
2 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 auth login | 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.
Consent-gated handoff
For Codex, Claude Code, and Copilot, coven setup <provider> is a launcher for the provider-owned command—not a replacement credential system. It shows the exact command, warns that the provider receives direct terminal access, and continues only after explicit consent.
An optional verification turn receives a separate consent prompt because it requires network access and may incur provider usage or cost. The bounded turn uses ephemeral Coven state. It does not copy provider credentials into Coven or persist the verification workspace.
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.
coven setup login uses direct terminal access rather than the session ledger. Its optional JSON verification report is deliberately redacted and excludes provider output, prompts, credentials, and ephemeral workspace contents.
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 Provider setup for consent and verification semantics, Authentication and local access for the daemon access model, and Daemon security posture for the local trust boundary.