How it works
Privilege creep is not usually one dramatic grant. It is the slow widening of reachable authority across runs, tools, memories, browser profiles, credentials, and workflow shortcuts. A harness starts with a bounded job. Then the job needs one more API token, a broader filesystem path, a reusable browser session, or write access for a nearby task. Each addition may be reasonable in isolation. The failure is that the combined authority is not recomputed.
The mechanism is simple:
- A task receives an initial permission set.
- New tools or credentials are added to remove friction.
- State persists across turns, runs, agents, or operators.
- No later checkpoint compares reachable authority to the current task contract.
- The agent can now affect systems outside the intended boundary.
The important word is reachable. A permission does not need to be used to matter. If the agent can invoke a tool, reuse a token, inherit a session, or steer another component that has authority, that authority is part of the agent's effective privilege. Privilege creep is therefore a control-plane problem, not only an identity-and-access-management problem. The harness has to account for what the agent can cause, not just what was explicitly written into a role description.
Why it matters in an agent harness
Agentic systems make privilege creep more dangerous because authority is exercised through trajectories, not single calls. A model may plan, delegate, retry, inspect old state, call tools, and recover from errors. That makes the permission boundary dynamic. A harmless read tool can become part of a write path. A browser session can carry authentication into an unrelated task. A subagent can inherit enough context to act as a confused deputy.
The engineering outcome is loss of containment. When privilege creeps, reversibility gets harder because more systems may have been touched. Observability gets noisier because the trace shows individual actions but not the boundary that should have prevented them. Evaluation gets weaker because tests often cover the happy path, not the accumulated authority of a long-running harness. Operator trust also degrades. The operator can no longer answer a basic question: what could this run change?
Privilege creep also distorts approvals. If a workflow approval checks only the proposed action, it may miss the fact that the agent reached that proposal through an overbroad token, an inherited browser profile, or a stale delegation. Good approval design separates capability from permission. The model may know how to do something. The harness still decides whether this run, under this contract, may do it now.
The practical control is to treat permissions as state that expires, narrows, and gets re-derived. Long-lived agents need periodic authority reconciliation. Handoffs need explicit scope transfer. Tool surfaces need read/write separation. Credentials need mediation rather than raw passthrough. Logs need to record not just what happened, but what authority was available when it happened.
Privilege creep vs least privilege
Least privilege is the design principle. Privilege creep is the failure mode that appears when the principle is not continuously maintained.
| Concept | What it asks | Harness decision it changes |
|---|---|---|
| Least privilege | What is the smallest authority needed for this task? | Initial permission design, credential scope, tool exposure. |
| Privilege creep | Has effective authority grown beyond the task boundary? | Revalidation, expiration, revocation, handoff checks, trace review. |
| Permission scope | What does a specific grant allow? | How a tool, token, path, or session is bounded. |
| Blast radius | What damage is possible if the run goes wrong? | Whether extra approvals, sandboxing, or rollback plans are required. |
The distinction matters because a system can start with least privilege and still drift. A harness that only reviews initial configuration will miss accumulated browser state, newly installed tools, cached credentials, broadened package authority, and inherited memory. Least privilege is a starting posture. Privilege creep is what the harness must detect over time.
The Rifty take
We optimize for authority that is explicit, current, and proportionate to the run. A capable agent should not carry old access just because a previous task needed it. We accept some operational friction to keep the control boundary legible. The boundary is simple: if a run cannot explain why it needs an authority now, the harness should remove it, narrow it, or stop before use.
Common failure modes
- Long-lived browser profiles carry authenticated sessions into unrelated workflows.
- Tool registries grow, but old tools are never removed from the agent's reachable surface.
- Read-only research jobs inherit write credentials from publishing or deployment jobs.
- A subagent receives broad context and can act through the parent agent's authority.
- Approval checks review final output but ignore the permissions used to reach it.
- Tokens are scoped by application convenience rather than by task, operation, or resource.
- Recovery paths grant broader access than the normal path and then persist after recovery.
- Memory stores preserve identifiers, paths, or operational hints that let future runs cross a boundary.
- Logs record tool calls but omit available authority, making after-the-fact review incomplete.
- Operators rotate keys but do not re-audit which harness components can still reach them.
Frequently asked questions
How do I tell whether privilege creep is happening?
Privilege creep is happening when the agent's reachable authority is broader than the current run contract. Compare the task's needed actions with available tools, tokens, browser sessions, filesystem paths, memories, and delegated agents. Any authority that cannot be justified for the current task is drift.
Is privilege creep only a security issue?
Privilege creep is a reliability and control issue as much as a security issue. Overbroad authority makes failures harder to contain, actions harder to reverse, and traces harder to interpret. Security language describes the risk, but harness engineering has to manage the operational mechanics.
What is the best default control against privilege creep?
The best default is expiring, task-scoped authority mediated by the harness. Grant access for a specific operation, record why it was granted, and remove it when the operation ends. Persistent credentials and sessions should be exceptions with explicit review, not the normal operating shape.
How does privilege creep interact with human approval?
Human approval is weaker when it reviews only the requested action. The approval point should also show the authority used or about to be used: token scope, write surface, browser identity, target resource, and rollback path. Otherwise the human approves an output without seeing the real blast radius.
Can observability catch privilege creep after the fact?
Observability can reveal privilege creep only if traces include available authority, not just executed calls. A useful trace records which tools were reachable, which credentials were mediated, which scopes were granted, and which boundary checks passed. Without that, the absence of misuse can hide the drift.