Notifications
Clear all
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.
NHIMG editorial — based on content published by Pomerium covering the Asana MCP connector leak: Asana's AI connector leak exposed sensitive data across organizations
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Move authorization to the application edge Evaluate each agent request at the point it reaches the service, not only at login.
- Replace reusable credentials with short-lived assertions Avoid giving connectors raw long-lived tokens.
What's in the full article
Pomerium's full post covers the operational detail this post intentionally leaves for the source:
- The exact MCP gateway policy pattern used to constrain search and fetch while blocking broader tool actions.
- The example configuration showing how identity assertions are injected downstream without passing raw OAuth tokens.
- The logging model for recording identity, action, time, and reason on each request.
- The deployment guidance for wrapping internal services with a policy enforcement layer.
👉 Read Pomerium's analysis of the Asana MCP connector leak and guardrails →
MCP server isolation gaps: what IAM teams need to fix now?
Explore further
12/06/2026 11:09 pm
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.
A few things that frame the scale:
- 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.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Asana's MCP leak shows why agentic access needs guardrails
