The Asana MCP Data Leak: What Cross-Tenant Exposure Teaches Us About AI Agent Security

In June 2025, the AI agent security community got its first large-scale, real-world demonstration of what happens when multi-tenant isolation fails inside an MCP integration. A logic flaw in Asana's Model Context Protocol server allowed data from one customer's Asana instance to surface in other organizations' AI assistants. Roughly one thousand customers were potentially affected, and the feature stayed offline for about two weeks while Asana investigated. Nobody attacked anyone. No credentials were stolen. And that is precisely what makes this incident the most instructive MCP failure to date: everything worked as deployed, and confidential data still crossed organizational boundaries.

What Happened

Asana launched its MCP server on May 1, 2025, as part of its AI Studio push. The idea was compelling and entirely mainstream: let customers connect AI assistants — Claude, internal copilots, custom agents — directly to their Asana workspace, so the assistant could read tasks, summarize projects, and answer questions grounded in real work data.

The exposed data was whatever the MCP integration could legitimately read — project information, task-level details, team metadata, comments — except it could be served to the wrong tenant. The severity of exposure for any given organization depended on what their neighbors' AI assistants happened to ask about during the window.

The Root Cause: A Bug, Not a Breach

It is important to be precise about what this incident was and was not. There is no indication that an attacker exploited the flaw. It was a tenant-isolation defect in the MCP server implementation — the kind of bug that every multi-tenant engineering team has fought at some point: state that should have been scoped per-organization leaking across request boundaries.

That ordinariness is the point. In 2025, vendors were racing to ship MCP servers — the protocol went from announcement to industry standard in under a year, and every SaaS product needed an AI connectivity story yesterday. MCP servers were frequently built as thin, fast-moving adapters on top of existing APIs. But an MCP server is not a thin adapter. It is a new, highly privileged access path into your data, exercised by autonomous software that generates query patterns no human product team ever anticipated. Tenant scoping that held up under years of human-driven web traffic met a brand-new code path, written in weeks, exercised by machines.

Why MCP Makes a Cross-Tenant Bug Worse

A cross-tenant bug in a REST API is bad. The same bug behind an MCP server is significantly worse, for reasons that are structural to how AI agents consume data.

The Two-Week Question: "What Did Our Agents See?"

When Asana notified administrators, every affected security team faced the same pair of questions, in both directions:

• Inbound: Did our AI assistants ingest data belonging to another organization? If so, where did it end up — which conversations, which summaries, which downstream documents?
• Outbound: Could our data have been served to someone else's assistant? What was reachable through the integration during the window?

Teams that routed agent traffic through an audited control point could answer the inbound question in minutes: pull every MCP request and response that crossed the boundary between June 4 and June 17, scan the responses for identifiers that do not belong to the organization, and produce a definitive list of contaminated sessions. Teams that connected assistants directly to the vendor's endpoint had no record of what their agents received — the only copy of the evidence lived in vendor logs and in scattered chat histories.

This is the operational lesson of the incident, and it generalizes far beyond one vendor: in an AI agent architecture, the audit trail of what your agents consumed is as security-critical as the audit trail of what they did.

Lessons for Every Organization Consuming MCP

1. Vendor trust is not a control

Asana is a mature SaaS company with a serious security program — and it still shipped a tenant-isolation bug in its MCP layer. If your MCP security model is "we only connect to reputable vendors," you have a vendor list, not a security model. Reputation did not prevent this incident, and vetting a server once at onboarding says nothing about the code the vendor deploys next sprint.

2. Enforce your boundaries on your side of the wire

The organizations exposed in this incident had no defect in their own systems. The failure was upstream — which means the only place they could have limited the damage was the path between their agents and the vendor. A gateway that inspects MCP responses before they reach the model can catch cross-tenant contamination the moment it appears: entity names that belong to no known project, email domains outside your organization, customer identifiers that do not match your tenant. INS applies exactly this kind of response-side scanning — the same DLP and anomaly pipeline that checks outbound requests also checks what comes back, because the Asana incident proved that inbound data is an attack surface too.

3. Record everything that crosses the boundary

Every request your agents send and every response they receive should be logged, attributed to a user and a session, and retained on infrastructure you control. This is not about distrust of any particular vendor. It is about being able to answer the two-week question — "what did our agents see between date X and date Y" — without depending on a third party's incident-response timeline. When the next upstream incident happens (and the 2025–2026 record says it will), the difference between a shrug and a definitive answer is whether the traffic passed through an audit point you own.

4. Scope agent access as if the upstream will fail

The blast radius of the incident, per organization, was bounded by what each connected assistant was entitled to ask for. Agents connected with broad, always-on access to entire workspaces had the largest exposure in both directions. Least privilege applies to agents with special force: per-agent tool allowlists, scoped credentials, and time-bounded access do not prevent an upstream bug, but they cap what any single failure can touch.

5. If you build multi-tenant MCP servers, isolation is the feature

For teams shipping their own MCP servers, the incident is a design mandate: tenant isolation cannot be an application-level convention enforced by remembering to add a WHERE org_id = ? clause in every new code path. It has to be structural. This is why INS isolates every tenant in its own PostgreSQL schema — a query without tenant context does not return the wrong tenant's data; it fails. Whatever your mechanism, the test is the same: can a single forgotten filter in a new feature leak data across organizations? If yes, an MCP server will eventually find it, because agents explore code paths at machine speed.

A Checklist Before You Reconnect Any SaaS MCP Server

1. Route it through a control point. No agent should talk to an external MCP server directly. Put an inspection and audit layer between them.
2. Log full request/response traffic with user and session attribution, retained on your infrastructure.
3. Scan responses, not just requests — for foreign identifiers, other organizations' data markers, PII that should not be present, and injected instructions.
4. Apply least privilege per agent: tool-level allowlists and scoped, expiring credentials instead of workspace-wide tokens.
5. Know your kill switch. When the next vendor advisory lands, you should be able to cut one server off from all agents in one action — and know exactly which sessions touched it, for how long, and what they received.

The Bigger Picture

The Asana incident sits in a 2025 lineage that includes the GitHub MCP prompt-injection exploit, the Supabase MCP "lethal trifecta," and the postmark-mcp supply-chain backdoor. Each one attacked a different layer — but they share a conclusion. MCP turned every SaaS product into an API for autonomous agents, and it did so faster than either the vendors or their customers built the corresponding safety infrastructure. Vendors will keep shipping MCP servers under competitive pressure, and some of those servers will have bugs. The organizations that weather those bugs are not the ones with the best vendor questionnaires. They are the ones that assumed upstream failure was a matter of time, and placed their own controls — inspection, isolation, least privilege, and an audit trail they own — between their agents and everyone else's code.