Deleted Google API Keys Remain Active for 23 Minutes. AI Agents and MCP Servers Turn Every Credential Gap Into a Full Breach Window.

A Google API key that has been deleted continues to authenticate successfully for up to 23 minutes. Google has closed the finding as "won't fix." This behavior is one data point in a systemic API security failure that has grown more dangerous as AI agents and Model Context Protocol servers automate the exploitation of every gap at machine speed.

Key Takeaways

Aikido Security found deleted Google API keys remain active for a median of 16 minutes and up to 23 minutes; Google classified the propagation delay as expected system behavior rather than a security vulnerability, leaving incident responders with no effective revocation guarantee.
43% of all exploited vulnerabilities in the CISA KEV Catalog are API-related; 59% require no authentication, 97% are exploitable with a single request, and 99% are remotely exploitable, according to Wallarm's 2025 API ThreatStats report.
AI agents sit behind every API call and automate exploitation across chained tool sequences, converting a 23-minute window from a narrow credential leak into a structured data exfiltration pipeline.
Model Context Protocol servers generated 315 vulnerabilities in 2025 with a 270% increase from Q2 to Q3; CVE-2025-6514 carries a CVSS score of 9.6 and enables arbitrary OS command execution on every major operating system via a design flaw Anthropic declined to fix.
Three MCP-specific attack classes have no parallel in traditional API security: tool poisoning (malicious instructions embedded in tool metadata), rug-pull server substitution (tool definitions rewritten post-approval), and AARF chained injection (tool calls sequenced across shared memory without validation).

Deleted API keys are not revoked. They enter a propagation delay window during which any attacker who captured the key before deletion can continue to authenticate against live Google Cloud services. Aikido Security researcher Joe Leon, who published the findings on Aikido's blog, ran 10 tests over two days, creating and deleting API keys across GCP regions and sending up to five authenticated requests per second until they ceased. The median revocation window was 16 minutes; the maximum was 23 minutes; the minimum was 8 minutes. Google reviewed the report and closed it as "won't fix," characterizing the behavior as a documented propagation property of the distributed infrastructure.

A Deleted Google API Key Continues to Authenticate Against Gemini, BigQuery, and Maps for Up to 23 Minutes

Joe Leon's testing revealed regional inconsistencies that compound the revocation problem. In one trial, according to Aikido's research, us-east1 showed an 82% success rate for post-deletion requests, europe-west1 showed 60%, and asia-southeast1 showed 32%, all measured immediately after deletion. Across the full revocation window, asia-southeast1 maintained a median success rate of approximately 22% while other regions averaged 49%. The same deleted key authenticated at significantly different rates depending on which data center the request landed in.

The affected services span Google's most sensitive developer APIs. Standard Google API keys with Gemini access, BigQuery access, and Maps access all exhibited the 23-minute window. Gemini API keys with the "AQ" prefix showed a much shorter window of approximately one minute. Google Service Account keys revoked in approximately five seconds. The asymmetry means the slowest-revoking credential class is also the most commonly issued: standard developer API keys used to authenticate against production AI and data services.

Aikido's recommended response is to assume a 30-minute revocation window whenever responding to a leaked Google API key incident, per SC Media's reporting on the findings. Incident responders should monitor API usage via GCP's credential-tracking console during that window and treat any continued authenticated requests as confirmed active exploitation, not residual noise.

Google's position frames the behavior as an inherent property of globally distributed cache invalidation. Cache invalidation at global scale requires propagation time, and Google's documentation states that deleted keys "can no longer be used to make API requests" without specifying a propagation window. The Register's coverage notes that no CVE was assigned, and the behavior remains present across all standard API key types.

API Vulnerabilities Are Not Niche: 43% of All Exploited CVEs in CISA's Catalog Are API-Related

The scale of the API security problem extends far beyond any single provider's credential lifecycle management. According to Wallarm's 2025 API ThreatStats Report, of 60,000-plus vulnerabilities published in 2025, more than 11,000 (17%) were API-related. Of those, 43% appeared in the CISA KEV Catalog, meaning nearly half of all known exploited API vulnerabilities had confirmed active exploitation in the wild.

The exploitability characteristics of API vulnerabilities are structurally worse than most other vulnerability classes:

97% are exploitable with a single request
98% are easy or trivial to exploit
99% are remotely exploitable
59% require no authentication

