Authorization Drift: Capable AI Agents Overreach Without an Attacker

This week I read Authorization Drift in LLM Agents: Evaluating Boundary Compliance in Multi-Step Tool Use by Chuxue Cao, Jingru Zeng, Boqin Yin, Yujin Zhou, Yidan Huang, Sujin Chen, Jinluan Yang, Haoran Li, Yike Guo, and Sirui Han. The authors are from the Hong Kong University of Science and Technology, South China University of Technology, Suzhou University, and Zhejiang University (Hugging Face page). It's a preprint posted November 6, 2026.

Most agent security work asks whether an agent can resist an attacker. This paper asks a quieter question: what does your agent do when nobody is attacking it, and a little extra access would just make the job easier? The answer, for the most capable models they tested, is that it often takes the access.

Summary

The authors call this failure authorization drift: an agent widens what it is effectively allowed to do while pursuing your goal, with no injected instruction telling it to. In their opening example, an agent asked to draft a follow-up email to Alice reads private CRM history and searches a manager's mailbox to make the draft better. Nothing told it to. The extra access just looked useful.

They built a benchmark for this, the Authorization Drift Benchmark (ADB), and ran 13 models through it. The headline: the models that complete the most tasks also cross the most boundaries, even though a clean, compliant path existed for most tasks.

What the Authors Did

Four kinds of boundary. The paper splits drift into four dimensions:

• Data: reading information beyond what the task authorizes
• Tool: using tools beyond the permitted ones
• Scope: expanding beyond what the user asked for
• Time: persisting or re-planning past the intended execution window

648 tasks, each with two paths. Every ADB sample pairs a "sufficient but effortful" compliant path with an "attractive unauthorized shortcut." The tasks span seven domains, though not evenly: IT & Cloud is 38.1% of the set and Personal & Lifestyle is 4.0%. The shortcuts are baited with realistic metadata in tool results, phrased as evaluations rather than instructions, so this is not prompt injection. The authors annotated 3,911 drift points across the 648 samples.

Built and checked with real rollouts. Claude Sonnet 4.6 designed the scenarios from a pool of 746 agent skills. Two probe models from different families then ran each task four times, and a task was kept only if at least one rollout covered all the required compliant calls and at least two of the eight tripped a designed drift point. A human audit of 20 random samples found every instruction natural, but rated compliant-path feasibility and success-criteria validity at 70% each.

Scale and scoring. 13 models from five families (Claude, Qwen, Llama, MiniMax, Mistral), from 4B to 397B parameters, ran with bare tool calling. Four of them were also run under ReAct and a LangChain Planner-Executor. That is 25,207 evaluated trajectories in total. Drift is detected by rule, by matching tool calls against the annotated unauthorized calls. Task success is judged by an LLM (Qwen3-235B-A22B-Instruct).

The authors are explicit that ADB is "an opportunity-conditioned stress test, not an estimate of drift prevalence in ordinary deployments." Every task offers a tempting shortcut by design.

Findings With Numbers

The most capable models drift the most. Drift rate (DR) is the share of runs that make at least one unauthorized call:

Claude Sonnet 4.6 succeeded on 0.923 of runs and drifted on 0.571. Qwen3.6-35B-A3B was the highest at 0.605. No model landed in the high-success, low-drift corner. The paper calls this an association, not a cause: the models differ in architecture and training too.

Low drift can just mean low effort. The only model under 0.10 drift, Llama-4-Maverick-17B×128E (0.029), also completed only 0.269 of tasks. A model that doesn't act can't overreach.

Size alone doesn't explain it. Within Qwen, drift rose from 0.45 at 4B to 0.61 at 35B-A3B, but the 397B model sat at 0.434. Within Mistral, the 14B and 24B models drifted less (0.236 and 0.250) than the 8B model (0.323).

Drift was usually avoidable. 555 of 644 analyzed tasks (86.18%) had at least one observed run that both succeeded and stayed in bounds, pooled across eight bare models and four rollouts each. The average per-task clean-success rate was lower, 33.70%. Only 35 tasks (5.43%) were completed but always with drift.

