Privilege Drift / Scope Sprawl

The gradual, seemingly-reasonable accumulation of an AI agent's permissions beyond its original scope and purpose over time — each individual grant justified in isolation, but the aggregate expanding the attack surface and violating least privilege; amplified when multiple agents share resources in a multi-agent system.

Also known as: privilege drift, scope sprawl, permission accumulation, over-permissioning, permission creep

Part of: Agent Governance (Internal)

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (5)

• Operating Mode as Runtime State: A Contract for Enterprise Shreshta Shyamsundar and Chidambaram GS · 2026-09-11 source ↗ Reader 🖥️
  Because enterprise AI agents infer whether they're operating under normal, incident, or recovery conditions from prompts and accumulated context rather than receiving it as authoritative input, temporary emergency exceptions quietly harden into permanent runtime behavior ('exception drift') — the fix is to make organizational operating mode a first-class, scoped, time-bound runtime construct, injected alongside identity and permissions, whose closure the platform itself can verify rather than merely document.
• Beyond Zero: Google Publishes Successor to BeyondCorp Renato Losio · 2026-09-05 source ↗ Reader 🖥️
  Google's newly published Beyond Zero model proposes extending Zero Trust from static, application-level, human-speed access control to continuous, resource- and action-level authorization combining static policy with dynamic AI-driven decisions for both humans and AI agents — an aspirational architecture that early practitioner and community reaction meets with skepticism about its maturity, complexity, and the wisdom of non-deterministic access controls.
• What Happens After Every Company Becomes a Data Company? Art Anthony · 2026-07-28 source ↗ Reader 🖥️
  As every company becomes a data company and AI agents begin consuming that data autonomously, organizations must abandon convenience-first identity patterns — broad SSO, single super-profiles, session-long OAuth grants — in favor of a Zero-Trust posture of least-privilege, just-in-time, minimally-scoped, continuously-evaluated access for humans and agents alike, treating themselves as active data stewards rather than passive collectors.
• 5 Signs That Authenticated API Traffic Is Actually Malicious J Simpson · 2026-07-21 source ↗ Reader 🖥️
  Because most API attacks now come through fully authenticated sessions rather than broken authentication, and valid credentials make an attacker's requests indistinguishable from legitimate traffic at the authentication layer, API security must shift from gating access at login to continuously profiling authenticated users' behavior and flagging deviations — unusual resource requests, access patterns, request volume, bulk actions, and error rates — since these behavioral signals, not credentials, are where malicious authenticated traffic actually reveals itself.
• How to Manage Privilege Drift in Multi-Agent Systems Janet Wagner · 2026-07-14 source ↗ Reader 🖥️
  Privilege drift — the incremental, individually-reasonable accumulation of an AI agent's permissions beyond its original purpose — multiplies across the agents, shared resources, and communication channels of a multi-agent system into an attack surface no single decision ever consciously approved, and it can only be managed (never eliminated) through continuous cross-agent inventory, runtime-enforced least privilege, just-in-time access, and behavioral monitoring.

Propositions touching this concept (3)

By publication month, oldest first (extraction month when no publication date is known).

2026-07

• explicitdevelopedPrivilege drift is the accumulation of an agent's permissions over time beyond what was originally granted and without reference to the agent's original purpose.
  How to Manage Privilege Drift in Multi-Agent Systems · p1
• explicitMulti-agent systems amplify privilege drift far beyond a single agent's exposure because permissions multiply across agents, shared resources, and inter-agent communication.
  How to Manage Privilege Drift in Multi-Agent Systems · p2
• explicitService accounts are over-privileged by default at startup and their permissions are rarely reduced afterward, so privilege drift compounds a pre-existing structural over-permissioning.
  How to Manage Privilege Drift in Multi-Agent Systems · p4

Open gaps (10)

• incompleteThe article never addresses the cold-start problem: none of the five signs work without an established behavioral baseline, and it says nothing about how long a baseline takes to become reliable, what happens during that window for new employees, new customers, or newly provisioned service/agent accounts, or how organizations should treat authenticated traffic from identities with no meaningful history yet.
  5 Signs That Authenticated API Traffic Is Actually Malicious — read next: Literature on user/entity behavior analytics (UEBA) cold-start handling, and on non-human/workload identity onboarding (service accounts, AI agent credentials) for how baseline-dependent anomaly detection copes with brand-new identities.
• incompleteThe piece treats each of the five signs largely in isolation and never discusses false-positive cost, alert fatigue, or who triages the resulting flags — for instance, a legitimate quarter-end bulk payroll export, a sales team doing a real end-of-quarter customer-list pull, or an employee traveling and logging in from an unusual country would all trip these detectors, and the article offers no discussion of tuning, escalation policy, or the operational burden this creates for a security team.
  5 Signs That Authenticated API Traffic Is Actually Malicious — read next: SOC/SIEM alert-fatigue research, and case studies on tuning UEBA/anomaly systems to acceptable false-positive rates in production.
