What works, what doesn't, and what's coming next
| Service / Credential | Auth Type | Support | Vault Method | Notes & Limitations |
|---|---|---|---|---|
| API Keys (Static Tokens) | ||||
| OpenAI API | Bearer token | Works great | vault_api_request | Header: Authorization: Bearer sk-... — the ideal use case. Key injected, response sanitized. |
| Anthropic API | Custom header | Works great | vault_api_request | Header: x-api-key: sk-ant-... — custom header name, fully supported via headerName config. |
| Stripe API | Bearer token | Works great | vault_api_request | Standard Bearer auth. Works perfectly. Template included. |
| Twilio | Basic auth | Works great | vault_api_request auth_type: basic |
Account SID + Auth Token as HTTP Basic. Use auth_type: "basic". |
| SendGrid | Bearer token | Works great | vault_api_request | Standard Bearer auth. |
| Google Maps API | Query param | Works great | vault_api_request auth_type: query |
Key appended as ?key=... — use auth_type: "query", authConfig: { queryParam: "key" }. |
| Deepgram | Bearer token | Works great | vault_api_request | Token: xxx — standard header injection. |
| Cloud Service Accounts & IAM | ||||
| GCP Service Account (JSON key) | JSON key file | PartialRoadmap | vault_import | Can store the private key, but GCP SDKs expect a file path (GOOGLE_APPLICATION_CREDENTIALS). Vault can't inject env vars into child processes yet. Workaround: store as api_key, use vault_api_request to call GCP REST APIs directly with Bearer token from the key. |
| GCP ADC (Application Default Credentials) | OAuth refresh token | Not applicable | — | ADC lives in ~/.config/gcloud/application_default_credentials.json and is managed by gcloud CLI. This is a file-based credential, not a token Vault can inject into HTTP headers. Not our use case — ADC is already local and not exposed to LLM. |
| BigQuery (Service Account) | Bearer token from SA key | PartialRoadmap | vault_api_request | If you have a short-lived access token (from gcloud auth print-access-token), it works as Bearer. But Vault can't do the OAuth2 JWT exchange to get the token from a service account key. Roadmap: OAuth2 flow support. |
| AWS IAM (Access Key + Secret) | HMAC Signature (Sig v4) | Not supported | — | AWS uses Signature Version 4 — every request requires HMAC signing with the secret key, region, service, and timestamp. This is NOT a static header. Vault would need a built-in AWS signer. Roadmap: plugin system for auth patterns. |
| AWS Console (Web Login) | Email + Password + MFA | Works great | vault_login + TOTP |
Web login via CDP. Template included. TOTP supported for MFA. Works like any web login. |
| OAuth2 / Token-Based Auth | ||||
| Google Sheets API (OAuth) | OAuth2 access token | PartialRoadmap | vault_api_request | If you already have an access token (e.g. from gcloud auth), store it and use as Bearer. Problem: tokens expire in 1 hour. Vault can't refresh them yet. Roadmap: OAuth2 token refresh. |
| Google Sheets API (API Key) | Query param | Works great | vault_api_request auth_type: query |
For read-only public sheets, API key as ?key=... works perfectly. |
| Meta Ads API | Long-lived access token | PartialRoadmap | vault_api_request | Meta issues long-lived tokens (60 days). Store as api_key, use as Bearer or ?access_token= query param. Caveat: when token expires, need to re-authenticate manually via Meta's OAuth flow. Vault can't do the OAuth dance yet. |
| Meta Business Suite (Web) | Email + Password + 2FA | PartialLimited | vault_login | CDP login works. But Meta's login flow has bot detection (Checkpoint), CAPTCHA, and device verification. May require manual intervention. Works ~60% of the time. |
| Shopify API | Access token (header) | Works great | vault_api_request | Header: X-Shopify-Access-Token: xxx. Custom header name — use headerName config. |
| Slack API | Bearer token | Works great | vault_api_request | Bot token or user token as Bearer. Works perfectly. |
| Web Logins (Chrome CDP) | ||||
| GitHub | Email + Password | Works great | vault_login | Template included. Selectors: #login_field, #password, [name="commit"]. TOTP supported. |
| Jira / Atlassian | Email + Password | Works great | vault_login | Template included. Two-step login (email first, then password) — both handled. |
| GitLab | Email + Password | Works great | vault_login | Template included. TOTP supported. |
| Email + Password | PartialLimited | vault_login | Login form works. But LinkedIn has aggressive bot detection — may trigger CAPTCHA or security verification after automated login. | |
| Google (Gmail, etc.) | Email + Password + 2FA | PartialLimited | vault_login | Google's login is multi-step and has bot detection. Email page → password page → 2FA. Custom selectors needed. May hit CAPTCHA. Works on warm Chrome profiles that Google already trusts. |
| E-Commerce & Complex Auth | ||||
| Amazon Seller Central | SP-API (OAuth2 + LWA) | Not supported | — | SP-API requires Login With Amazon (LWA) OAuth2 flow with client_id + client_secret + refresh_token, plus an AWS Sig v4 signed request. This is a multi-layer auth that Vault can't handle: both OAuth2 token refresh AND AWS signature needed for each call. |
| Amazon Seller Central (Web) | Email + Password + OTP | PartialLimited | vault_login | Web login works but Amazon has CAPTCHA, device verification, and OTP via SMS/email (not TOTP). If it sends SMS OTP, Vault can't intercept it. Works only if the Chrome profile is already trusted by Amazon. |
| Shopify Admin (Web) | Email + Password | Works great | vault_login | Standard login form. Custom selectors needed but straightforward. |
| Databases & Infrastructure | ||||
| PostgreSQL / MySQL | Connection string | Not supported | — | Database credentials are used by client libraries (pg, mysql2), not HTTP requests. Vault only handles HTTP headers/params and CDP browser automation. Roadmap: env var injection for child processes. |
| Redis | Password | Not supported | — | Same as databases — not HTTP-based. Needs env var injection or process-level credential passing. |
| MongoDB Atlas API | Digest auth / API key | PartialRoadmap | vault_api_request | Atlas Admin API uses Digest auth (not Basic). Vault supports Basic but not Digest. Workaround: use Atlas API keys with Bearer auth for some endpoints. |
| SSH, Certificates & Non-HTTP | ||||
| SSH Keys | Private key file | Not supported | — | SSH uses file-based keys or ssh-agent. Not HTTP, not browser-based. Outside Vault's scope. |
| TLS Client Certificates | Certificate + private key | Not supported | — | mTLS requires passing cert files to HTTP client. Vault's fetch() doesn't support custom certs. |
Vault MCP stores credentials securely. Behalf Chrome Extension acts as the browser-side runtime — handling flows that pure CDP or HTTP can't.
| Scenario | Vault MCP alone | + Behalf Extension | How the extension helps |
|---|---|---|---|
| OAuth2 redirect flows | Can't | Solved | Extension intercepts OAuth redirects via chrome.webNavigation, captures the authorization_code, sends to Vault via Native Messaging for token exchange. Credentials never leave the machine. |
| AWS Signature v4 | Can't | Solved | Extension receives access key from Vault via Native Messaging, signs each request in webRequest.onBeforeSendHeaders. The secret key never appears in HTTP traffic or agent context. |
| Token refresh (OAuth2, Meta, Google) | Can't | Solved | Extension runs a background refresh loop — when token nears expiry, it uses the refresh_token (from Vault) to get a new access_token and sends it back to Vault for encrypted storage. |
| Amazon SP-API (OAuth2 + Sig v4) | Can't | Solved | Extension handles both layers: OAuth2 token refresh (LWA) + AWS Sig v4 signing per request. Vault stores client_id, client_secret, refresh_token — extension does the runtime work. |
| Bot detection bypass (LinkedIn, Meta, Google) | ~60% | ~85% | Extension runs inside a real Chrome profile with full cookies/history/fingerprint. Less detectable than CDP automation. Can handle intermediate verification steps via content scripts. Still can't solve CAPTCHAs. |
| Session cookie management | CDP only | Solved | chrome.cookies API gives full access including httpOnly cookies. Extension can check session validity, persist sessions across restarts, and share sessions with Vault without network exposure. |
| SMS/Email OTP interception | Can't | Partial | If the OTP arrives in a browser-visible context (e.g. Gmail tab), extension content scripts can extract it. Can't intercept actual SMS — but covers email-based OTP for sites like Amazon. |
| Digest auth (MongoDB Atlas) | Can't | Solved | Extension handles HTTP Digest challenge-response in webRequest handlers. Vault stores username + password, extension computes the nonce-based hash per request. |
Communication: Vault MCP ↔ Behalf Extension via Chrome Native Messaging (stdin/stdout, no network). Credentials never leave the machine. Extension is the runtime, Vault is the storage.