Asana’s MCP leak shows why agentic access needs guardrails

At a glance

What this is: Asana’s MCP server bug showed how agentic access can leak cross-tenant data when tool permissions and enforcement are too loose.

Why it matters: IAM and NHI teams need to treat MCP as an access boundary problem because AI connectors can expand blast radius across tenants, tools, and identities.

By the numbers:

• Over 1,000 customers were potentially affected by the Asana MCP bug.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Pomerium's analysis of the Asana MCP connector leak and guardrails

Context

MCP server security is the control problem hidden inside agentic AI integrations: tools need access, but the access must stay within the tenant, workflow, and identity boundary that created it. The Asana bug matters because it showed that when those boundaries are not enforced continuously, a connector can surface data from outside the intended organisation.

For IAM, NHI, and platform security teams, this is not just a protocol issue. It is an enforcement design issue that sits between identity, authorization, and application-layer context, which means existing role-based models alone are not enough when agents can chain requests and invoke tools asynchronously.

Key questions

Q: How should security teams control MCP tool access in multi-tenant environments?

A: Security teams should enforce request-level policy at the application edge, not rely on a single login event or broad connector grant. Each tool call should be evaluated for tenant, workflow, and action context, with default-deny rules for anything outside the approved path. That is the only practical way to stop cross-tenant data exposure when agents can chain requests.

Q: Why do MCP connectors create new IAM and NHI governance risks?

A: MCP connectors create risk because they turn a user-facing integration into a reusable access path that may outlive the original request context. If the connector can call multiple tools or retrieve metadata without continuous revalidation, it behaves like standing privilege. That makes it an NHI governance issue as much as an AI integration issue.

Q: What breaks when AI agents are given broad connector permissions?

A: Broad permissions break tenant isolation, because the agent can request data or tool actions that exceed the business purpose of the session. In practice, that means metadata from other organisations, unexpected tool reach, and weak auditability when the connector is trusted more than the request context. The safer pattern is narrow scope plus continuous authorization.

Q: Who should be accountable when an MCP integration exposes cross-tenant data?

A: Accountability should sit with the team that owns the connector, the policy boundary, and the downstream service, not just with the vendor or the user who triggered the action. Under IAM and NHI governance, the control owner must prove scoping, logging, and offboarding for the integration. If those controls are absent, the organisation owns the exposure.

Technical breakdown

Why MCP tool access breaks static role models

MCP gives agents a structured way to request context and invoke tools, but the security question is not whether the protocol works. It is whether the surrounding authorization layer can decide, for each request, what tool, tenant, and workflow context is actually allowed. Traditional static roles assume access can be described once and reused safely. Agentic workflows break that assumption because request sequence, timing, and destination can change mid-session. Without policy evaluation at the point of use, the connector becomes a broad conduit rather than a bounded control surface.

Practical implication: move from coarse identity grants to request-level policy enforcement that evaluates context before each tool call.

Tenant isolation in MCP connectors

Tenant isolation means one organisation’s data, metadata, and operational context must remain unavailable to another organisation, even when they share the same integration path. In an MCP environment, that boundary can fail if the connector resolves context too broadly, passes through excessive permissions, or trusts the client session more than the destination policy. The Asana incident shows how quickly a multi-tenant integration can expose project names, task descriptions, and metadata across organisational lines when isolation logic is incomplete.

Practical implication: validate that every connector enforces tenant scoping explicitly, not implicitly through application defaults.

Why long-lived tokens are the wrong trust model for agents

Long-lived tokens are dangerous in agentic systems because they treat the token as the identity boundary, even when the agent is acting on behalf of a user across multiple tools and decisions. Once a token can be reused beyond the original intent, the control plane loses visibility into whether the request is still contextually valid. The safer pattern is short-lived assertions, explicit authorization checks, and logs that bind identity to action, reason, and destination. That reduces the chance that an integration becomes a standing privilege channel.

Practical implication: replace reusable credentials with short-lived assertions and preserve a per-action audit trail.

Threat narrative

Attacker objective: The objective was not credential theft but unauthorized visibility into another organisation’s project data through an over-permissive connector.

1. Entry occurred through an MCP server integration that was intended to let users connect third-party AI tools to Asana workflows.
2. Escalation happened when the connector overreached its intended scope and surfaced project metadata from separate tenants.
3. Impact was cross-tenant exposure of sensitive data, including project names, task descriptions, and related metadata, across more than 1,000 customers.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic access control has become a tenant-isolation problem, not just an authorization problem. When an AI connector can chain requests and surface data across organisations, the failure is not limited to permission checks. The real issue is that traditional access models assume the requester stays within a single trust boundary, while MCP-mediated workflows can cross that boundary repeatedly in one session. Practitioners should treat every agent connector as a potential multi-tenant exposure path.