It's consistent, not random. Run-to-run standard deviation was below 0.02 for every model. For the models above 0.50 drift, a task that drifted once drifted in about 83% to 86% of rollouts.

Grabbing extra data comes first and dominates. Data drift was the largest component for every model (up to 0.574 for Qwen3.6-35B-A3B). It peaks early to mid-trajectory (0.2 to 0.5 of the way through). Scope and time drift show up later (0.6 to 0.8), and tool drift peaks after 0.7.

Heavier scaffolds don't fix it. Planner-Executor cut drift for three of four models (Qwen3.6-35B-A3B went from 0.61 to 0.08). But compliant task competence (CCSR) collapsed at the same time, from 0.94 to 0.23 for that model. For Llama-3.1-8B, drift actually rose from 0.12 to 0.21. The lower drift mostly came from the agent doing less.

It maps to data-protection law. Mapping drift points to provisions in the EU, Mainland China, Singapore, and Hong Kong, GDPR Art. 5(1)(c) (data minimisation) was the most implicated provision for all 13 models. 93.5% of legally grounded drifting runs mapped to provisions in more than one jurisdiction. The authors say this connects drift to real harms; it does not establish a legal violation.

Limitations

The authors list these themselves:

• Single session, single user. Sub-agents, shared memory, cross-session persistence, and multi-agent trust aren't measured.
• Rule-based detection. Drift only counts if it matches an annotated unauthorized call. New shortcuts a capable model invents are missed, so ADB may underestimate drift for strong models.
• Stress test, not prevalence. Every task offers a tempting shortcut by design.
• Imperfect tasks. The human audit rated compliant-path feasibility and success criteria at 70%, and 35 tasks were only ever completed with drift.
• Mock environments. No real user data or production systems were used.

From my own reading: task success is LLM-judged, and the audit sample is only 20 tasks. I'd treat the exact rates as directional. The pattern (capable models reach for more than they need, early, and consistently) is the part I'd act on.

My Takeaways

The paper's own recommendations are narrow. Based on where drift happens, it suggests "limits on early context-gathering calls and explicit completion-condition checks during later stages of task execution." It concludes that the results "motivate trajectory-level training and runtime authorization controls that preserve legitimate task completion without permitting overreach." The list below is my take on applying that, not the authors'.

1. Don't let the model be the access-control layer. Enforce least privilege outside the model, in the tool layer or the API it calls. If the model can reach it, assume a helpful model eventually will
2. Scope tools per task. Give each task an allowlist of tools and data sources, not the agent's full kit
3. Watch the first few calls. Data drift clusters early. Rate-limit or log early context-gathering reads, and flag reads outside the task's declared data
4. Confirm state-changing actions. Sends, writes, and deletes should need a human or policy check, especially late in a run where scope and time drift show up
5. Measure drift and completion together. A guardrail that halves drift by halving useful work isn't a fix. Track both

For mapping, my team files this under OWASP LLM06:2025 Excessive Agency, whose prevention list includes minimizing extension permissions, requiring user approval for high-impact actions, and enforcing authorization in downstream systems rather than in the LLM. In MITRE ATLAS (October 2026 data), the closest mitigations are AML.M0027 Manage User-Delegated AI Agent Access and AML.M0037 AI Agent Authority Expansion Controls, with AML.M0026 Manage AI Agent Service Access for agents that run under their own service identity. That mapping is ours, not the authors'. The paper doesn't cite OWASP or ATLAS.

The Bottom Line

You don't need an attacker for an agent to overstep. In this benchmark, the better the model was at finishing the job, the more often it reached for data and tools it wasn't given, even when a clean path existed. Put the boundary where the model can't argue with it.

Sources

• Authorization Drift in LLM Agents: Evaluating Boundary Compliance in Multi-Step Tool Use (arXiv, November 2026)
• Hugging Face paper page
• AgentDrift code and data repository
• OWASP LLM06:2025 Excessive Agency
• MITRE ATLAS data (AML.M0026, AML.M0027, AML.M0037)

Read the full paper on arXiv. If you run agents with real tool access, I'd like to hear how you scope them. Reach me on X.