Agentic Permission Creep: Permissions Don't Start Excessive — They Accumulate
You authorized the agent to read your project files. Twenty minutes later, it has written to production and consumed three API keys from context. It still holds an elevated database token from a subtask that finished ten minutes ago. No single permission was unreasonable. The sequence was.
OWASP LLM06:2025 treats excessive agency as a design flaw present at session start. The actual failure is structural and temporal: agentic sessions have no permission revocation primitive. Each justified task completion is simultaneously a capability expansion event. The authorization state at session end is a monotonic accumulation that no standard RBAC or ABAC model controls.
LLM06 Defines the Ceiling, Not the Climb
OWASP LLM06 identifies excessive agency as agents receiving too many permissions at design time. The proposed mitigations operate at session start: minimal scope in tool definitions, JIT ephemeral tokens before deployment. This framing is correct. It is incomplete.
LLM06 has no model for the permission state at minute 45 of a session that started with minimal, reasonable grants. The specification defines no intra-session revocation primitive and requires no capability audit during execution. The NIST AI RMF Agentic Profile v1 (CSA) acknowledges the gap by categorizing "runtime permission accumulation" separately from static over-provisioning. These are distinct problems requiring distinct controls.
GrantBox (arXiv:2603.28166) measured privilege usage across agents with real-world tools. Finding: agents consistently use fewer permissions than granted at session start, but privilege usage increases monotonically as context accumulates. The permission ceiling is not the problem. The climb toward it is.
Cascading Tool Grants: Each Yes Makes the Next Yes Reasonable
The session starts: the agent needs read access to a project directory. Granted. The agent finds an outdated dependency file and requests write access to update it. Reasonable given context. Granted. The agent discovers the updated dependency requires a configuration change and requests access to the config file. Also reasonable. Granted.
The agent finds an API endpoint referenced in the config that needs validation. It requests network access. Each grant follows from the previous task result. At no point did any individual request appear excessive.
arXiv:2607.13718 studied permission request patterns empirically across platforms including Claude Cowork. Finding: users granted 89% of in-session permission requests because each was contextually justified by the immediately preceding task outcome. Permission creep is not a manipulation attack. It is a coherent request sequence that produces an incoherent cumulative state.
arXiv:2605.05440 formalizes this as "transitive delegation": each step is individually sanctioned, but the final capability surface far exceeds what individual permissions suggested. Production evidence from real enterprise platforms confirms: ordinary system behavior, not only adversarial action, already produces the predicted authorization failures.
Credentials in Context Are Capability Without a Grant Event
Explicit permission grants are visible. Implicit capability acquisition is not.
When an agent reads a file containing an API key and stores it in context, it has acquired the capability to call that API. No permission was requested. No grant event occurred. No audit log entry was written. The key is in context: the model can use it.
arXiv:2605.05440 documents the "capability inheritance" problem. When an orchestrator passes context to a sub-agent, the sub-agent inherits all capabilities encoded in that context. This includes credentials from tool responses, system prompt references, and intermediate results never intended to cross agent boundaries.
GrantBox (arXiv:2603.28166) measured an 84.80% average attack success rate in adversarial scenarios against agents with real-world tool access. The attack surface grows with each credential accumulated in context. AI coding agents routinely read .env files, CI/CD configs, and shell histories as part of normal operation. Credentials absorbed in task N are available without any tool grant change in task N+5. The sub-agent's permission set is not what was configured. It is what the context contains. No standard authorization framework instruments that difference.
'Temporary' Elevated Access Has No Off Switch
Human workflows use temporary elevation: sudo for one command, admin access for one task, break-glass credentials for one incident. Elevation is bounded in time because the human session ends.
Agentic sessions do not expire on task completion. A session granted temporary elevated access for a specific subtask retains that access for the rest of the session. "Temporary" means "for this task" to the human operator and "until session end" to the agent runtime.
arXiv:2607.13718 documents the empirical finding directly: once permissions are granted in a session, users cannot revoke them within that session. The mechanism simply does not exist in the interface. The session's permission state is append-only.
arXiv:2603.14332 identifies the "capability-identity gap": frameworks authenticate who an agent is but fail to detect when its capabilities have changed. This enables silent capability escalation. The SANS Institute "confused deputy" analysis describes the same gap. An agent cannot distinguish between permissions granted directly and those inherited from a prior task's context. Every accumulated capability appears, from the model's perspective, as a legitimately available resource.
The Session Is the Wrong Permission Boundary
RBAC models permissions as identity properties evaluated at role assignment. ABAC evaluates per request. Neither has a concept of permission state at a point in time within a session. Both evaluate the current grant, not the accumulated history of grants.
An agentic session is not a single access event. It is a sequence of access events with shared context. The permission surface grows with each event. By session end, the agent may have accumulated capabilities that no individual grant would have authorized.
arXiv:2605.05440 proposes "task-scoped authorization" as the correct primitive. Permissions are scoped to a declared task with an explicit completion condition, after which they expire. This is not session-level RBAC. It is a different primitive. NIST AI RMF Agentic Profile AG-GV.3 requires tracking what authorities agents hold and updating registries when tools are added. It treats capability state as a dynamic audited quantity.
The minimal footprint principle from OWASP LLM06 is correct: agents should request permissions, store data, and act within the minimum necessary scope. The mechanism to enforce this at runtime does not exist in standard frameworks.
Session-Aware Authorization: Three Controls That Address Accumulation
Task-scoped permission tokens: each tool grant is issued with an explicit task scope and expiry. The cryptographic binding approach from arXiv:2603.14332 ties capability tokens to task identifiers that expire on task completion. The agent cannot carry permissions forward from a completed subtask. Capability drift detection runs in 5 microseconds at 0.12% overhead on 8.7-second workflows.
Context sanitization at agent handoff: the orchestrator strips credentials, sensitive API responses, and capability-encoding material outside the sub-agent's declared scope. The authorization propagation framework from arXiv:2605.05440 treats this as a pre-handoff filter. The resulting permission set is what was configured, not what the context accidentally contains.
Mid-session permission snapshots: the session's permission state is logged at each task boundary. Anomaly detection compares the current capability surface against the declared initial scope. NIST AI RMF AG-MS.1 requires tracking "permission escalation rate" as an early warning signal. The metric measures frequency of requests outside the initial authorization scope.
MAGO Intel (intel.mago.team) tracks permission accumulation across agent sessions. It logs each capability expansion event and flags sessions where the terminal permission surface exceeds the declared initial scope. Implicit capability acquisition through credential-containing tool responses is also detected.
None of these controls exist in standard frameworks today. Each requires custom instrumentation. The alternative is accepting that permission state at session end is unpredictable from session-start configuration, which is the current production default.
Agentic frameworks configure tool access at session start and treat that configuration as static. The authorization state at each task boundary is the question they have not learned to ask. Until they do, every completed task is a silent capability expansion.
Top comments (0)