Repository navigation
Modal and Paperclip credentials bypass the vault-first provider-key resolver #18383
Description
Problem
The owner ruling of 2026-10-12, delivered on #18371, says provider credentials resolve with the vault first. A key the vault holds but cannot read is refused, and the environment is used only for keys the vault does not hold. All of this goes through services.provider_key_vault.resolve_provider_key.
Two credential readers still bypass that resolver. They are allowlisted, with this issue as the reason, in the guard #18371 adds (repo_tests/provider_key_env_reads_route_through_vault_18094_test.py):
| Reader | Why it was not routed in #18371 |
|---|---|
autobot-backend/services/execution/modal_backend.py:133 (MODAL_TOKEN_ID / MODAL_TOKEN_SECRET) |
The third-party Modal SDK reads these names from the process environment itself. The backend only checks that they are present. Routing only the presence check through the vault would report a vault-only token as healthy while the SDK still cannot see it. The fix needs a way to hand the resolved token to the SDK, and I have not verified which SDK API supports that. |
autobot_shared/paperclip_client.py:123 (PAPERCLIP_API_KEY) |
autobot_shared cannot import the backend's provider_key_vault (wrong layering direction). There is no in-repo production constructor of PaperclipClient. A consumer would have to inject a resolved key, or the client would take a resolver argument. |
Acceptance criteria
- The Modal token resolves through the vault and is passed to the SDK explicitly. A refused token makes
health_checkreturn False with the reason. The guard entry is removed. -
PaperclipClienttakes its key from a resolver injected by the backend, with the environment kept only for standalone use. The guard entry is removed.
Activity
security(credentials): a vault outage refuses every key; video and Ti…