security platforms that monitor agent context drift during live MCP sessions

Most enterprise security stacks were never built to see agent context drift during live MCP sessions, which is the gap these monitoring platforms now address. Context drift is the condition where an AI agent's behavior quietly moves away from what was approved at the start of a session, driven by what accumulates in its context window as the session runs. This piece explains why drift is a distinct threat, not just a new name for prompt injection, how it builds step by step, why existing tools miss it, and what real monitoring at tool-call depth needs.

Why context drift is a distinct threat

The trust gap at the center of this problem is simple to state and hard to close. Tool definitions get reviewed once, when a session opens, but tool responses keep flowing in afterward, and they never get that same scrutiny. That asymmetry is the whole story. Every MCP tool call returns text appended directly to the model's context, so every connected server works as a continuous push channel, not a one-time handshake. The agent's effective instructions change with each new response it receives, not just at the moment the session was set up.

That is a structurally different problem from tool poisoning at connection time. Tool poisoning happens at the door. Drift happens after the door is already open, inside a session that looks authorized from start to finish. The "rug pull" pattern makes this concrete: a tool's description or behavior changes silently after a user has already approved it, so the agent keeps operating on a premise that quietly stopped being true, and no new approval screen ever appears to flag the change (drawing on the broader framing in the research brief). Nothing in the session's audit trail distinguishes a tool behaving as approved from a tool that has since been altered underneath the agent.

The NSA's cybersecurity information sheet on MCP, published in May 2026, describes the protocol's core design inversion directly: servers query and execute on behalf of clients rather than the other way around, and that inversion creates attack paths the agency calls "largely not well-traced". That phrase describes exactly where drift operates. It is a live-session condition produced by the protocol's own architecture, not a known category of MCP risk wearing a new label, and it needs its own detection approach.

How drift develops inside a live session

Drift builds through the context window, one tool response at a time. Each response the agent receives becomes part of what the model treats as its operating reality on the next turn, so a session that started with a narrow, fully approved task can end up somewhere materially different without a single dramatic moment that would trip a traditional alert.

The most common way that happens is prompt injection carried inside ordinary MCP responses. Tool calls return text or structured data serialized as text, and whoever controls the contents of a Jira ticket, a Slack message, a database row, or a scraped webpage controls part of what the model reads next. The agent treats data and instruction the same way once that content lands in its context.

Tool parameter injection works the same mechanism in the other direction. Checkmarx's analysis found open-source MCP agents exposing sensitive server data after unsanitized tool parameters, passed through malformed MCP messages, were executed without contextual validation. The interface doing the damage was the legitimate one. Nothing had to be smuggled past access controls because there was no check in place to catch it at the point of execution.

From there, drift stops being contained to a single session. The Cloud Security Alliance's research note describes how one compromised MCP server can pollute the shared context used by other servers and other sessions, a pattern it calls "supply chain via context". So that spread creates behavioral drift across multiple MCP components at once, and from there it opens a path to indirect data exfiltration that never touches the compromised server directly.

The ContextCrush technique, named in the research brief behind this reporting, shows how far the mechanism can be pushed. Even a read-only MCP server with narrow, seemingly harmless tools can serve as a delivery channel for attacker instructions, because what matters is not the server's capability scope but the fact that its output lands in context shared with everything else running in the session. A tool that can only read data can still carry an instruction that changes what the agent does with the data it was never supposed to touch.

Rather than fix the underlying vulnerability class, Sentry blocked a single payload string. That response left the broader technique intact, because the fix addressed one instance of the problem rather than the mechanism producing it. The protocol revision that took effect July 28, 2026, does not close this gap either: its rules govern which server an agent is allowed to connect to and what a user approved when a session opened, and the attacker in these cases never tried to circumvent either of those controls. The session stayed within its approved boundaries the entire time. The drift happened inside those boundaries, so a payload-specific patch could not have caught it, and neither could a connection-time rule.

Why conventional security tooling cannot see drift happening

The tools most enterprises already run were built to watch for discrete events, a file write, a network connection, a process launch, rather than the gradual semantic shift of what an agent believes its context means across a multi-step chain of tool calls. That mismatch is architectural, requiring a different approach than tuning the existing stack more aggressively.

EDR and XDR platforms, in particular, were designed for static APIs handling predictable, human-driven requests. MCP workflows look nothing like that: they involve agent-driven decisions, context that shifts from one call to the next, and chains of tools where each new interaction and each context switch opens a fresh path for exploitation. A security tool built to flag a known-bad process launch has no equivalent signal to flag when an agent's effective instructions have quietly changed mid-session.

Missing authentication compounds the lack of visibility before you even get to monitoring. UltraViolet Cyber's advisory, citing research from Trend Micro, found 492 MCP servers exposed to the internet with no authentication at all. If a session was never identity-verified in the first place, security teams have no baseline of approved intent to measure drift against. There is nothing to compare the current behavior to.

Even where authentication exists, attribution often does not. When tool calls carry no agent identity, you cannot tell AI agent activity apart from human activity in your own logs. Drift cannot be attributed to a specific agent, a specific session, or a specific moment of compromise if the logs treat every action as equally anonymous. It certainly cannot be caught while it is happening.

Shadow MCP usage removes the last piece of ground you have to stand on. If a security team does not know which MCP servers are active across the environment, it has no way to define what approved behavior even looks like, and drift away from an undefined baseline is, by definition, unmeasurable.

