security platforms that monitor agent context drift during live MCP sessions

Context drift is what happens when an AI agent, mid-session, starts acting outside the job it was given. It's a runtime problem, not a config problem, and that gap matters because most security tools built for MCP (Model Context Protocol) sessions still check configuration, not behavior. This piece covers what drift looks like, the attacks that use it as their engine, and what a monitoring platform has to do to catch it while a session is still live, not after the fact. Get this wrong and the scanner you bought tells you nothing about the fifteen minutes after it finished scanning, which is exactly when the damage happens.

Start with the design itself. MCP lets an agent receive tool descriptions from a server and treat them as trusted operating instructions. Nothing in the protocol checks whether that trust still holds ten minutes into a session. The NSA's May 2026 advisory named the structural inversion at the heart of this: MCP flips the old client-requests-data pattern so servers query and execute on behalf of clients. Traditional monitoring was built to trace a client acting on a server, not the reverse, which is the wrong direction now.

Static scans and pre-deployment audits catch what's wrong at a single point in time. They can't watch a server that behaves fine at session start and pivots halfway through. The MCPShield paper (arXiv:2602.14281, February 2026) gives this a name: temporal misalignment. Most agent frameworks assume tool calls behave as declared, gather no security evidence while a call is running, and carry nothing forward from one invocation to the next. So even when a check does happen, it doesn't stick around to inform the next tool call. The whole failure sits in one sentence: the system checks once and remembers nothing.

Drift rarely stays contained to one layer, either. Server metadata, tool descriptions, permission scopes, and auth tokens can all shift at once, and each shift compounds the others. The MCP ecosystem has already passed 97 million monthly SDK downloads, with more than 10,000 active public servers running, and Datadog logged a 22x jump in MCP tool calls since Q4 2025. That's a lot of live sessions for something still treated like a one-time scan problem.

The real danger is the misconfigured server that slips past a scan. It's the agent that passes every upstream check clean, then changes behavior mid-execution while every dashboard still shows green. Anyone still buying tools that only check at the handshake is solving last year's problem, and paying full price for it.

The specific behaviors that constitute context drift in a live MCP session

Drift is the buildup of many small actions, not one big jump. Picture it as a trajectory: a slow bend in an agent's tool choices, data access, and task focus, away from whatever it was originally asked to do.

The MCPShield researchers break the problem into three gaps. There's the semantic gap, where a tool's declared metadata doesn't match what the tool actually does. There's observational discrepancy, where the return value an agent sees masks what actually ran underneath. And there's long-term behavioral inconsistency, where a tool acts normal across the first several calls, then pivots, so invocation history is the only witness that ever catches it.

Rug-pull attacks live in that third bucket. A server gets approved once, then quietly redefines its own tool descriptions afterward. The protocol provides no built-in mechanism to re-verify tool versions past the initial handshake, so the agent keeps trusting a tool that's already been swapped out from under it.

Tool shadowing works differently. A compromised server injects overriding descriptions that reach into a different, trusted server running in the same session, nudging the agent's tool choices without changing anything a user could see. Invariant Labs documented this cross-server weaponization through a responsible disclosure. It's a clean example of why single-server security checks miss so much: the attack doesn't originate where the damage shows up.

Worth separating intent drift from credential drift here, because detection has to treat them differently. Intent drift is when the tool-call sequence wanders from the stated goal: scope creep, quiet lateral movement, tasks that balloon past their original ask. Credential drift is when the session picks up more access rights than the task ever required, usually because a token was over-permissioned or long-lived to begin with.

None of this shows up where a user would notice. Tool descriptions and injected instructions sit inside the model's context window, not the interface. The user sees a clean result while the agent, underneath, executes something else entirely. EchoLeak (CVE-2025-32711), the attack against Microsoft 365 Copilot, made this concrete: a hidden prompt in an email got pulled into Copilot's retrieval context and executed, no user action required.

Documented attack classes that exploit context drift as their mechanism

Tool poisoning, cataloged under OWASP as MCP03:2025, hides adversarial instructions inside a tool's description or parameter schema. That text gets fed to the model as trusted operational context, and no native MCP mechanism flags or blocks it. The user never sees any of it.

Two 2025 incidents show what this looks like outside a lab. In May, a GitHub MCP prompt injection combined over-permissioned tokens with untrusted context to expose private repository contents, salary data included. The flaw was architectural rather than something isolated to a single server's implementation. In April, a WhatsApp MCP exfiltration used hidden instructions buried in a malicious server's tool descriptions, textbook tool poisoning, to pull entire message histories out.