Context-aware enforcement is the new minimum control for MCP. This article shows that identity alone does not express enough intent to keep an agent inside its authorised scope. Policy has to account for workflow, tool, tenant, and request timing together, or the system will grant broader access than the business case justified. The implication for practitioners is that gateway-style enforcement belongs at the application edge, not only in the identity provider.

Identity-aware guardrails matter more than token possession in agentic systems. Pomerium’s example reinforces a wider pattern: if a connector can reuse credentials without continuously revalidating the request, the control boundary has already shifted too far downstream. That is why MCP security should be reviewed as part of NHI governance, not as an isolated AI feature. Practitioners need to re-evaluate where authorization actually happens in the stack.

MCP security is now part of workload identity governance. The same governance discipline used for service accounts and API keys has to extend to agent connectors that can invoke tools on behalf of users. The field is moving toward policy-scoped, short-lived, auditable access rather than broad connector trust. Practitioners should align agent access reviews with the same rigor used for non-human identities.

Scoped tool permissions are the named concept practitioners should operationalise. MCP makes it obvious that access should be limited by tool, tenant, and context rather than by a broad connector grant. When scoped permissions are missing, the blast radius expands beyond the intended workflow and becomes visible only after data has already crossed a boundary. Practitioners should use scoped tool permissions as the default design assumption.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• For the next step: The 52 NHI breaches Report shows how weak lifecycle control turns identity exposure into repeatable incident patterns.

What this signals

Scoped tool permissions will become a baseline control for any organisation adopting MCP-based workflows. The gap is structural, not cosmetic: when connectors can act across tenants or tools, access reviews alone cannot prove the session stayed inside its intended boundary. Teams should treat OWASP Agentic AI Top 10 guidance as a starting point for design review, not a final control list.

With 96% of organisations still storing secrets outside secrets managers in vulnerable places, per the Ultimate Guide to NHIs, agentic integrations inherit a trust problem before they even reach production. The signal for practitioners is simple: if you cannot prove where credentials live and how they are scoped, you cannot prove that an MCP connector is safe.

Identity-aware enforcement will shift left into the application layer. That means security teams will increasingly evaluate agent access in the same way they evaluate workload identity: short-lived, scoped, and continuously verified. Organisations that keep treating MCP as a tooling add-on will end up with an authorization gap they cannot close after deployment.

For practitioners

• Scope every MCP tool explicitly Define allowlists for each connector by tool, tenant, and workflow path so a user can invoke only the functions that match the approved business case. Review default-deny behaviour before any agent integration reaches production.
• Move authorization to the application edge Evaluate each agent request at the point it reaches the service, not only at login. Use context signals such as tenant, frequency, destination, and action type to decide whether to continue.
• Replace reusable credentials with short-lived assertions Avoid giving connectors raw long-lived tokens. Validate external identity and pass downstream only the minimum assertion needed for the specific request, then log the identity, action, time, and reason.
• Test tenant isolation with adversarial workflows Simulate cross-tenant prompts, chained requests, and malformed tool invocations to confirm that a connector cannot retrieve metadata outside its assigned boundary.
• Review agent access with NHI governance controls Treat AI connectors like other non-human identities and include them in access reviews, offboarding checks, and scope validation so they do not become standing access paths.

Key takeaways

• MCP security fails when connectors are trusted as if they were simple integrations, because agentic access can cross tenant boundaries and expose data outside the intended scope.
• The exposure scale matters: more than 1,000 customers were potentially affected, which shows that a single over-permissive connector can become a multi-tenant incident.
• The control that changes the outcome is context-aware enforcement at the application edge, backed by scoped permissions, short-lived assertions, and auditable decisions.

Key terms

• MCP server: An MCP server exposes tools and context to AI systems through the Model Context Protocol. In practice, it becomes part of the access layer, so its security depends on how tightly tool use, tenant boundaries, and authorization are enforced.
• Tenant isolation: Tenant isolation is the requirement that one customer, workspace, or organisation cannot access another’s data, metadata, or actions. In multi-tenant agentic systems, isolation must hold at the connector, policy, and service layers, not just in the user interface.
• Context-aware authorization: Context-aware authorization evaluates not only who is asking, but also what they are asking for, from where, and for what purpose. For agentic systems, that usually means checking tool, tenant, timing, and workflow context before each action is allowed.
• Short-lived assertion: A short-lived assertion is a temporary proof of identity or entitlement passed downstream for a specific request. It reduces the risk created by reusable tokens because it limits how long an integration can act and makes every action more attributable.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pomerium covering the Asana MCP connector leak: Asana's AI connector leak exposed sensitive data across organizations. Read the original.