AI API Key Security for Agents: Rotate, Scope, and Keep Secrets Out of MCP

On 17 October, OpenCode posted on X that it "had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users." The company said it had emailed everyone affected, that anyone without an email was not impacted, and that the affected users were "a subset of users who had external providers linked." It added that the incident was ongoing and that it was working with Anthropic, OpenAI and Google to remediate.

"External providers linked" is the part that matters. OpenCode's own Console providers documentation says teams connect provider accounts by entering that provider's API key, and that "Console stores the credential and serves each provider through its gateway." So the keys at stake are your own OpenAI, Anthropic or Google keys, held by a third-party tool.

This piece is the checklist I would run today if I had linked keys, followed by the habits that keep the next tool breach small. It is about protecting your own keys. Nothing here explains how stolen keys get used.

What is known, and what is not

Stick to what has been published. As of Cyera's developing write-up (last updated 17 October, 6:00 PM ET):

• Confirmed by OpenCode: a breach affecting 1.4% of all Console users (a subset of those who had linked external providers), affected users emailed, remediation with the three providers.
• Reported by Cyera: OpenCode's email to users attributed the intrusion to a legacy console system it was retiring, and some users report usage charges they did not make.
• Not yet known: how attackers got in, how the keys were stored, and whether any were misused. Cyera reports that OpenCode says it cannot yet confirm misuse.

"Distillation" here means collecting a model's outputs at scale to train another model on them. If someone sends those requests on your key, you pay for them. That is why an AI provider key deserves the same care as a payment card: it is a bearer secret, and whoever holds it spends on your account.

Do this first: the incident checklist

Even if you got no email, rotating a key you linked to any third-party tool is cheap insurance.

1. Ask your team directly. OpenCode emailed affected users individually, so a notice may sit in one developer's inbox and never reach security. Ask who linked keys in Console.
2. Revoke at the provider, not in the tool. Cyera's advice is specific: revoke in each provider's own dashboard, because deleting a key inside OpenCode does not stop someone who already copied it. Removing the key from the tool only stops the tool from using it.
3. Open dashboards from your bookmarks. Do not click through links in a breach email. Cyera notes that notices like these are common phishing bait.
4. Replace, then revoke, where you can. OpenAI's API key safety guidance describes the order: create a replacement, update your applications, and revoke the old key once the replacement works. For a key you know was exposed, revoke now and fix what breaks.
5. Check usage and billing. Cyera suggests reviewing provider usage from 16 October onward for spikes, unfamiliar models or activity at odd hours.
6. Turn on hard spend limits. OpenAI's page is blunt: "Spend alerts alone don't stop API traffic." It recommends monthly limits with hard enforcement, and notes that enforcement is not instantaneous, so spend can slightly exceed the cap. Cyera also points out that Console budgets only cover spend that runs through OpenCode, so they do not stop a stolen key used directly against the provider.
7. Clean up the tool side. Reset your OpenCode account password, regenerate any Console API keys, and remove providers you no longer need from each workspace.

Find every consumer of the key

Rotation breaks things you forgot about. Before or right after you revoke, answer three questions for each key:

• Who owns it? Keys often start on one developer's account and spread. A key nobody owns is the key nobody rotates.
• What else uses it? The same key may run a CI job, an internal script, another coding agent or an MCP server. List them, move them all to the new key, and confirm the old one is dead.
• What can it reach? Cyera notes that, depending on the provider, a key can read uploaded files, stored responses and fine-tuned models. If an exposed key had that access, treat the data as possibly exposed.

Why this keeps happening: CERT-In's view

Two days before the OpenCode post, CERT-In issued advisory CIAD-2026-0049, rated Critical, on AI agents as attack vectors (official advisory; summary in The Hacker News). In the incidents it describes, agents reached systems through credentials and connection settings exposed in application configuration and public code repositories, and through cloud roles with excessive permissions. In the voluntarily disclosed cases, agents found the same exposed credential again and reused it in separate operations.

