Definition
Multiple MCP clients, belonging to different agents or users, connect to the same MCP server. A vulnerability in the server’s session isolation allows one client to interfere with the operations of another: modifying shared data, hijacking sessions, or triggering unintended actions on another client’s behalf. The interference is indirect, mediated through the shared server, rather than direct agent-to-agent communication.
What it looks like in practice
An MCP server manages access to a shared database used by two separate agents: Agent A performs compliance checks and Agent B handles customer data enrichment. A session isolation failure in the server means that Agent B’s write requests are not scoped to Agent B’s namespace; they overwrite records in the shared state that Agent A is actively reading during a compliance validation. Agent A reads partially overwritten records and produces an incorrect compliance result.
The cross-layer scenario “Schema Ambiguity Cascading Through Multi-Client Server” (T41 feeding into T42) demonstrates the compound variant: schema mismatches in T41 cause Client B to write incorrectly formatted data to the shared server state, which Client A then reads and misinterprets, combining a protocol ambiguity failure with an isolation failure into a compound data corruption event.
Why it’s dangerous in multi-agent context
MCP’s design encourages shared server deployments to aggregate data and tool capabilities. Shared servers with weak client session isolation create a cross-agent attack surface: one agent (or a malicious actor impersonating a client via T40) can corrupt the data or session state that another agent depends on. Because agents act autonomously on server responses, the corruption is not surfaced to a human; it manifests as incorrect downstream decisions. T39 (Unintended Resource Consumption via MCP) compounds the risk: a runaway agent’s excessive request volume on the shared server degrades performance for all co-located clients simultaneously.
Detection signals
Session isolation failures leave forensic evidence in the server’s concurrency and data-access logs, where writes from one client identifier appear in records owned by another.
- A write operation attributed to Client B’s session token modifying a record whose namespace prefix belongs to Client A: cross-client namespace write events should never occur and should trigger an immediate alert when they appear in the server’s access log.
- A compliance check result or other derived output from Client A that is inconsistent with Client A’s own prior reads of the same records within the same session. An intra-session consistency check on derived outputs can catch mid-read overwrites.
- Two concurrent sessions holding write locks on overlapping record sets without an explicit shared-access grant: the database’s lock acquisition log will show overlapping lock scopes for client identifiers that are not permitted to share state.
- A race condition producing a record with a
last_modified_byclient identifier that differs from the client that initiated the containing transaction: transactional audit columns that record the initiating client identity surface isolation breaches directly. - Client A’s error rate rising in correlation with Client B’s write throughput spiking. A statistical correlation between one client’s error rate and another client’s write volume is a behavioural signal of resource contention from isolation failure.
Mitigations
- Enforce per-client namespace isolation in all shared databases managed by the MCP server: no client’s writes should be visible to or overwritable by another client without explicit sharing consent.
- Scope session tokens to prevent cross-client API calls; a token issued to Client A must not be usable by Client B.
- Test client isolation under multi-client load scenarios: concurrent write operations from different clients must not produce observable cross-client effects.
- Audit the server’s concurrency model for race conditions in shared state management; enforce serialisable isolation for operations that touch shared records.
Relation to base threat (T1–T17)
T42 extends T12 Agent Communication Poisoning. Where T12 addresses direct manipulation of messages between agents, T42 addresses indirect interference mediated through a shared MCP server. The server’s isolation failure allows one client’s operations to corrupt another client’s state without any direct inter-agent communication. T41 (Schema Mismatch Leading to Errors) is the upstream cause in the compound scenario: schema ambiguity causes Client B to write corrupt data that T42’s isolation failure then exposes to Client A.
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. T42 is covered by the following Top 10 entries:
-
ASI07 Insecure Inter-Agent Communication contributing Agents in a multi-agent system pass instructions, results, and context to one another across APIs, message buses, and shared state. Without per-message authentication and integrity controls, a single compromised peripheral agent becomes an injection source for every peer it can reach. One hop becomes n-hop, and the orchestrator is reachable from the outside.
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 T42 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-Depth The isolation failure here is structural: without per-client namespace scoping, one client's writes are physically reachable by another client's reads, so any single access-control oversight collapses both boundaries at once. Depth means the namespace boundary and the session-token scope are independent layers: per-client namespace isolation ensures Agent B's writes cannot overwrite Agent A's records even if session-token scoping fails, and serialisable isolation on shared records provides a third layer so that concurrent operations from different clients cannot interleave into a corrupt state. Conformance testing under multi-client load validates that all three layers hold simultaneously.
- Microsegmentation Shared server state is the common surface that makes cross-client interference possible: without east-west isolation between client namespaces, a session isolation failure in one client immediately becomes a data corruption event for every other client reading the same records. Microsegmentation answers this by scoping each client to its own namespace: Agent B's writes are confined to Agent B's segment, so the compliance agent and the enrichment agent have no shared records to corrupt. Session tokens scoped to prevent cross-client API calls enforce the boundary at the credential layer, independent of the namespace boundary.
- Least Common Mechanism A shared MCP server with a single undivided state store is the common mechanism that connects otherwise independent agents; the more clients share it, the wider the blast radius of any one client's misbehaviour. Least-common-mechanism counters this by eliminating the shared surface: per-client namespace isolation means Agent A and Agent B do not share writable state, so Agent B's malformed writes (arriving via T41's schema mismatch) have no path to the records Agent A is reading. Separate MCP instances per trust boundary take this further, removing even the shared process as a common failure point.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T42, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
- Tier 2 Cross-client isolation (Cross-client isolation — request-scope tenant boundaries in shared MCP server deployments)
A shared MCP server that accepts connections from multiple clients is a concentration point where one client's session state, credentials, and resource budget are physically co-located with every other client's. Without enforced isolation, a malicious or compromised client can read another session's cached credentials, consume shared resources to the point of denying service to other clients, or exploit aggregate server permissions that exceed its own declared scope. Cross-client isolation is the set of structural controls that close those paths: per-session state scoping, per-client permission evaluation, and per-client resource quotas enforced at the server layer.
why it helps Cross-client interference in a shared MCP server depends on access to another session's state, cached credentials, or shared memory. Per-session state scoping, per-request context isolation, and session-key separation structurally remove those access paths, so there is no session artifact for an interfering client to reach.
-
An inter-agent message travels through channels and intermediate agents the receiver did not originate. If nothing binds the message cryptographically to its source, any intermediate hop can substitute or inject content that the receiving agent will treat as authoritative. Message signing closes that gap: the source agent signs each message payload with its private key, and the receiver verifies the signature against a distributed trust bundle before the content reaches the reasoning layer.
why it helps Cross-client interference via shared MCP server is partially mitigated when client requests carry per-client signatures. A message relayed from one client session cannot be attributed to another without possession of the originating client's signing key.
Multi-agent variants: OWASP MAS Guide
The OWASP OWASP MAS Threat Modelling Guide v1.0 catalogues 1 named multi-agent variant of T42, anchored to specific MAESTRO layers. Each is a concrete attack pattern that emerges when this threat compounds across agents.
- CL Cross-Client Inference Interference extends T42, T45, T28
Shared inference infrastructure (T42: side-channel) allows a tenant to observe timing or cache patterns from a co-tenant session (T45: session isolation failure); incomplete sandboxing (T28) lets the attacker infer private prompt content across clients.
Source: OWASP MAS Threat Modelling Guide v1.0, §2 Overview of MAESTRO Framework — Extended Threat Scenarios + Cross-Layer table.
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.
AML.T0080 AI Agent Context Poisoning view on ATLAS ↗ Adversary contaminates an agent's context store (short-term scratchpad, vector memory, conversation history) so future reasoning is biased toward attacker goals.
Agentic angle: Persistent across sessions: a single successful poisoning influences every later decision until the memory is purged.
AML.T0053 AI Agent Tool Invocation view on ATLAS ↗ Adversary causes an agent to invoke a legitimate tool with attacker-controlled parameters, turning a sanctioned capability into an attack vector.
Agentic angle: Maps directly to OWASP T2 Tool Misuse: the agent's tools are operating within their declared scope, but the chosen invocation is unsafe.
AML.T0073 Impersonation view on ATLAS ↗ Adversary poses as a trusted entity (user, service, peer agent) to gain access or influence decisions.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §5 Anthropic MCP — Layer 3 Agent Frameworks.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §5 Anthropic MCP — Layer 3 Agent Frameworks