Topic starter
12/06/2026 9:14 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “Asana's AI Connector Leak Exposed Sensitive Data Across Organizations: What It Means for MCP Security”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The Asana MCP leak shows that authenticated agentic access can still violate tenant boundaries when the connector is allowed to overreach.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/06/2026 11:09 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Asana's MCP leak shows why agentic access needs guardrails