Ivan Novikov, CEO of Wallarm, stated in the report: "API security is at the heart of any AI transformation. Every AI application or agent interaction is mediated through an API." The implication is direct: every AI feature shipped without a corresponding API security review is a vulnerability being introduced into production alongside a feature.

The top four API weakness categories in Wallarm's 2025 rankings shifted from prior years in ways that reflect AI's growing footprint. Cross-site issues rose from fifth place in 2024 to first. Injections dropped from first to second. Broken access control dropped from second to third. Insecure resource consumption rose from seventh to fourth, reflecting the new demand patterns created by AI workloads that call APIs at rates human-driven applications never approached.

AI Agents Convert a 23-Minute Credential Window Into a Structured Exfiltration Pipeline

The combination of a 23-minute revocation window and an AI agent is not additive: it is multiplicative. A human attacker with a leaked Google API key and a 23-minute window must manually identify available services, craft requests, and process responses. An AI agent with the same key can, within seconds, enumerate all enabled APIs via the GCP credentials tracking surface, issue sequential requests to Gemini to dump cached conversations, query BigQuery for stored datasets, and structure the exfiltration results into a deliverable format, all before the deletion propagates.

Tim Erlin, Wallarm Security Strategist, identified the core mechanism in SecurityWeek's coverage: MCP vulnerabilities combine three failure modes that compound each other. Over-permissioned tools grant agents broad API access by default. Direct API exposure means the tools themselves contain common API vulnerabilities. Absent runtime enforcement means policy violations only become visible after damage has occurred.

The blast radius concept is central to understanding why AI changes API risk. Traditional API breaches operate linearly: one exploited endpoint produces one category of data exposure. An AI agent with access to multiple APIs via an MCP server or a similar orchestration layer operates as a force multiplier: a single credential compromise, or a single prompt injection, propagates across every connected tool in the agent's permission set simultaneously.

MCP Generated 315 Vulnerabilities in 2025. Three Attack Classes Have No Precedent in Traditional API Security

Model Context Protocol is an open specification, originally developed by Anthropic, that standardizes how AI agents connect to external tools and data sources via JSON-RPC 2.0. Over 13,000 MCP servers launched on GitHub in 2025, according to Wallarm's report. The protocol generated 315 documented vulnerabilities in 2025, with a 270% increase between Q2 and Q3, per the same source.

CVE-2025-6514 is the most severe MCP vulnerability to date, carrying a CVSS score of 9.6. According to eSentire's CISO briefing, it affects mcp-remote versions 0.0.5 through 0.1.15 and enables arbitrary OS command execution via man-in-the-middle attacks against insecure HTTP connections. On Windows, exploitation produces arbitrary OS command execution. On macOS and Linux, it produces arbitrary executable launch.

A separate architectural flaw in MCP's STDIO transport layer was documented by OX Security researchers Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok, and Roni Bar, and reported by The Hacker News. The implementation executes any command that successfully creates a STDIO server, regardless of whether that command has any legitimate server purpose, returning a handle to the calling process. The flaw affects implementations in Python, TypeScript, Java, and Rust across over 7,000 publicly accessible servers with more than 150 million combined downloads. Anthropic declined to make architectural changes, characterizing the behavior as expected. Affected CVEs include:

CVE-2025-65720 (GPT Researcher)
CVE-2026-30623 (LiteLLM, patched)
CVE-2026-30624 (Agent Zero)
CVE-2026-30618 (Fay Framework)
CVE-2026-33224 (Bisheng, patched)
CVE-2026-30617 (Langchain-Chatchat)
CVE-2026-30625 (Upsonic)
CVE-2026-30615 (Windsurf)
CVE-2026-26015 (DocsGPT, patched)
CVE-2026-40933 (Flowise)

Tool Poisoning, Rug Pulls, and AARF Injection: The Three MCP Attack Classes With No Traditional Equivalent

Tool poisoning is the most prevalent MCP-specific attack vector, according to Zenity's MCP security analysis. A malicious MCP server presents tools with legitimate-sounding names and descriptions while embedding adversarial instructions in the tool's metadata. The AI agent reads the metadata as part of its context, interprets it as instructions, and executes the embedded attack without presenting any visible indication to the user. A published proof-of-concept demonstrated a "random fact of the day" tool that functioned normally on first use while silently combining its access with a legitimate WhatsApp MCP server to exfiltrate the user's complete message history on subsequent invocations.