What detection at tool-call depth requires

You have to catch drift while sessions are still running, not reconstruct them afterward from logs, because by the time a session closes, whatever behavioral divergence occurred has already produced its effect. Detection has to happen at tool-call depth, in real time, on every call an agent makes.

That requires five controls operating simultaneously on each call: identity, confirming who or what is actually making the request; tool scope, confirming the call falls within what was approved; execution approval, confirming this specific action was sanctioned rather than merely permitted in general; argument and result inspection, checking whether the content crossing the context boundary in either direction carries injected instructions; and an attributed log tying the action to both the agent and the human behind it. Each of these controls maps directly onto a failure mode you saw described above. Identity and attribution are what the 492 unauthenticated servers and the invisible agent logs were missing. Argument and result inspection is what would have caught the unsanitized parameters Checkmarx documented and the instructions ContextCrush smuggled through a read-only server. Execution approval is what a rug pull defeats by changing a tool's behavior without triggering a new approval flow.

Identity has to be bound at the agent level, not just the user level. You need to know not just which human authorized a session but which specific agent, running in which environment, makes each individual call, so agent and human identity feed into a single access decision together. Secretless, short-lived credentials close the vector that long-lived API keys leave open: an agent's identity gets verified at the time of each call, and access can be revoked immediately if its runtime characteristics stop matching what policy expects, eliminating the window between credential theft and credential expiry that static keys leave wide open.

Result inspection, reading what a tool response actually contains before it is allowed into the context window, is the control that intercepts drift directly, at the exact point where the Sentry case showed a single blocked string was not enough. Argument inspection closes the same gap in the other direction, checking what the agent is sending out before it reaches a tool.

None of this works without a tamper-proof, attributed audit log. That log is the record that distinguishes genuine drift, a real behavioral change over the course of a session, from ordinary variation in how an agent completes a task, and it is what makes reconstructing an incident possible without depending on the agent's own account of what it did.

The NSA's guidance frames all of this as a matter of implementation rigor rather than protocol design. The protocol specification gives you no native defenses against tool poisoning, rug pull attacks, or cross-server tool shadowing, so you have to build and enforce that validation yourself, because MCP was not built to solve this problem on its own and the responsibility falls on whatever sits in front of it.

Implementing live session monitoring in enterprise platforms

The architecture most enterprise platforms are converging on is a proxy or gateway that sits between the agent and every MCP tool call, which makes enforcement and inspection possible without requiring any change to the individual MCP servers themselves. That design choice matters because it means security teams are not waiting on every tool vendor to rebuild for safety.

ServiceNow routes every agent action through its AI Control Tower, combining identity verification, permission scoping, and full auditability, with managed OAuth, enterprise audit trails, session management, and role-based tool packages available through its MCP Server Console. This implementation shows session-level control running at genuine enterprise scale.

Salesforce, which made MCP generally available in April 2026, attaches the authenticated user's name to every agent-made record change. That is a foundational attribution control: it makes drift visible in the audit record even when the agent is acting autonomously, because every change traces back to a specific authorized identity rather than disappearing into an anonymous agent action.

Palo Alto Networks' Secure AI Agents solution takes the identity broker approach, acting as the authorization server for MCP and proxying requests to the target server. That setup lets security teams discover which remote MCP servers are actually in use, when each last communicated, and enforce identity security controls across all of an organization's agent activity, giving teams visibility into shadow MCP servers that previously went untracked.

Aembit's deployment at a large investment firm demonstrates what secretless, session-scoped access looks like once it is running in production. Long-lived credentials that had been sitting in Claude and MCP server configurations were swapped out for short-lived, policy-scoped tokens issued per session, and every agent action got logged with attribution that distinguished human-initiated access from agent-initiated access. The same deployment enforces continuous verification rather than a one-time check at startup: the agent has to keep proving it is running in a trusted, unaltered environment throughout the session, and if that environment changes or its runtime characteristics stop matching policy, access can be revoked immediately. That is the specific control that addresses drift directly, by invalidating a session the moment the agent's actual state diverges from its approved baseline, rather than waiting to notice the divergence after the fact.

Security and usability move together in all of these deployments. People route around the governed path when it is harder to use than going around it, which is how shadow MCP usage takes hold in the first place. Snowflake's Cortex AI Gateway was built to proactively discover and prevent that kind of workaround, on the premise that the secure path only works if it is also the easy one.

The same per-session, policy-scoped credential model closes the exact vector demonstrated in the Drift and Salesforce OAuth token theft: tokens issued per session, scoped to policy, and revocable the moment session characteristics change, the same continuous-verification approach Aembit's investment firm deployment put into practice.

Across these implementations, one gap remains consistent. Most of what has been built governs what an agent is permitted to call and logs that the call happened. Far fewer platforms inspect the actual content of tool responses in flight, checking for injected instructions before that content enters the context window, which is the specific control that catches drift at the moment it is being delivered rather than after it has already shaped the agent's behavior. That gap is where the field as a whole currently stands, and it is the reason the compliance pressure around this problem keeps building. The Cloud Security Alliance's May 2026 research note frames MCP security as a supply chain and governance problem that needs forward-looking strategic guidance rather than reactive patching, and enterprises in regulated sectors carry direct exposure for as long as they cannot attribute and audit every action an agent takes on their behalf.