• incompleteThe single supporting statistic (95% of API attacks come from authenticated sources) is sourced from a single vendor's (Salt Security) self-published report, and the article does not interrogate the report's methodology, sample, or definition of 'API attack' — nor cross-check it against any independent source.
  5 Signs That Authenticated API Traffic Is Actually Malicious — read next: Read extract-mcp-api-sprawl (which the corpus already flags as a model of independently-sourced adoption/security statistics in the adjacent MCP-governance space) as a comparison point, and look for non-vendor-sourced API attack telemetry (e.g. OWASP, academic breach studies) to corroborate or complicate the 95% figure.
• incompleteThe new MCP access controls are described only as governing 'which agents can run and what systems they can reach' — no detail is given on the underlying model (allow-lists, roles, least-privilege enforcement, drift monitoring over time), leaving open how they specifically prevent permission creep as more agent types (Dependency Scanning, Security Review, Duo CLI, Custom Flows) run inside the same platform.
  GitLab 19.2 Puts AI Agents to Work on the Security Backlog — read next: Read alongside the corpus's privilege-drift material on multi-agent systems (permissions accumulating beyond original scope, amplified when multiple agents share resources) to assess whether GitLab's access-control model is a structural mitigation or just a policy statement.
• uninformedThe article doesn't engage at all with how Beyond Zero's continuous, per-action authorization model would interact with, replace, or duplicate the just-in-time token issuance and platform-wide permission-inventory approaches already covered elsewhere in the corpus's privilege-drift and agent-governance material, even though both are solving the overlapping problem of bounding what an agent can do at any given moment.
  Beyond Zero: Google Publishes Successor to BeyondCorp — read next: Read the privilege-drift-in-multi-agent-systems and AWS Loom governance extractions side by side with Beyond Zero's five principles to map where the mechanisms converge or diverge.
• incompleteNo treatment of who authors and maintains the mapping between an incident-management system's narrative state (tickets, severity levels) and the proposed six-field runtime contract (mode/scope/authority/expiry/status) — a translation-and-ownership gap structurally identical to one already flagged in the corpus for privilege-drift's permission inventory.
  Operating Mode as Runtime State: A Contract for Enterprise — read next: Platform-as-product / internal-platform-adoption literature on what keeps a shared governance artifact from decaying; read directly against extract-privilege-drift-multi-agent-systems#g1 (who owns the platform-wide permission inventory as it decays).
• incompleteFormalizing exception declaration into a lightweight schema could itself be gamed: an actor under pressure could declare an overly broad scope or a soft, rolling expiry ("expires: incident-close" where closure is never formally triggered) to durably legitimize what is functionally still an ad hoc workaround. The article never asks whether making exceptions easy to declare could increase their volume or scope rather than shrink drift.
  Operating Mode as Runtime State: A Contract for Enterprise — read next: Goodhart's-law / gaming-the-control literature; compare with the corpus's privilege-drift material on JIT tokens being requested more liberally once the friction to request them drops.
• illogicalThe article insists memory should never decide whether an accommodation is 'still authorized' and that authoritative runtime state must win when the two disagree, yet allows expiry to be tied to a soft condition like 'incident-close' — a status that itself has to be recorded and read from somewhere, often by human judgment. If that status update is delayed, inferred, or manually entered, the 'authoritative state' is not obviously more reliable than the informal traces it's meant to replace; the piece never explains what structurally distinguishes a trustworthy 'incident-close' status from the kind of soft, human-mediated signal it dismisses when it comes from memory or prompts.
  Operating Mode as Runtime State: A Contract for Enterprise — read next: Distinguish structurally-guaranteed authority (a hard-timestamped, cryptographically scoped token) from merely relocated human judgment (a status field someone updates); read against the piece's own JIT/short-lived-token material and against extract-privilege-drift-multi-agent-systems on runtime enforcement.
• uninformedThe article names feature flags (LaunchDarkly), RBAC, and tenancy metadata as adjacent-but-distinct patterns, and cites ITIL/ISO change and incident frameworks, but never engages existing runtime policy-engine literature (OPA/Rego, AWS Cedar) — which the corpus's own privilege-drift piece names as the concrete tooling category for 'enforce at runtime, at the point of invocation.' Operating mode as proposed here is architecturally a policy-as-code problem (a context attribute gating an authorization decision), and the piece doesn't connect it to that existing ecosystem.
  Operating Mode as Runtime State: A Contract for Enterprise — read next: Policy-as-code literature (OPA, Cedar) for how a 'mode' attribute would actually be evaluated as part of an authorization decision at tool-invocation time; read against extract-privilege-drift-multi-agent-systems#g4.
• incompleteThe article's own central provocative question — 'how much data is too much data' — is posed rhetorically and never answered; no threshold, framework, or decision procedure is offered for organizations trying to operationalize 'minimization' in practice.
  What Happens After Every Company Becomes a Data Company? — read next: Data-minimization-by-design frameworks (e.g. NIST privacy engineering, GDPR Art. 5 guidance) that attempt to convert the principle into an auditable practice.