Data Residency / Compliance Violation via MCP Server

OWASP Top 10 for Agentic Applications 2026

The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T46 is covered by the following Top 10 entries:

• ASI08Cascading Failuresrelated

  A single low-severity fault (a hallucinated value, a corrupted tool output, a poisoned memory entry) propagates across a network of agents that each build on the last agent's output, compounding into system-wide harm that is disproportionate to the original defect. ASI08 is about propagation and amplification, not the fault's origin; the initial trigger may itself be innocuous.

  OWASP LLM Top 10:LLM01:2026LLM05:2026LLM03:2026

Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.

Design principles at stake

When T46 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.

• Defence-in-DepthA data residency violation can occur on any individual query: an agent requests EU customer records, the server retrieves and returns them through the wrong jurisdiction, and the transfer is complete before any single control has a chance to intervene. Depth means three independent gates must all be absent for a violation to succeed: data classification tags on MCP resources identify regulated data before retrieval, residency controls at the server level reject requests from clients outside permitted jurisdictions, and per-request logging with client identity and resource retrieved creates the audit trail that exposes any transfer that slipped through the first two. Without all three, the autonomous, high-speed nature of agent interactions means violations occur at scale before detection.
• Data Minimization & PrivacyT46's second variant shows data-minimisation violated without any single access being non-compliant: combining a customer interaction history with a product usage log through MCP creates a profile that GDPR's purpose-limitation principle prohibits, even though each individual source access was lawful. Data minimisation at the MCP layer means classifying the data each server exposes according to applicable regulatory requirements, enforcing residency controls that prevent cross-jurisdiction retrieval, and conducting a data flow mapping exercise to identify every aggregation path through which regulated data can be combined in a way that exceeds the original collection purpose. Per-request logging of what was retrieved and from which resource gives auditors the visibility to detect purpose creep before it accumulates into a reportable violation.

Recommended mitigations

Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T46, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).

• Tier 2Data classification(Data classification with tool-access allow-lists — a sensitivity label on every dataset, enforced at every access seam)

  Every dataset, document, and external system an agent can reach carries a classification label. The agent's permitted-class set and the tool's permitted-class set are intersected at the moment of every read or write. When the requested data's class falls outside that intersection, access is denied at the seam. This is the data-side complement to least-privilege: it adds a data-sensitivity constraint that role scoping alone does not provide.

  why it helps Data residency and compliance violations occur when data crosses a jurisdictional or regulatory boundary it must not cross. Classification labels that encode jurisdictional scope (for example, EU-PII or HIPAA-PHI) can drive MCP server access-control rules that block cross-border data transfer to agents outside permitted jurisdictions, directly reducing compliance-violation risk.

• Tier 2Egress DLP(Output egress DLP — inspection gate for PII, secrets, and IP at the agent boundary)

  An agent produces output continuously across multiple channels: user-facing responses, tool-call parameter envelopes, log records, and outbound HTTP requests. Any of those channels can carry sensitive content the agent has retrieved, been fed, or been tricked into including. Output egress DLP places an inspection gate at the boundary so that PII, credentials, and proprietary content are classified and either redacted or quarantined before they leave the trust boundary, regardless of how they got into the output.

  why it helps Data residency violations occur when PII or regulated data crosses jurisdictional boundaries through an agent's output channel. The egress gate detects regulated-data patterns in outbound payloads and quarantines them before the cross-border transfer completes.

• Tier 2Egress isolation(Network egress isolation — deny-by-default agent→internet, enforced at the network layer)

  Content-layer inspection reads outbound payloads and decides pass, redact, or quarantine per channel — but it can only classify what it can parse as content. A direct TCP/UDP socket opened by agent-executed code, a raw DNS query, or a payload encoded into DNS subdomain labels never reaches an HTTP-shaped inspection point at all. Network egress isolation closes that gap one layer down: every agent and tool-bus process sits behind a default-deny network policy, and the only path to the internet is through an enforced proxy that mediates, allowlists, and logs each connection attempt regardless of what it contains.

  why it helps Data Residency violations occur when a call crosses a jurisdictional boundary the data isn't authorised to cross. Content classification can miss a residency violation if the regulated field isn't recognised as such; a proxy with a jurisdiction-scoped destination allowlist blocks the cross-border connection at the network layer independent of what the payload classifier decided.

• Tier 2RBAC/ABAC(RBAC and ABAC: role-based and attribute-based access control for agents)

  Role-Based Access Control (RBAC) assigns every agent identity a named role that sets the outer limit on what it can reach. Attribute-Based Access Control (ABAC) narrows individual decisions inside that role by evaluating contextual attributes at request time. Used together, they enforce least privilege for non-human identities: the agent can only do what its role permits, and only when the request attributes satisfy the policy.

  why it helps Data residency violations occur when an agent in one jurisdiction reads or transfers data classified as belonging to another. ABAC conditions that encode jurisdictional attributes on both the requesting agent and the target resource enforce residency at the access-control layer, before any read or transfer takes place.

Red-team pivot: MITRE ATLAS techniques

MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.

© 2026 The MITRE Corporation. ATLAS content is reproduced and distributed with the permission of The MITRE Corporation.

Related threats

• T8: Repudiation and Untraceability
• T44: Insufficient Logging in MCP Server / Client
• T28: RAG Data Exfiltration

References

• OWASP MAS Threat Modelling Guide v1.0 (April 2025) §5 Anthropic MCP — Layer 6 Security and Compliance.

Sources

• OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §5 Anthropic MCP — Layer 6 Security and Compliance

Adapted by Helmwart from the OWASP source(s) above underCC BY-SA 4.0(changes: normalized IDs, added MAESTRO-layer, agentic-factor, and mitigation mappings). This entry is licensed CC BY-SA 4.0.