A leaked API key for a model provider or AI platform is billed, abused and sometimes resold within hours, and each provider handles scoping, revocation and leak detection slightly differently. This page groups ten providers whose keys share the same leak-response shape: Mistral AI, Cohere, Groq, OpenRouter, Perplexity, xAI, DeepSeek, Replicate, Pinecone and Weights & Biases. For each it sets out how keys are scoped, how to revoke and replace them, what GitHub secret scanning detects, and what the provider's documentation does not tell you. It is written for platform, security operations and AI engineering teams who hold these keys in applications, notebooks, CI pipelines and agent configurations. For the general response template use the LLMjacking Response Playbook; this page supplies the provider-specific detail.
Key takeaways
- Revoke first, investigate second: on every provider here, deleting or disabling the key is immediate and the documented rotation is "create new, deploy, delete old", so a leaked key should be killed as soon as a replacement path exists.
- Scope differs a lot: Pinecone keys are per project with roles, Mistral keys per Workspace with optional expiry, xAI keys can carry model and endpoint ACLs, while Weights & Biases personal keys work in every organisation the user belongs to.
- Provider notification is uneven: GitHub's secret scanning partner programme notifies Groq, OpenRouter, xAI and Replicate about public leaks, but not Mistral AI, Cohere, Perplexity, DeepSeek, Pinecone or Weights & Biases, so for those you rely on your own scanning.
- The bill is the first signal: usage and spend dashboards often show abuse before any security alert, so set spend or credit limits where the provider supports them.
- Data keys are worse than inference keys: a leaked Pinecone or Weights & Biases key can expose embeddings, experiments, artefacts and models, so treat these as data breach candidates, not just billing incidents.
How identity and access work in AI model provider platforms
All ten providers authenticate API calls with a static bearer secret tied to an account, organisation, project or workspace. None of them, in the documentation checked, binds a standard API key to a network location or a workload identity, so possession is enough. The differences are in how far a key reaches and how quickly you can contain it.
| Provider | Key scope (vendor docs) | Revoke or disable | Expiry option |
|---|---|---|---|
| Mistral AI | One Workspace; uses that Workspace's quota, limits and resources | Delete in Admin Panel (Organization Admins) or User Profile in Studio | Yes, set at creation; optional organisation and Workspace maximum policies (off by default) |
| Cohere | Trial or production key per account | Cohere dashboard (procedure not detailed in the docs checked) | Not documented in the pages checked |
| Groq | One project; projects isolate keys, rate limits, usage and logs | Project Owners manage keys (steps not described) | Not documented |
| OpenRouter | Account or organisation; management keys are account-level and unscoped | PATCH disabled: true or DELETE /api/v1/keys/{hash} | Recommended for management keys; per-key credit limits |
| Perplexity | Project | POST /revoke_auth_token; permanent | Not documented; docs suggest rotating, for example every 90 days |
| xAI | Team; ACLs per key for models and endpoints | Delete through console or management API | Not documented in the page checked |
| DeepSeek | Platform account (keys from platform.deepseek.com/api_keys) | Platform console (procedure not documented in the page checked) | Not documented |
| Replicate | Account; tokens start r8_ | Disable at replicate.com/account/api-tokens | Not documented |
| Pinecone | One project, with roles such as ProjectEditor | Project owners delete; irreversible and immediate | Not documented |
| Weights & Biases | Personal key: every organisation of the user; team or organisation service account keys | Delete singly or in bulk; immediate | No expiry described |
Where this table says "not documented", the provider may well offer the feature: it means the official page we read on 28 October 2026 did not describe it. Check the console before relying on a gap or a feature.
Admin roles and privileged access
- Mistral AI: Organization Admins can create, review, rotate and delete keys across Workspaces in the Admin Panel and set the maximum key lifetime; Workspace Admins can set a stricter maximum. Key Workspace, Connector access scope and expiry cannot be changed after creation.
- Groq: organisation roles are Owner, Developer (currently the same as Owner) and Reader. Because Developer equals Owner, anyone with Developer can manage keys: keep Owner and Developer lists short.
- OpenRouter: management keys can create, edit and delete every other key but cannot call completion endpoints. Only Organization Admins create them for organisations; give them an expiry, which cannot be changed later. See the Model Aggregator and LLM Router Key Security guide.
- xAI: management keys (Console, Settings, Management Keys) use a separate base URL,
https://management-api.x.ai, and can create, update and delete API keys and their ACLs. A leaked management key is an account takeover, not a billing problem. - Pinecone: project owners update permissions and delete keys; the Admin API and
pc api-key createcan create keys programmatically, so protect the Admin API credentials as privileged. - Weights & Biases: organisation admins see all organisation keys, team admins see service account keys for their teams. Enterprise organisations on multi-tenant cloud can enforce organisation-scoped API keys so personal keys lose access; Dedicated Cloud and Self-Managed (v0.84.0 and later) can disable key creation for users and team service accounts.
Integrations, API tokens and service accounts
These keys end up in the same places: .env files, notebooks, agent and IDE configuration, CI variables, container images and front-end code that should never hold them. OpenAI-compatible APIs make this worse: DeepSeek, for example, documents both OpenAI and Anthropic compatible endpoints (https://api.deepseek.com and https://api.deepseek.com/anthropic), so tools configured with a base URL and a key variable can silently carry several providers' keys.
- Use non-personal identities: Weights & Biases service account keys (team or organisation) instead of personal keys for pipelines; Mistral, Groq, Perplexity and Pinecone keys in dedicated projects or Workspaces per environment.
- Narrow the key: xAI ACLs such as
api-key:model:<model name>andapi-key:endpoint:chatinstead of the wildcardsapi-key:model:*andapi-key:endpoint:*; Pinecone custom permissions (Standard and Enterprise plans) targeted at specific index hosts; Mistral Connector access scope left at the default "Shared connectors only". - Cap the spend: OpenRouter per-key credit limits with optional daily, weekly or monthly reset; xAI per-key
qps,qpmandtpmrate limits; Groq project rate limits set at or below organisation limits. - Centralise where possible: an AI gateway can hold provider keys once and issue its own scoped credentials to applications, which shrinks the number of places a provider key can leak. See the AI Gateway and LLM Gateway Guide.
Logging and detection
GitHub secret scanning has patterns for all ten providers, with push protection on every one, but provider notification and validity checks vary. "Partner" means GitHub notifies the provider when the secret appears in a public repository; "validity check" means GitHub can tell you whether a detected key is still active.
| Provider | GitHub secret type | Partner alert | Push protection | Validity check |
|---|---|---|---|---|
| Mistral AI | mistral_ai_api_key | No | Yes | Yes |
| Cohere | cohere_api_key | No | Yes | Yes |
| Groq | groq_api_key | Yes | Yes | Yes |
| OpenRouter | openrouter_api_key | Yes | Yes | Yes |
| Perplexity | perplexity_api_key | No | Yes | No |
| xAI | xai_api_key | Yes | Yes | Yes |
| DeepSeek | deepseek_api_key | No | Yes | Yes |
| Replicate | replicate_api_token | Yes | Yes | Yes |
| Pinecone | pinecone_api_key | No | Yes | Yes |
| Weights & Biases | wandb_api_key | No | Yes | No |
Replicate goes further than most: it says it scans public GitHub repositories, immediately disables flagged tokens and emails the owner, so an application can stop working without warning after a leak. Plan for that outage. For Perplexity and Weights & Biases, which have no validity check, test a found key against the provider (with a harmless call from an isolated host) or simply revoke it.
- Usage signals: spend spikes, new models in use (for example a key that only ever called a small model suddenly calling the most expensive one), traffic outside working hours, requests from unexpected regions where the provider exposes them, and rate-limit errors your applications did not cause.
- Per-project telemetry: Groq usage and logs are per project; Mistral usage is per Workspace; OpenRouter reports
limit_remainingper key. Separate projects per application make these signals attributable. - Data platform signals: for Pinecone and Weights & Biases, look for unexpected reads or exports of indexes, runs and artefacts, and new keys or service accounts created during the exposure window.
| Metric | Target |
|---|---|
| Provider keys with a named owner, project and environment in the inventory | 100% |
| Keys without a spend cap, expiry or ACL where the provider supports one | Falling to 0 |
| Time from leak alert to revocation | Under 1 hour |
| Personal keys used by automation (for example Weights & Biases personal keys in CI) | 0 |
| Repositories with push protection enabled | 100% |
The scale of the problem is not hypothetical: in the Hugging Face API tokens exposure, researchers found 1,681 working tokens hard-coded in public repositories, reaching 723 organisations, and 655 had write permission over models and datasets. The same pattern applies to every provider on this page.
Leak response, step by step
- Confirm and classify: identify provider, key type (inference key, management key, data platform key), owning project or Workspace, and where it leaked (public repository, package, image, log, client-side code).
- Create the replacement: in the same project or Workspace, with narrower scope than before where the provider allows it. Perplexity documents generating the new key while the current one is active, deploying it, waiting for services to switch, then revoking the old key.
- Revoke the leaked key: delete or disable it. Deletion is immediate on Pinecone and Weights & Biases and permanent on Perplexity; OpenRouter supports disabling first. xAI documents that key changes may take a short time to propagate across clusters, so verify with a test call.
- If a management or admin key leaked: assume every key it could manage is compromised. List all keys, delete any you did not create, and rotate the rest.
- Review usage for the exposure window: spend, models used, request volume. For Pinecone and Weights & Biases, review data access and treat it as a possible data incident.
- Remove the secret from the source: history rewrite or package yank where needed, but only after revocation; a removed commit does not un-leak a key.
- Contact the provider for billing disputes or abuse reports, with the timeline.
- Close the cause: push protection on, secret moved to a secrets manager, and a per-environment key policy. See the Leaked Credential Response Playbook.
Small versus large teams: a small team using two or three providers can keep keys in one secrets manager, one project per environment, and revoke by hand from the console. A larger organisation with many teams experimenting across providers should route traffic through a gateway, issue provider keys only to the gateway, use the providers' management APIs (OpenRouter, xAI, Perplexity, Pinecone Admin API) to create and revoke keys from automation, and record which team owns each key so revocation does not wait for an investigation into who uses it.
Where identity fits: AI agents and coding assistants are now a common holder of these keys, often in local configuration files that sit outside normal secrets management. Treat an agent's provider key as a non-human identity with an owner, a scope and an expiry, and prefer a gateway-issued credential the agent can lose without exposing the provider account. See the Credential Vaulting for AI Agents Guide.
Hardening baseline
| Control | Where supported (vendor docs) | Framework anchor |
|---|---|---|
| One key per application and environment, in separate projects or Workspaces | Mistral, Groq, Perplexity, Pinecone, Weights & Biases service accounts | NIST SP 800-53 AC-6 Least Privilege |
| Key expiry or maximum lifetime | Mistral expiration policy; OpenRouter management key expiry | IA-5 Authenticator Management |
| Model and endpoint restrictions | xAI ACLs; Pinecone custom permissions | AC-6 |
| Spend and rate caps | OpenRouter credit limits; xAI rate limits; Groq project limits | OWASP LLM10:2025 Unbounded Consumption |
| Block personal keys for organisation data | Weights & Biases "Enforce organization-scoped API keys" | NIST CSF 2.0 PR.AA-01 |
| Push protection and repository scanning | GitHub secret scanning for all ten | CSF DE.CM-09; ATT&CK T1552.001 Credentials In Files |
| Usage monitoring and review | Provider usage dashboards and logs | AU-6; ATT&CK T1496.004 Cloud Service Hijacking |
Stolen keys used against a provider account map to ATT&CK T1078.004 Cloud Accounts, and containment to CSF RS.MI-01. See the LLMjacking Guide for the attacker economics, and the OWASP NHI Top 10 NHI2 Secret Leakage Guide for the wider pattern.
Common misconfigurations
- One key everywhere: the same key in development laptops, CI and production means a leak anywhere forces an outage everywhere.
- Personal keys in pipelines: a Weights & Biases personal key reaches every organisation the user belongs to and disappears with the user.
- Wildcard ACLs and "All" permissions: xAI wildcard ACLs and Pinecone "All" permissions (the only option on Starter and Builder plans) give a leaked key full reach.
- No spend cap: an unlimited key lets an attacker run up the bill until someone reads the invoice.
- Keys in client code: browser and mobile apps calling providers directly expose the key to every user. Proxy calls through your own backend or gateway.
- Treating the leak as fixed when the commit is deleted: forks, caches and scrapers keep the key; only revocation fixes it.
Practitioner checklist
- Inventory every key for these ten providers with owner, project or Workspace, environment and storage location.
- Enable GitHub push protection and scanning for these secret types across all repositories.
- Run your own scanning for providers without GitHub partner alerts: Mistral AI, Cohere, Perplexity, DeepSeek, Pinecone and Weights & Biases.
- Separate projects or Workspaces per application and environment.
- Apply expiry, ACLs, custom permissions and spend caps wherever the provider offers them.
- Protect OpenRouter and xAI management keys and the Pinecone Admin API as privileged credentials.
- Replace Weights & Biases personal keys in automation with service account keys and enforce organisation-scoped keys if available.
- Document a revoke-and-replace runbook per provider, including Replicate's automatic disable behaviour.
- Alert on spend spikes and unexpected model use per key.
Standards and references
- GitHub Docs: Supported secret scanning patterns
- Mistral AI: API keys
- OpenRouter: Management API keys
- xAI: Management API guide
- Perplexity: API key management
- Replicate: API tokens
- Pinecone: Manage API keys
- OWASP: Top 10 for LLM Applications 2025
Related NHI Mgmt Group resources: LLMjacking Response Playbook · Model Aggregator and LLM Router Key Security · OpenAI API Keys Security Guide · Vector Database Security Guide