EchoLeak deserves a second look on its own terms. Attackers embedded a hidden prompt inside a crafted email. When Microsoft 365 Copilot retrieved that email through its retrieval-augmented context, no summary request, no click, nothing, it executed the attacker's instructions and leaked sensitive data. Zero user interaction. That's about as close as this space gets to a textbook case.

Also worth flagging: CVE-2025-6514, rated 9.6 on CVSS, an OS command injection bug in mcp-remote versions 0.0.5 through 0.1.15 (patched in 0.1.16). The package had logged more than 437,000 downloads. A malicious server could trigger command injection on the client machine before a session was fully established. It stands as a documented case of full remote code execution on a client OS through a connection to an untrusted MCP server.

OX Security surfaced something broader in April 2026: a design flaw in the STDIO transport baked into official MCP SDKs across Python, TypeScript, Java, and Rust. An attacker able to touch an MCP config file gets arbitrary code execution on the host. OX estimated 200,000 vulnerable instances sitting inside a supply chain with more than 150 million package downloads. Anthropic reviewed it and called the behavior intentional, declining to change the protocol's architecture. Read that twice: the vendor looked at the flaw and said it's working as designed.

Government agencies aren't treating any of this as speculative anymore. A government advisory from the NSA named tool poisoning, rug-pull attacks, and cross-server trust exploitation as priority risks for agentic AI deployments. MITRE ATLAS added 14 new agent-focused techniques in October 2025, including AI Agent Context Poisoning, Memory Manipulation, and Thread Injection. Drift-class attacks are now in the field's actual threat taxonomy, not sitting off to the side as edge cases.

Why authentication gaps and credential sprawl amplify drift risk at the session layer

MCP's authorization spec defines an OAuth 2.1 framework, but leaves authorization optional. That single word, optional, does more damage than any single exploit on this list. A July 2025 internet scan found 1,862 publicly reachable MCP instances responding to unauthenticated requests. Trend Micro ran a separate scan and found 492 MCP servers exposed with zero authentication at all.

Only 8.5% of public MCP servers actually use OAuth. That leaves the other 91.5% without any standardized identity signal a monitoring platform could use to build a behavioral baseline against. Hard to spot an agent drifting from its normal pattern when nothing tells you what normal even looks like in the first place.

The confused-deputy problem is baked into the protocol itself. The MCP server runs actions under its own permissions, often broad ones, not the requesting user's. The protocol doesn't carry user context from host to server by default, so the server can't tell one user from another. A drifting agent can quietly pick up more effective access than it should have, and nothing in the architecture stops it.

Credential handling makes this worse in a few specific ways. Tokens handed to MCP servers are frequently over-permissioned, long-lived, and unscoped from the start. Long-running async tasks can outlive their original access tokens, so without solid refresh strategies, sessions keep running on stale or overly broad credentials. And the leg between the MCP server and the final tool, Salesforce, GitHub, whatever sits downstream, usually runs on custom implementations with no standard scoping or rotation. That's a second authentication gap sitting right behind the first one, and most teams never even check for it.

Scale is the part that makes manual oversight a non-starter. Machine identities already outnumber human ones somewhere between 45:1 and 100:1 in a typical enterprise, by industry estimates. Only about 23% of organizations have a formal identity strategy for AI agents, and only 14.4% of agents make it to production with full security approval. Put an over-permissioned, unmonitored credential inside a session where tool definitions can silently change, and drift goes unnoticed until it's already done damage.

What continuous behavioral monitoring of a live MCP session must actually do

Detection has to run across the whole invocation lifecycle, not just one phase of it. Security evidence gathered before a tool call has to get carried forward and reused on the next one, and the one after that, within the same session. That's the core requirement the MCPShield research lays out, and it's a fair bar for any platform claiming to do this.

The framework splits detection into three phases. Pre-invocation is metadata-guided probing: the system runs mock invocations and checks the observed behavior before the agent commits to a real call, confirming declared capabilities match what actually runs. Execution monitoring catches out-of-bounds requests as they happen: tool calls that reach past the declared task, access patterns that don't fit the session's stated intent, parameter values that look off. Post-invocation reflection looks back across the full invocation history for long-term inconsistency. A server that behaves for ten calls and pivots on the eleventh is only catchable if the platform kept the whole trace and actually reasoned over it.

A behavioral monitor needs to track a handful of signals, continuously, not as a one-time gate. Whether each tool call's purpose lines up with the session's sanctioned goal. Whether tool descriptions have changed since the session started, or since the last call. Whether one server's tool rankings are quietly steering choices toward tools on a different server. Whether the agent is touching data outside what the task calls for. Whether credentials are being used in ways that don't match their issued scope.

