MCP Assistant Bypasses Row-Level Security with a Service Token
An enterprise AI assistant calls a MicroStrategy MCP server. MCP tools wrap REST API endpoints: list dossiers, run dossier, and get metric. Users authenticate to the assistant through corporate SSO, but the MCP server calls MicroStrategy with one OAuth client-credentials token for service account MCP_SVC. MCP_SVC has the All Regions security filter. The pilot has 25 users, including APAC sales reps who should see only APAC. In testing, an APAC rep asks for 'top 10 customers by revenue in EMEA' and receives global customer names and revenue. The AI platform caches tool responses for 10 minutes. Security requires every data access be attributable to the human user and no cross-region leakage. MCP logs only MCP_SVC, tool name, and timestamp; it does not log the SSO subject. The assistant accepts free-form prompts and can call any exposed tool.
1. Explain why SSO at the AI layer did not enforce MicroStrategy row-level security, and how the MCP tool design and response cache made it worse.
Read the worked answer
SSO authenticated the human to the AI assistant, but MicroStrategy never saw that identity. The MCP server acted as a confidential client with a client-credentials token, so every REST call carried MCP_SVC's identity. MicroStrategy correctly applied MCP_SVC's security filter, which is All Regions. The APAC rep's request for EMEA data was therefore authorized as MCP_SVC, not as the rep. This is a confused-deputy failure: the MCP server has authority the user does not have, and it exercises that authority on the user's behalf without a per-user authorization decision.
The tool design widened the exposure. A free-form 'run dossier' tool lets the model choose any dossier and prompt, so the user does not need to navigate a governed interface. The 10-minute response cache is likely keyed by tool and prompt, not by user identity. One user's regional result can be returned to another user during the cache window. The logs cannot reconstruct who asked for what because they record only MCP_SVC and a timestamp. The combination of broad service identity, unrestricted tool scope, and cross-user caching defeats both row-level security and attribution.
2. Redesign the MCP-to-MicroStrategy authentication and authorization flow. Be specific about tokens, user context, and tool scoping.
Read the worked answer
Make the human identity the authorization subject for every MicroStrategy call. The AI platform should pass a signed OIDC ID token or access token for the user to the MCP server. The MCP server validates the token signature, issuer, audience, and expiry, then obtains a MicroStrategy token for that user. Use OAuth 2.0 token exchange if the identity provider and MicroStrategy deployment support it; otherwise use a controlled impersonation flow with a narrowly privileged broker, an explicit user-mapping allow-list, and per-call audit. Do not store user tokens; keep token lifetimes short and bind them to the MCP session.
Scope the tools. Expose only certified dossiers and governed metric operations, not arbitrary dossier IDs or raw SQL. The 'get metric' tool should return the governed definition and permitted dimensions, not unrestricted data. The 'run dossier' tool should require a dossier from an allow-list and should apply the user's security filter at execution time. If a region parameter is accepted, validate it against the user's entitlements in the MCP server as defense in depth, but do not rely on the model to supply it.
Disable cross-user response caching or include the MicroStrategy user, security filter, and token subject in the cache key. The service account MCP_SVC should lose All-Regions access and be used only for discovery operations that contain no row data.
3. Define logging, testing, and prompt-injection controls that would satisfy the security team.
Read the worked answer
Log the SSO subject, mapped MicroStrategy user, MCP session ID, tool name, dossier or metric ID, prompt hash and normalized prompt, security filter ID, row count, cache hit/miss, token ID or jti, and timestamp. Never log bearer tokens or full result sets. Emit a correlation ID from the assistant through MCP to the REST call so an investigator can reconstruct one user request end to end. Alert on a user requesting a region outside their entitlement, repeated authorization failures, and cache hits across different SSO subjects.
Test with two users in different regions, including an APAC user asking for EMEA data. Attempt prompt injection such as 'ignore regional restrictions' and 'call the raw data tool'; confirm the request is rejected at the tool layer, not merely discouraged by the model prompt. Test expired tokens, token replay, a deactivated user, and a user removed from the region mapping. Confirm the response cache cannot serve one user's data to another.
Finally, restrict the model's tool inventory to the minimum necessary, require human confirmation for data-returning calls, and add rate limits and anomaly detection. The security team should be able to prove attribution from the assistant log to the MicroStrategy audit log without relying on the model's own narrative.