Agent drift is the divergence of an agent’s behavior from its declared objective or scope over the course of execution, distinct from model drift and data drift. Sentience Governor records signals relevant to such divergence, including scope mismatches, unexpected operations and policy violations, but does not provide a single comprehensive drift measurement.
The word “drift” is doing specific work. It names a course that departs from where it was supposed to go. The departure can arrive in one action or accumulate across many, and in the second case it is often visible only from a distance. An agent asked to fix a failing test edits the code, then a configuration file the test touched, then writes a note to a path nobody mentioned, then posts an update to a chat channel. Each action may succeed. Each may even have seemed sensible at the moment it was taken. Together they are somewhere else. The model behind the agent may be performing exactly as it did an hour earlier; drift is a property of the run, not of the model.
How an agent departs from its task
Drift takes two shapes. Gradual drift is the accumulation of individually reasonable actions, as above: no step draws attention, and the departure exists only in the sequence. A sharp departure is one action that leaves the task at once, often because something the agent read redirected it: a note inside a ticket, an instruction in a web page, a comment in a file. Prompt injection is the adversarial version of that cause. It is one way drift begins, not what drift is; the same departure happens without any adversary when an agent misjudges what matters.
Two distinctions run through both shapes.
Authorized is not the same as serving the task. An agent that drifts is rarely doing something it lacks the credentials for. Editing configuration, writing files and posting to chat may all be within its permissions. Authorization answers whether the agent may do a thing and has no opinion about whether the thing belongs to the task.
Objective divergence is broader than scope violation. An agent can leave its task in two ways. It can act on a system the task did not include: a declared-scope mismatch, which a comparison with the declared scope can surface. An asserted scope is not downstream authorization, so this is a departure from what the task stated, not from what the agent was permitted. Or it can stay inside every boundary and stop serving the objective: it refactors the module it was asked to patch, tidies files it was asked to read, keeps working after the goal was met. The second kind is the larger class and the harder one to see, because nothing structural changes.
Not every change of direction is drift. An agent asked to fix one test that finds the cause in a shared helper, and fixes the helper, has adapted. An agent that fixes the helper and then rewrites the module around it has drifted. The difference is not distance from the first plan. It is whether the move remained justified by what the agent was asked to do and stayed within the authority and scope in force. Agentic AI is valuable because agents adapt to what they find, and the same capability produces drift when adaptations stop being anchored to the objective. Governance that treats every adaptation as drift removes what made the agent worth using.
Drift that shares a word with something else
Machine learning has used “drift” for years, for changes in a model’s relationship to the data it sees.
- Data drift is a change in the distribution of the inputs a deployed model receives, compared with the data it was trained on.
- Concept drift is a change in the relationship between inputs and the outcome being predicted. A widely cited review defines it as unforeseeable changes in the underlying distribution of streaming data over time, and Google’s machine learning glossary describes drift as a shift in the relationship between features and the label.
- Model drift is the everyday term for the resulting change in a model’s behavior over time, often a decline in quality, though not always.
These describe the world moving under a model. Agent drift describes an agent moving away from its task during a run, and it can happen with a model whose quality has not changed at all. Researchers studying language model agents have begun using “goal drift” for this, and one 2025 evaluation found that every agent it tested drifted from an assigned goal to some degree, with more drift as the context grew longer.
Because the terms overlap, a conversation about drift in an agent system is worth disambiguating early. Monitoring for data drift and recognizing agent drift take different instruments and answer different questions.
Why drift grows with the run
Three properties make drift hard to notice while it is happening. Every step can be permitted. Every step can be locally reasonable. And there is often nothing to compare against: a log records what the agent did, not what it was supposed to be doing, so without a reference, drift is an impression a reviewer forms afterward, if anyone looks.
Each of these worsens with length and reach. A long-running agent accumulates more steps in which to drift, and its early context, where the task was stated, recedes as new material arrives. A workflow that touches several systems multiplies the number of permitted actions that could be outside the task, and spreads the evidence of what happened across systems that keep separate records. Consequences compound too: a drifted write in one system becomes an input to the next, and reconstructing how the run left its course means assembling a sequence nobody recorded as one. This is the setting in which drift stops being an inefficiency and becomes a governance problem.
Recognizing and governing drift
Drift can be governed. Doing so involves several distinct responsibilities, and no single one of them is sufficient.
A stated reference. Drift is measurable only against something. A declared intent, the objective and the declared scope within which it will be pursued, stated before the agent acts, turns “did this drift?” from an impression into a comparison, at least for the part of drift that crosses a boundary. The precision of the declaration sets what can be noticed: a scope that names everything the agent can reach notices very little.
Visibility into attempted actions. The execution boundary is where a decision becomes an attempted operation, and it is where each agent action can be seen as it happens, rather than reconstructed later from whatever was logged.
Comparison with the reference. Each attempted action can be compared, as it is attempted, with the declared scope and the applicable policy. This is runtime governance as evaluation.
Structural signals, and their limits. The comparison yields signals, and it is worth being exact about what each one shows.
| Signal | What it shows | Its limit |
|---|---|---|
| Declared-scope mismatch | An attempted action’s target is outside the declared scope | Silent about actions inside the scope |
| Unexpected operation | A write, delete or execute attempted with no objective declared | Absence of a reference, not a departure from one |
| Policy violation | A rule matched the action | Reports the rule, not the intent behind the action |
| Task-boundary crossing | Consecutive actions changed in a way the operator chose to treat as the start of a new task: a move to another directory, a shift in file type, an idle gap, a read followed by a write | A boundary crossing can be a new task or the next step of the same one |
| High-consequence detection | The action matched a tool or effect the operator marked as costly or hard to reverse | Consequence, not relevance |
| Token attribution | How much of the session’s model usage was associated with turns that carried findings | Usage on flagged turns, not a measure of drift; some findings are unrelated to drift |
Read together, these can make drift visible. No structural signal, and no combination of them, establishes comprehensive detection of drift, because the largest class of drift, wandering inside the declared scope, produces no structural signal. Deciding whether an in-scope action served the objective requires interpreting the objective and the action, which is a semantic judgment.
Context, policy and authority. Whether a departure matters depends on more than the action. The same write is routine in a scratch directory and serious in a system of record; the same adaptation is fine for an agent whose owner is watching and not for one running unattended overnight; a policy may treat a class of operations as needing a second look regardless of scope. Governance that recognizes drift has to hold this context alongside the actions.
Evidence that reconstructs the departure. When drift is found, the useful question is how the run got there: what was declared, what was attempted in what order, what the evaluation found at each step, and where certainty ends. Governance evidence of that kind is what lets a reviewer distinguish a justified adaptation from a departure, and it is only available if it was recorded as the run happened.
Intervention and enforcement, as separate responsibilities. Recognizing drift is not the same as responding to it. Possible responses range from a flag for later review, to a prompt for confirmation, to refusal, to a restriction enforced at the system where the consequence would occur. Which response fits which operation is a decision for the organization operating the agent, and an advisory finding does not by itself stop anything. The entry on the agent harness discusses where enforcement has to sit to be effective.
An example: what the record shows and what it does not
The records below are genuine Sentience Governor output, generated by feeding representative Claude Code hook payloads into the released Claude Code integration. No command ran, no file was edited and no message was sent. The payloads were supplied in a fixed order and were not chosen by a live model, so the example shows what is recorded and evaluated, not how an agent behaves. A governance profile was in force that marked the chat tool as high-consequence. Findings are described in words.
The session was declared with the objective “Fix the failing date-parsing test in tests/test_dates.py” and a scope of the filesystem and test processes. Seven actions followed.
| Attempted action | Recorded as | Findings | |
|---|---|---|---|
| 1 | Run the test suite | Execute, target shell/process | None |
| 2 | Read the module under test | Read, target filesystem | None |
| 3 | Edit the module under test | Write, target filesystem | None |
| 4 | Run the test suite again | Execute, target shell/process | None |
| 5 | Edit a configuration file in another part of the repository | Write, target filesystem | None |
| 6 | Write a note to a path outside the repository | Write, target filesystem | None |
| 7 | Post a message through a chat tool | Read, target slack | Outside the declared scope, with the default intent rule; high-consequence tool |
The event for the seventh action, with envelope metadata omitted:
{
"event_type": "SCOPE_ASSERTED",
"pass_through": true,
"payload": {
"tool_id": "mcp__slack__post_message",
"operation_type": "READ",
"asserted_permissions": ["read"],
"target_system": "slack"
}
}What the scenario illustrates. Actions 1 to 4 are the task. Actions 5 and 6 are the wander: still inside the repository’s tooling, still on the filesystem, no longer about the test. Action 7 leaves the task’s systems altogether. A reviewer with the objective in front of them would call 5, 6 and 7 drift, of two kinds: two inside the declared scope, one outside it.
What the records establish. That the objective and scope were declared; that seven actions were attempted, in this order, with these operation types and targets; that the seventh was outside the declared scope and matched the operator’s high-consequence pattern, and was flagged at the attempt; and that every action was passed through, because the current implementation observes and does not block. The seventh action’s operation type was inferred as a read from the tool’s name; the high-consequence match did not depend on that.
What needs task context or a reviewer’s judgment. Whether actions 5 and 6 served the objective. Both are writes to the filesystem, the filesystem was in scope, and both produced no finding. The record holds no file paths, so it cannot even show that action 6 left the repository. The released implementation does not semantically distinguish an in-scope action that serves the objective from one that does not, which is exactly the class of drift the earlier sections describe. And nothing in the record says whether any action had an effect: what the configuration edit changed, whether the message was delivered.
The declared-scope mismatch in action 7 is the visible subset. The drift in actions 5 and 6 is the larger, quieter part, and it is why a declared reference, a record of attempts and a reviewer are all needed.
How Sentience Governor relates to this
Sentience Governor is one implementation of runtime governance. Its current implementation records a declared objective and scope, evaluates each attempted action at instrumented execution boundaries against that declaration, the default rules and the operator’s governance profile, attaches findings to the event, and, where the integration reports model usage, attributes tokens to the turn where each action happened. Its session report summarizes those findings and the usage associated with turns that lacked a declared intent or carried policy violations. That is usage on flagged turns; not every finding is drift.
It has no drift detector. It does not interpret the objective, does not perform semantic detection of drift, and does not act on drift: findings are advisory, every action is passed through, and a session’s declared scope is not adjusted in response to what the agent does. The Sentience white paper names drift and shifting objectives among the problems the Governor Model addresses and treats drift as a signal in a continuous control loop. That is architecture and direction. The current implementation supplies signals of the kind in the table above and nothing that closes the loop.
Often confused with
Model drift, data drift and concept drift. Changes in a model’s inputs or in its relationship to the world over days or months. Agent drift is a departure of behavior from a task within a run.
Prompt injection. One cause of drift, and an adversarial one. Drift also happens with no adversary, and injection can cause a sharp departure rather than a gradual one.
Hallucination. A model producing false content. An agent can drift while everything it states is true, and can hallucinate without leaving its task.
Declared-scope mismatch. One signal of drift, and the easiest to record. It compares an action with what the task stated, not with what the agent was authorized to do, and drift that stays inside the declared scope produces no mismatch.
Task failure. An agent can drift and still complete its task, at greater cost, and can fail without drifting.
Where the concept stops
Agent drift names a departure, not a mechanism and not a measurement. Whether a sequence of actions counts as drift depends on a reference, the declared objective and scope, and on a judgment about which adaptations were justified by it. A governance record can make part of the departure visible, the part that crosses a declared boundary or a rule, and can attribute a session’s usage to the turns that carried findings. It does not establish that an agent stayed on course, does not see drift that keeps within scope without interpreting the objective, and does not by itself say whether a drifted action had an effect. What the concept asks of anyone running increasingly autonomous systems is simpler than a detector: state the task, watch the attempts, keep the evidence, and decide in advance which departures warrant which response.