Drawn from a pooled corpus of production agent telemetry, nearly 28,000 sessions across 147 endpoints.
Part one of two: signals that don’t survive production.
What the pooled data shows from our research:
Sessions are long-lived and multi-purpose. One in eight exceeds 100 recorded activities, the largest held more than 50,000, and over 1,700 ran longer than a day, so there is no single "initial intent" to measure drift against.
A naive within-session drift rule floods the SOC. The most conservative such rule produced 0.40 benign alerts per endpoint per day, roughly 4,000 a day at 10,000 endpoints, and not one coincided with a real security finding.
The population it watches is the population that legitimately drifts. About a third of drift-scoreable sessions span multiple projects, up to five in a single session.
Behavioral baselining is the workable alternative. Two sessions from the same user are about twice as similar as sessions from different users (median 0.76 versus 0.35), creating a signal the within-session rule lacks.
Living in the traffic
The market for AI agent security is converging on a small set of signals that everyone seems to agree are the right things to watch. Two of them dominate the conversation: intent drift and the lethal trifecta. Both are intuitive, both make for a compelling slide, and both, when you take them out of the threat-modeling whiteboard and run them against real production traffic, generate so much noise that they can do more harm than good. This piece is the first in a two-part series on why. Here we take on intent drift; the second part turns to the lethal trifecta.
We know this because we live in that traffic. Working from a large pooled corpus of agent activity, we’ve watched how people actually use agents, how long their sessions run, how their objectives shift, and how often a perfectly benign workflow trips every wire a naive detection would set. The numbers in this piece are drawn from that aggregate pool: nearly 28,000 reconstructed agent sessions across an endpoint research group of 200+ endpoints, and close to 7,000 endpoint-days of production activity. What we have found is that the raw version of intent drift, applied as a detection rule, is not just imperfect. At enterprise scale it is actively counterproductive. It buries security operations teams in false positives and pushes organizations to make decisions that hurt the business without meaningfully reducing risk.
This is not an argument for throwing the concept away. Intent drift carries real signal at its core, and the threat model behind it is worth taking seriously. It is an argument for the rigor that must sit on top of it before it belongs anywhere near a system that drives detection and response. This piece walks through where intent drift breaks, why it breaks, and what we believe is the more defensible way to operationalize the underlying intuition.
The appeal of intent drift, and where it collapses
The idea behind intent drift is straightforward. You evaluate an agent's prompts, its outputs, and its actions over the course of a session, and you ask a simple question: has the objective the agent is working toward changed from where it started? You establish the initial intent, what the user or the agent set out to do, and then you watch for the session to wander somewhere it wasn't supposed to go. When it drifts, you alert.
On paper this is reasonable. It sounds like exactly the kind of behavioral awareness an agentic security tool should have. The problem shows up the moment you compare the model to how people actually consume these agents.
The first thing you notice in real data is that sessions run long, far longer than the mental model behind intent-drift detection assumes. Across the pooled corpus, we routinely see sessions containing thousands of activities, and in a meaningful number of cases tens of thousands. These are not sessions that live for an afternoon. They run for days, for weeks, and in some cases for months. Across nearly 28,000 sessions, one in eight exceeds 100 recorded activities, several hundred exceed 1,000, and the largest held more than 52,000. Session lifetimes match: more than 1,700 ran longer than a day, 456 longer than a week, and 25 longer than a month, the longest spanning 51 days. Users log in, spin up an agent instance, and then keep that single session alive as they move through completely different pieces of work.
When we speak to these users, we find they do this deliberately, and for a good reason: context is valuable, and they don't want to throw it away. A user builds up understanding inside one session, the agent has learned the shape of a problem, the relevant files, the prior decisions, and rather than start cold in a new session, the user pivots that accumulated context toward the next job. The conversation continues because continuing the conversation is where the leverage is.
Play that forward against an intent-drift rule and the outcome is obvious. A developer starts a session doing database work. Then they pivot to modifying backend application code in a separate part of the system. Then, in the same session, they move on to updating Kubernetes configurations. Then they come across a finding they realize might have been the cause of a series of system errors that have open tickets against them, so they have the agent pull those tickets and the related logs and run some analysis. The goal of the session is changing constantly, by design, because the human driving it is using one long-lived context to accomplish several unrelated things. What, exactly, are you baselining "intent" against here? The first task? The most recent one? A session like this has no single intent to drift away from.
This is measurable. Among sessions large enough for a drift detector to bother scoring, roughly a third span more than one project directory, up to five distinct projects in a single session. The population a drift detector watches most closely is precisely the population that legitimately drifts.
These are real usage patterns, seen at scale. And they lead directly to the practical failure mode: the most conservative literal drift rule we could write, alert when a session switches project context mid-stream, produced 0.40 benign alerts per endpoint per day across nearly 7,000 endpoint-days of production traffic, and not one coincided with a recorded security finding. That works out to roughly 120 false positives a day at 300 endpoints, about 4,000 at 10,000, and around 40,000 at 100,000. "Several false positives per day even in a modest environment" turns out to be conservative by an order of magnitude. Every one of those alerts lands on a security analyst who has to stop, investigate what the "drift" actually was, and determine whether anything real happened, only to discover again and again that a user simply didn't feel like opening a new session, or was actively getting value from carrying context across objectives.
That is the business cost, and it is not abstract. Security operations capacity is finite and expensive. A signal that reliably produces benign alerts at scale doesn't just fail to add security value; it consumes the analyst hours you needed for the AI alerts that matter, and it trains your team to treat the whole category as noise. False positives are not a cosmetic problem. They are a direct tax on your ability to detect the true positives sitting next to them.
Intent drift is often a governance question wearing a detection costume
There is a more productive way to think about some of what intent drift is trying to catch, and it starts by admitting that a lot of these concerns are really governance decisions, not detection problems.
Take the exploratory example again. There may be legitimate reasons you don't want a user exploring an open-source repository and then, in the same session, turning the agent loose on your internal repository. The content the agent ingested from the public project could poison the session, a prompt injection or a poisoned artifact picked up while reading external code could carry over and cause problems once the agent is operating against private systems. That is a real threat model. Similarly, you may have a hard rule that if a session begins working with one customer's data, it should not go on to commingle another customer's data in the same session. Also reasonable.
But notice what just happened. We stopped treating this as "detect and alert on drift" and started treating it as "decide, in advance, what we will and won't allow." That is a governance posture. And we believe that, for a large share of what intent drift is reaching for, governance is simply the better frame. If you are worried about a specific dangerous transition, don't wait for it to happen and then generate an alert you have to chase, write a policy that prevents the transition in the first place.
Even here, though, you have to stay honest about usage patterns, because the same behavior that looks risky in one light is genuinely valuable in another. Users tell us, and we see, that cross-context work inside a single session is often exactly where the value is. Someone pulls meeting minutes and context from one client engagement, and then realizes the insight applies to another customer they're working with, so they bring that second customer's context into the same session to act on it. That is commingling data and it may also be the most useful thing that user does all week.
So the governance decision is real, and it is a decision, one with a cost the business will feel and push back on. The point is not that commingling is always wrong. The point is that if your organization decides it is unacceptable, the correct instrument is a preventative governance control enforced on the front end, not a detection rule that floods your SOC with alerts about users who are just trying to get their jobs done inside one session. Whether or not to allow the pattern is a separate conversation with the business. But operationally, framing it as governance means you make a clean, deliberate choice and enforce it, rather than manufacturing false positives that bog your response team down.
When a transition is genuinely off-limits, Manifold enforces it up front rather than leaving it for your SOC to chase after the fact. Talk to Manifold.
What to actually do: rigor on top of the intuition
So do we throw intent drift away? That would be an overreaction. It carries a genuine kernel of truth and points at a threat model worth caring about. Intent drift is asking a real question: as a session unfolds, how is it changing, and how is it behaving? The failure is not in the question. The failure is in stopping at the simplistic classification, did this one session start in one place and end in another, and shipping it as a feature. The work is in the rigor you apply beyond the label.
Detect against behavioral baselines, not within-session drift
The detection story needs something more nuanced than "this session started one way and ended another." What you actually want is to profile the normal behavioral patterns of an agent and of the user's use of that agent, and then look for anomalies against that baseline.
Rather than trying to baseline drift within a session, asking whether the session started in one place and ended in another, which we have established is a losing game, study how sessions for a given agent and user usually go, over time. Build the historical behavioral baseline. Then, in subsequent sessions, compare the new session's patterns against the historical ones and look for anomalies. The unit of analysis moves from "did this one session wander?" (which is almost always yes, and almost always fine) to "is this session behaving unlike the way this agent's sessions normally behave?" (which is a question with actual signal in the answer).
The data backs this up. Across the pool, sessions from the same user are consistently more alike, in which tools they use and how they use them, than sessions from different users: two sessions from the same user are about twice as similar as two from different users, a median tool-mix similarity of 0.76 versus 0.35. The per-user, per-agent baseline carries exactly the discriminating signal that within-session drift lacks.
And when it's really governance, prevent, don't detect
Finally, close the loop we opened earlier. A good deal of what people try to catch with intent drift is not detection at all, it is governance. Don't spend your team's time creating false-positive detections for things that would be better handled as enforcement policy on the front end and broadly communicated to the organization as policy violations (i.e., users should not expect it to be blocked if they try).
If your organization genuinely doesn't want users or agents commingling customer data within a single session, or running a marketing job and a coding job in the same session, then don't build a detection that generates an alert every time it happens and ships it to your SOC. Write the governance rule and make sure you have a platform that can enforce it, prevent the behavior from happening in the first place. You will likely face pushback from the business and from users who derive real value from these patterns, and that is a legitimate conversation to have. But it is a governance conversation. Operationally, deciding "we will not enable this, and we will enforce that preventatively" is far healthier than authoring detection rules that turn into a stream of false positives your security operations team has to wade through.
The bottom line
Intent drift was born from good instincts. It encodes a threat model that is worth understanding, and at the theoretical level it belongs in any serious conversation about agentic risk. But intuition is not a control. Applied naively, as a literal within-session detection rule, it shatters against the reality of how people use agents: long-lived, context-rich, multi-objective sessions in which shifting goals are the normal texture of legitimate work, not the exception.
At scale, the consequences are concrete and they are a business problem, not just a security one. A naive drift rule floods security operations with false positives, a measured 0.40 per endpoint per day, roughly 4,000 a day at 10,000 endpoints, none of them tied to a real finding, the single most expensive and demoralizing failure mode a detection program can have, while surfacing almost nothing real.
The path forward is not to discard the intuition but to do the harder work on top of it: baseline agent and user behavior over time and detect anomalies against it rather than firing on the fact that a session moved; and move the genuinely governance-shaped concerns, like commingling customer data in a single session, to preventative enforcement rather than after-the-fact alerting. That is the difference between a signal that sounds good in a threat model and a control that actually holds up in production, which is the only place that counts.
In the second part of this series we turn to the lethal trifecta. It fails in a different way, as a risk label rather than a session-level rule, but for the same underlying reason: it describes something true about agents in the abstract, then falls apart the moment it meets how agents are actually used.
Manifold monitors agent behavior at runtime. We baseline how each agent and user normally behaves, then flag the sessions that break from it rather than alerting every time a long-lived session changes objective. Talk to Manifold.
Latest articles
