TL;DR: Asana’s MCP server bug exposed sensitive project metadata across tenants and potentially affected more than 1,000 customers, showing that agentic access without context-aware enforcement can pierce basic isolation boundaries, according to Pomerium. Static IAM assumptions are failing as AI tools chain requests and act asynchronously, so policy must move closer to the application boundary.
At a glance
What this is: This is an analysis of Asana’s MCP server leak and the broader lesson that agentic access can pierce tenant boundaries when enforcement is not evaluated at request time.
Why it matters: It matters because IAM, PAM, and NHI teams now have to govern AI-driven access patterns that operate asynchronously, chain requests, and outgrow static role assumptions.
Context
Model Context Protocol creates a new class of access path: software agents can use tools and internal systems on behalf of a user, but the access decision now depends on the request context as much as the identity itself. When that control plane is weak, tenant isolation becomes fragile because the agent can reach data it was never meant to see.
In Asana's case, the issue was not simple authentication failure. The governance gap was that access was being evaluated too coarsely for agentic workflows that chain requests, operate asynchronously, and can overreach across organisational boundaries if enforcement does not follow the action.
Key questions
Q: What breaks when MCP connectors are allowed to overreach their intended scope?
A: Tenant isolation breaks first, because the connector can surface data from outside the requesting organisation even when the user is authenticated. That is a policy failure at the boundary between the agent and the application, not simply a login problem. The practical test is whether every tool call is constrained to the minimum tenant and action scope required.
Q: Why do agentic access paths create new governance risk for IAM teams?
A: Because the actor can initiate actions at runtime and reach tools or data through delegated authority, which makes static entitlement thinking incomplete. IAM teams need visibility into who or what is acting, what it can call, and how that authority is bounded across the session or workflow.
Q: How do organisations know whether MCP enforcement is actually working?
A: The clearest sign is that every meaningful agent action produces a consistent attestation trail and can be blocked when the session lacks provenance. If requests still succeed through direct APIs, side connectors, or browser clicks without governance metadata, enforcement is incomplete and the control plane is not authoritative.
Q: What should IAM and NHI teams do when agent requests can reach internal systems on behalf of users?
A: They should treat each request as a governed action, not just a continuation of the original user session. That means enforcing continuous authorisation, narrowing tool scope, and logging the decision context for every invocation. Accountability stays with the organisation, but the control point has to move closer to the application and connector layer.
Technical breakdown
Why MCP changes the access-control boundary
MCP is a tool-access layer for AI agents, which means the security question is no longer just who authenticated, but what the agent is allowed to do with each tool call. That shifts enforcement from session-level trust to request-level authorisation. In this model, a connector can become an execution surface for data retrieval, task actions, and downstream API calls. If policy is not evaluated at the application boundary, the agent can inherit more reach than the user or workflow intended. The problem is especially sharp when a single connector can touch multiple tenants or data domains.
Practical implication: enforce policy at the MCP gateway or application boundary, not only at sign-in.
How asynchronous agent behaviour breaks static IAM assumptions
Traditional IAM assumes access is granted to a known actor, in a known context, for a reasonably stable session. Agentic systems violate that assumption by chaining requests, calling tools on behalf of users, and acting at machine speed between human checkpoints. That makes coarse role checks too blunt, because the risky part is often not the first request but the follow-on request the agent generates. Context-aware enforcement evaluates the current task, the allowed tool, the target resource, and the frequency or timing of the request. Without that, long-lived tokens and inherited permissions become an open-ended trust channel.
Practical implication: replace static entitlements with request-time checks that evaluate task context and tool scope.
Why tenant isolation fails when tool scope is too broad
Tenant isolation depends on the control plane rejecting cross-boundary data access even when the caller is authenticated. In agentic architectures, that boundary can fail if the tool itself is allowed to return data beyond the requesting user's organisation. The failure mode is not just a leak of one record. It is a policy gap where project names, task descriptions, and metadata become reachable through a connector that was trusted too broadly. That is a governance problem as much as a technical one, because the organisation has effectively delegated enforcement to the wrong layer.
Practical implication: scope each tool to the minimum tenant and action set it actually needs.
Threat narrative
Attacker objective: The objective was to obtain data from outside the requesting organisation by exploiting an overbroad agentic access path.
- Initial access began through a legitimate MCP integration that was meant to help users automate work across third-party apps.
- The connector then overreached its intended scope and surfaced data from other organisations instead of limiting results to the active tenant.
- The impact was cross-tenant exposure of project names, task descriptions, and metadata that should have remained isolated.
Breaches seen in the wild
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
- Indian government breach 2021: Sakura Samurai found exposed .git and .env files across Indian government sites, leaking 35 credential pairs, private keys and personal data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agentic access invalidates the assumption that identity is the primary control point. In MCP-driven architectures, the caller may be authenticated correctly while the request itself is still unsafe. That means the enforcement question moves from who the user is to what the agent is trying to do right now. Practitioners should treat request context as a first-class control input.
Tenant isolation is now a policy-design problem, not just a data-segmentation problem. The Asana case shows that multi-tenant exposure can emerge when tool scope outpaces boundary checks. If a connector can return cross-org metadata, the isolation model has already failed before the data ever reaches the application layer. Practitioners need to re-evaluate where the trust boundary actually sits.
Continuous authorization is the named concept this incident reinforces. A one-time login does not describe the risk surface of an AI agent that chains requests and acts asynchronously. The control must be re-evaluated at each tool invocation because the agent's purpose, target, and reach can change mid-session. Practitioners should move governance closer to the point of action.
Static IAM assumptions are too slow for agentic systems. Traditional role assignment presumes stable intent, but agent workflows can generate new decisions faster than recertification or periodic review can capture. That creates a mismatch between governance cadence and execution cadence. Practitioners should redesign access control around task scope, not just principal identity.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Continuous authorization becomes the practical boundary for MCP governance. Agentic systems can shift from one request to the next without a human checkpoint, so session trust is too blunt to protect internal systems. Security teams should expect policy to move closer to the application layer, where the current task and resource can actually be evaluated.
The deeper lesson is that tenant isolation is no longer guaranteed by authentication alone. Once a connector can call internal tools on behalf of a user, the control question becomes whether the tool is scoped tightly enough to prevent cross-boundary data return. That is a governance design issue, not just a runtime bug.
For practitioners
- Shift enforcement to the application boundary Place authorisation checks at the MCP gateway or service endpoint so every tool call is evaluated in context before it reaches internal systems.
- Scope tools to explicit tenant boundaries Restrict each connector to the minimum tenant, resource, and action set it needs, and block any cross-organisation result path by default.
- Replace long-lived trust with request-time checks Require fresh policy evaluation for each agent request, including purpose, tool, target resource, and frequency, rather than reusing broad session trust.
- Log the decision context for every agent action Record identity, action, time, reason, and tool selection so security teams can reconstruct why an agent was allowed to reach a given resource.
Key takeaways
- The Asana MCP leak shows that authenticated agentic access can still violate tenant boundaries when the connector is allowed to overreach.
- Static IAM assumptions do not fit asynchronous AI workflows, because the risk appears in later tool calls rather than the initial login.
- Policy must be evaluated at request time, with tight tool scope and boundary-aware logging, if organisations want MCP to remain governable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and OWASP API Security Top 10 define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on authenticated agent access that still needs stronger request-level enforcement. |
| NHI-08 — Environment Isolation | Cross-tenant data exposure is the core failure mode described in the article. | |
| NHI-10 — Human Use of NHI | The article describes users delegating actions to agents that operate on their behalf. | |
| Recommendation — Enforce request-time authentication and authorisation for every MCP tool call. Separate tenant-bound resources so connectors cannot return data across organisational boundaries. Govern delegated agent actions as NHI activity rather than treating them as ordinary user clicks. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The incident shows an agentic access path exceeding intended privilege boundaries. |
| Recommendation — Constrain agent privilege so tool calls cannot exceed the authority granted for the current task. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | A connector exposing too much capability is fundamentally an authorisation failure at the function layer. |
| Recommendation — Authorize each MCP function explicitly and block capabilities that cross tenant or role boundaries. | ||
Key terms
- MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
- Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.
- Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.
- Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
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.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org