Asana’s MCP AI connector could have exposed corporate data, CSOs warned

Bug allowing access to other MCP users’ data was found a month after server released.

CSOs with Asana’s Model Context Protocol (MCP) server in their environment should scour their logs and metadata for data leaks after the discovery of a serious vulnerability.

Asana, a software-as-a-service workplace management platform, said this week that its MCP server had been temporarily taken offline after it found what it called a bug. The server was back online Tuesday.

But according to researchers at security provider Upguard, the hole, discovered June 4, could also have exposed data belonging to other users of Asana’s work management platform. 

Upguard quotes Asana saying the bug “could have potentially exposed certain information from your Asana domain to other Asana MCP users within the projects, teams, tasks, and other Asana objects of the MCP user’s permissions.”

There is no indication that attackers have exploited the bug or that other users actually viewed the information accessible through the MCP bug, says Upguard.

For its part, Asana says the vulnerability was not a result of a hack or malicious activity on its systems. CSO asked the company for comment, but no reply had been received by press time.

The incident is more evidence that MCP is a protocol that’s still in early development, says Kellman Meghu, principal security architect at Canadian consultancy DeepCove Cybersecurity. “This is a common problem with MCP servers, which is why we stay away from them. MCPs all have this issue.”

CSOs using MCP should limit the data it can access until cybersecurity controls are tightened, he said in an interview.

What is MCP?

MPC is a protocol created by AI provider Anthropic and open sourced last November. The company described it as  “a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments. Its aim is to help frontier models produce better, more relevant responses.”

Developers can either expose their data through MCP servers, Anthropic said, or build AI applications (MCP clients) that connect to these servers. The idea is that, instead of maintaining separate connectors for each data source, developers can now build against a standard protocol. Anthropic’s Claude AI platform supports connecting MCP servers to the Claude Desktop app.

According to Upguard, Asana released its MCP server May 1. The company’s web page still refers to it as an “experimental beta tool.”

“You may encounter bugs, errors, or unexpected results,” it adds.

Asana says its MPC server allows AI assistants and other applications to access the Asana Work Graph so customers can access Asana data from compatible AI applications, generate reports and summaries based on Asana data, and analyze project data and get AI-powered suggestions. Through it, an employee can ask an AI assistant, for example, “Find all my incomplete tasks due this week”, “Create a new task in the Marketing project assigned to me” or “Show me the status of the Q2 Planning project.”

As AI platforms like Claude, ChatGPT, Microsoft Copilot, and others multiply, developers are eager for ways, such as MCP, to connect them to existing enterprise productivity applications. However, there have been warnings that these AI agents, some of which come from AI platform providers themselves, have security risks.

DeepCove Cybersecurity’s Meghu notes that some AI broker agents, like MCP, are actually long-lived server-TCP connections. He prefers a connection solution using the RAG model (retrieval augmented generation) with an API call that can be authenticated for security. Among other benefits, RAG can be configured to search only approved data and not information used in training that may include sensitive information.

“This is where the lessons we’ve learned in terms of [data] segmentation and how we handle direct APIs are applicable [to AI systems],” he said, “but they threw that out and went with these long-lived TCP connections that can’t really be monitored. By the time it [a data leak] happens, it’s too late.”

Depending on what it connects to, an MCP server can be “a huge, massive attack vector,” Meghu said. For example, he said, if the MCP server is connected to a SIEM (security information and event monitoring) platform for analysis of log data, a threat actor might try to access that server to gather data.

“Where do you situate this thing [an MCP server] is a great question” — one that CSOs need to answer, he said.

“I think, like all [new] protocols, it’s too early to put it into production,” he added. “They rushed this out. I think there are better ways to do this that we haven’t figured out yet … Why couldn’t we build on known protocols like JSON, RestAPI? Why did this have to be a special service? They didn’t think about access control as part of the protocol?”

“I expect lots of protocols like this to appear, and hopefully some of them will be built from the ground up with security in mind – audit control, authentication of each call-in,” he said.

Advice for CSOs

He advised CSOs to limit the data MCP projects can access, and audit who has been accessing that data. “I think we have a lot to learn,” he said.

Upguard says CSOs integrating any large language model (LLM) into their IT systems should:

• limit scope aggressively: Ensure that context servers like MCP enforce strict tenant isolation and least-privilege access;
• log everything: Maintain granular logs of all requests, especially LLM-generated queries, to support forensic investigations;
• ensure manual oversight during reintroduction: Automated re-connections or retraining pipelines should be paused when incidents arise;
• treat internal bugs seriously: Even internal software flaws can have real-world exposure consequences.