The MCP trifecta: three conditions that turn AI agents into your riskiest API clients

In June 2025, a developer agent running inside Cursor connected to a Supabase database via MCP. The agent held a service_role key—one that bypasses all row-level security by design. It was also reading user-submitted support tickets as part of its workflow. An attacker embedded a SQL instruction inside a ticket. The agent treated it as a legitimate task, ran a query, and leaked integration tokens into a public thread.

Simon Willison's analysis of the incident named the root cause the "lethal trifecta": privileged access + untrusted input + external communication channel. All three were present. The breach was the inevitable result.

This pattern did not end with that incident. Researchers found similar conditions in Neon DB and Heroku's MCP servers. As MCP becomes the default integration layer for enterprise AI tooling, the trifecta is becoming reproducible at scale.

Why the trifecta is now a board-level API problem

The numbers bear this out. 48% of cybersecurity professionals identify agentic AI as their top attack vector heading into 2026, yet only 34% of enterprises have AI-specific security controls in place. Shadow AI breaches cost an average of $4.63 million per incident—$670,000 more than a standard breach.

The attack surface has also expanded in a specific direction. A 2026 supply chain attack on the OpenAI plugin ecosystem harvested agent credentials from 47 enterprise deployments, giving attackers lateral access to customer data and financial records across all connected systems. MCP servers are high-value targets precisely because they aggregate authentication tokens for multiple downstream services—compromising one yields access to everything the agent can reach.

Traditional API security models were designed for predictable, human-driven clients. An MCP-connected agent is neither: it makes decisions based on context windows that can contain attacker-supplied content, it operates with elevated credentials justified by "the agent needs to do its job," and it produces API calls that are indistinguishable from legitimate ones until the data is already gone.

Three conditions, one enforcement point

The trifecta is not a flaw in MCP itself. It is a configuration and architecture problem that repeats whenever AI clients are granted access outside the same governance framework applied to every other API consumer.

Privileged access exists because teams provision agent credentials the same way they provision developer service accounts: broadly scoped, long-lived, and rarely audited. The fix is not weaker credentials—it is credential issuance through the same IAM process that governs partner and application access, with scopes bounded to published API products rather than raw database roles.

Untrusted input becomes dangerous when the agent has no enforcement layer between the content it processes and the APIs it can call. Rate limits and scope enforcement at the gateway do not stop prompt injection at the model layer, but they bound the blast radius: an agent tricked into calling an out-of-scope endpoint is blocked; an agent running a runaway loop hits a per-client limit before it saturates upstream resources.

External channel risk—data exfiltrated via tool call responses, API parameters, or callback URLs—is most tractable when every outbound API call is logged with a stable identity, product, and outcome before it leaves the edge. An audit trail that records what the agent called, what response it received, and what it did next is the difference between a containable incident and a breach you discover from a customer complaint.

All three conditions share the same fix: enforce at the gateway, for AI clients and apps alike.

What "govern it at the edge" means in practice

For AI clients, a governed gateway must do five things that matter specifically to the trifecta:

Issue scoped credentials, not service-wide keys. An agent that only needs to call /payments should not hold credentials that work on /admin. Per-product API bundles, enforced at the proxy, limit what a compromised or injected agent can reach. See zerq.dev/security.
Enforce rate limits per client, not per route. Agents amplify QPS without malice—tool loops and retry logic produce bursts that saturate upstreams before any human notices. Redis-backed per-partner limits at the edge shape this traffic before expensive backend work runs.
Write structured audit records for every request, including AI-originated ones. SOC teams cannot answer "what did that agent call at 03:00 on Tuesday" if AI traffic lands in a separate log stream with different schema. Zerq's observability writes structured JSON with stable fields—identity, product, partner, outcome—that drops straight into your SIEM pipeline.
Rotate and revoke credentials through a single lifecycle process. Long-lived agent keys are the gift that keeps giving attackers access. Encrypted storage with scheduled rotation and emergency revocation—integrated with HashiCorp Vault or environment-based secrets—closes the window between compromise and containment. See zerq.dev/security.
Scope discovery to authorization. MCP enables clients to discover available tools and endpoints, which is genuinely useful—but discovery must not become a bypass. What the agent can see in a portal should match exactly what it can call at the gateway. Authorization is authoritative at the edge, not advisory.

How Zerq enforces this for MCP clients

Zerq's Gateway MCP gives AI consumers a natural-language interface to the developer portal—API discovery, endpoint inspection, safe test calls—while keeping every tool call subject to the same RBAC, rate limits, and audit enforcement that apply to every other client. The agent uses the active access profile's gateway identity, meaning the credentials it carries in discovery are the same ones validated in production. There is no privileged "discovery mode" that bypasses enforcement.

On the operations side, Management MCP lets platform teams configure and query the gateway in natural language, with every action running under the signed-in OIDC session. An operator asking Zerq Copilot to "raise the rate limit on Payments to 750 RPM" produces the same audit record as clicking Save in the console—same actor, same change, same trail. The Copilot brings its own LLM credential; you choose the provider (OpenAI, Anthropic, Bedrock, Ollama, or any custom endpoint), and the key never touches the browser.

The trifecta—privileged access, untrusted input, external channel—is a configuration problem, not a fundamental incompatibility between AI and production APIs. Enforce at the gateway with the same controls you already run for apps and partners, and the attack surface shrinks to the same manageable shape you have for every other class of client.

The Supabase breach was reproducible anywhere the trifecta appeared—and it still is. If your AI clients hold broader credentials than your tightest human partner, produce traffic that lands in a different audit stream, and operate outside the rate limits you set for production apps, you have the same three conditions in your environment today.

Request an enterprise demo at zerq.dev to map your AI client access against the same governance framework you apply to apps and partners.