Sandboxing alone doesn't cover any of this, and treating it as a substitute for behavioral monitoring is the mistake most teams make first. A sandbox stops damage after a boundary gets crossed, but it gives no warning about the drift that led to the crossing. A platform that only sandboxes has no signal an agent is drifting until the agent has already acted on it. That gap is significant. It's the whole gap.

Tamper-proof audit logs and full session tracing aren't nice extras here. They're the evidentiary record that makes post-invocation reflection and incident reconstruction possible at all. Without them, drift only gets confirmed after the damage is done, never during the session while something could still be stopped.

And identity needs binding at the level of each individual tool call, not just at the session handshake. That's what connects a behavioral anomaly back to a specific agent, a specific credential, and a specific policy scope, instead of leaving security teams to guess which of a dozen calls in a session actually caused the problem.

How current security platforms approach live MCP session monitoring

Most enterprise security tools were built around human-initiated, request-response traffic. Bending that toward continuous, autonomous, multi-server MCP sessions takes real architectural work, not a settings change.

On the research side, MCPShield (arXiv:2602.14281, February 2026) offers one working model: an agent-side plug-in policy that runs security cognitive probing before invocation, constrains execution inside a sandbox while reading runtime events during execution (what the paper calls Isolated Projection), and updates its own security reasoning based on the accumulated session record after invocation. The paper reports strong generalization across six novel MCP attack scenarios and six widely used agentic LLMs, with few false positives on benign servers and low overhead. It's a research framework right now, not something running in production enterprise environments yet, and that gap matters more than the paper's results do.

On the product side, some vendors route everything through an MCP gateway: a proxy that sits in front of every tool call, enforces policy, checks tool descriptions for changes, and logs what happened. Whether that actually works depends entirely on where the gateway is looking. Does it inspect every tool call, or does it check things once, at the session handshake, and call it done?

The real question for any platform on the market is whether it keeps security evidence from earlier in a session and uses it to judge later tool calls, or treats every call as its own isolated event. Platforms built the second way can't catch temporal drift, full stop, because temporal drift is by definition a pattern across time, and a stateless check never sees a pattern, no matter how often you run it.

A decent proxy for how deep a platform's detection actually goes: does it catch a tool description changing mid-session, or only at initial registration? Rug-pull attacks are invisible to anything that only checks once, at the start. If a vendor can't answer that question directly, assume the answer is no.

The pressure to close this gap isn't abstract. Somewhere between 47% and 53% of organizations report AI agents that have already exceeded their permissions or caused an incident. HackerOne logged a 540% jump in prompt-injection reports. Passive, point-in-time monitoring clearly isn't holding the line, and no amount of dashboard polish changes that.

What a security team needs to verify before trusting a platform's drift detection claims

Ask whether detection covers the full lifecycle, pre-invocation, during execution, and post-invocation, or just one of those phases. Phase-local detection misses temporal drift by design, not by accident, so don't accept "we monitor execution" as a full answer.

Ask about tool-description change detection specifically. Can the platform catch a rug-pull, a server that redefines its own tools after the initial handshake, and either alert on it or kill the session? A vendor should be able to demonstrate this against a server that modifies its schema partway through, live, not in a slide deck.

Ask about cross-server visibility. Can the platform see when one server's tool descriptions or ranking signals are quietly steering calls toward a different, trusted server in the same session? Tool shadowing doesn't show up without that cross-server context, and most gateways never look for it.

Ask where identity gets bound: at the individual tool call, or only once, at session start? A tamper-proof, per-call audit trail is the minimum bar for reconstructing an incident or passing a compliance review afterward.

Ask how credential scope gets enforced. Does the platform issue tokens just-in-time and stop them from accumulating scope as a session runs longer, or does it just watch and hope the original scope holds? Hope is not a control, and any vendor pitching it as one should lose the deal on that answer alone.

Ask about alert latency, too, the gap between a drift signal (an odd tool call, a schema change, data access outside the task) and an alert a human or a policy engine can actually act on. Detection that only surfaces after a session ends is forensic. It's useful for the post-mortem, not for stopping anything in progress, and teams that confuse the two end up writing incident reports instead of preventing them.

Last thing worth checking: how fast a vendor updates its detection logic when the MCP spec itself changes. The specification saw a material release in July 2026, following a release candidate in May and a roadmap update in March, covering stateless sessions, Enterprise-Managed Authorization, and a shift from Dynamic Client Registration to Client ID Metadata Documents, plus server-to-client change notifications. A detection rule tuned to an older version of the spec is exactly the kind of gap that turns into next year's incident report.