Rug-pull server substitution exploits a fundamental gap in MCP's approval model. When a user approves a server, they approve its tool definitions at that point in time. MCP servers can modify their tool definitions between sessions without requiring explicit re-approval. An attacker who gains write access to an approved MCP server's configuration can redefine what approved tools do, redirecting them to leak data, execute commands, or intercept traffic flows, all under the cover of a previously trusted identity.

AARF (Agent-Accessible Resource Flooding) chained injection sequences tool calls through shared memory contexts without individual call validation. Per Zenity's framework, an attacker who can inject instructions into one point of a multi-agent workflow can cause downstream agents to execute unauthorized actions against APIs they have legitimate access to, by embedding instructions that appear to originate from a prior authorized step. Each individual tool call appears valid in isolation; the attack is only visible by analyzing the full execution chain.

CVE-2025-49596 and the EchoLeak vulnerability against Microsoft 365 Copilot demonstrate the real-world consequence of prompt injection in AI API workflows. According to eSentire's analysis, threat actors embedded hidden prompts within ordinary Office documents. When Copilot processed those documents, it read the hidden instructions as part of its context and executed them: exfiltrating sensitive data from the user's Microsoft 365 environment, querying connected services, and forwarding results to attacker-controlled infrastructure. The document was the delivery mechanism; the API integration was the payload.

What Defenders Must Do: A Prioritized Response to API and MCP Credential Risk

For the Google revocation gap specifically, Aikido recommends three immediate controls. First, assume a 30-minute window from the moment a key deletion is confirmed before treating the credential as inactive. Second, monitor all API usage via GCP's "Enabled APIs and services" credential-tracking dashboard during that window. Third, treat any authenticated request received after deletion as confirmed active exploitation requiring immediate IR escalation, not a cache artifact.

For AI API security broadly, Wallarm's analysis identifies three failure modes that organizations must close independently:

Over-permission: AI agents should receive API credentials scoped to the minimum required for each specific task, not broad service-level access
Direct exposure: every API surface accessible to an AI agent must pass the same security review as a public-facing endpoint, not a more permissive internal review
Runtime enforcement: policy violations must be blocked at the time of the API call, not logged after the fact

For MCP deployments, the 90-day CISO roadmap from eSentire describes three phases. Phase 1 (30 days): complete MCP server discovery across cloud and endpoint surfaces, establish an allowlist of verified servers, and conduct threat modeling for each deployed agent workflow. Phase 2 (60 days): implement cryptographic verification for allowlisted servers, integrate authentication for all tool invocations, and deploy behavioral monitoring for anomalous usage patterns. Phase 3 (90 days): deploy automated kill-switch capability for immediate suspension of a compromised agent or server, implement Unicode-based prompt injection detection, and establish a full audit chain from initial user query through every tool invocation and API response.

The authentication anti-pattern identified by eSentire as "token passthrough" requires specific attention. MCP servers that accept OAuth tokens without validating they were properly issued to that server create a confused deputy attack surface: any agent or process that obtains a valid token for any service can use a passthrough server as an unwitting proxy. Every MCP server that handles OAuth tokens should validate issuer, audience, and scope before accepting any token for downstream API calls.

Background: Why the API Credential Lifecycle Has Always Been Underdeveloped

API keys were designed for developer convenience, not operational security. The original model assumed a human developer creating a key, using it for a session or a project, and deleting it when done. Revocation was treated as a near-instantaneous operation because the original use case did not contemplate distributed cache architectures serving billions of requests per second across dozens of geographic regions.

The MCP protocol launched in November 2024 as Anthropic's attempt to standardize how AI agents connect to external tools. Its rapid adoption, more than 13,000 public servers within a year, outpaced the security review process by a wide margin. The OWASP Top 10 for LLM Applications (2025) lists prompt injection as the number-one risk specifically because tool-calling architectures like MCP provide a new class of injection target: not a database query or a shell command, but an AI agent's decision-making context.

The convergence of three independent trends has produced the current threat environment. API vulnerabilities have always been high in volume and ease of exploitation. AI agents have introduced a demand pattern where credentials are used at rates and across combinations that human developers never intended. MCP and similar protocols have created a new integration layer that is not yet covered by existing API security standards, SAST tooling, or WAF rule sets. Each trend was a manageable risk in isolation; their convergence has produced an attack surface with no established defense playbook.