CERT-In calls the root weaknesses conventional, and its fixes read like a key-hygiene list:

• Audit source code, commit history, CI/CD variables and configuration files for exposed credentials. Rotate what you find, purge it from history, and verify the fix externally.
• Scan every commit and build for secrets, and keep credentials out of code and configuration files.
• Give each agent run its own short-lived, least-privilege identity, enforce default-deny egress, and keep a tamper-resistant log of agent activity.

The two stories are different incidents. What they share is that a long-lived key sitting somewhere convenient is the weak point.

Steady state: key hygiene for agents and MCP

Once the fire is out, set things up so the next tool breach costs you one key, not all of them.

One key per tool, per agent, per server

Do not share one organisation-wide key across every MCP server, agent and script. OpenAI's guidance is a unique key for each team member, with permissions assigned per key, and it does not support sharing keys. Extend that to machines: one key per tool or server, named so you know what to revoke. Our MCP security cheat sheet puts it as "use fine-grained, scoped tokens" rather than reusing "a single broad token across servers." If you want the wider permission picture (tool allowlists, scopes, approval), I covered it in MCP tool permissions and least privilege.

Keep secrets out of MCP config files

MCP client configs are JSON files that get copied, shared in chat and committed by accident. Do not paste keys into them. Load secrets from environment variables or a secret manager. This lines up with the MCP spec too: the authorization specification says stdio servers should retrieve credentials from the environment rather than follow the HTTP OAuth flow. OpenAI recommends environment variables over hard-coded keys, and a key management service for production so keys are encrypted and managed somewhere else.

Prefer keys that expire

OpenAI project keys can be created with an expiration date, and administrators can enforce a maximum key lifetime at the organisation or project level. For supported workloads, OpenAI recommends workload identity federation, which exchanges an identity for a short-lived access token instead of storing a long-lived key at all. CERT-In's per-run, short-lived identity advice points the same way.

Restrict where a key works

OpenAI supports IP allowlisting, so requests from outside your configured ranges are rejected even with a valid key. A copied key that only works from your backend is worth much less to whoever copied it.

Grade before you grant

Do not hand a real key to an MCP server you have not looked at. Vet the server first, and check its grade in the MCP server directory or with the Andrax MCP scanner (mcpgrade-1.4.0, 39 checks).

Separate secret-bearing tools from untrusted content

An agent that holds a key, reads untrusted content and can send data out has all three parts of the problem described in the lethal trifecta. Keep key-holding tools away from agents that browse or read arbitrary input.

Watch usage like you watch a card statement

Review provider usage regularly, not only after a breach. Know your normal models, volumes and hours so a spike stands out.

Where Guard fits

Rotation and config hygiene are promises about where keys live. A grade finds risk; a gate enforces policy. SentinelAgent Guard sits in front of your MCP server and runs 22 controls on every call (mcpgrade-2.0.0). One layer scans what a tool sends back for secrets, and a finding names the check that fired, never the secret itself. Guard does not replace revoking and rotating keys at the provider. The 22 controls are Guard's runtime rubric and the scanner's 39 checks are a separate rubric; never compare them as scores. See Guard's Free and Pro plans.

Andrax grades use 39 checks (scanner mcpgrade-1.4.0); Guard enforces 22 runtime controls (mcpgrade-2.0.0). They measure different things.

FAQ

Does deleting a key inside my coding tool revoke it? No. It only stops that tool from using it. Revoke the key in the provider's own dashboard.

I did not get an email from OpenCode. Am I safe? OpenCode says users without an email were not impacted. If you linked provider keys and are unsure, rotating them is cheap.

Are spend alerts enough? No. OpenAI states that spend alerts alone don't stop API traffic. Use hard limits where the provider offers them, and keep alerts as an early warning.

Is a scanner grade enough after a breach? No. A grade tells you about a server's risk. After a key exposure, you still have to rotate at the provider, find every consumer of the key, and watch usage.