XIV · Anti-PatternsAnti-pattern✕

Static Role for a Dynamic Agent

also known as Standing Privilege for Agents, RBAC-for-Agents Mismatch

Anti-pattern: authorize a goal-driven agent with static, login-time, role-based privileges, so its standing permissions persist between and beyond tasks, forcing a choice between over-granting broad access and blocking the agent mid-task.

Context

An organisation already governs its people with role-based access control: users are placed in groups, groups map to roles, roles grant standing permissions, and access is decided once at login. When it deploys an agent it reaches for the same machinery — give the agent a role, put it in the right groups, grant the permissions that role implies. The agent, however, is goal-driven: it chains tools, retries, and discovers paths no one enumerated when the role was defined.

Problem

Role-based access control decides permissions once, from a static role, for a predictable actor. A goal-driven agent is none of those things. Its action set is dynamic and task-dependent, so the role either grants more standing privilege than any single task needs — broad, long-lived access that persists between and beyond tasks and becomes the blast radius when the agent is hijacked, prompt-injected, or simply wrong — or it grants too little and the agent is blocked mid-task, so someone widens the role to unblock it. Because each new task path wants a different permission combination, roles multiply until effective access can no longer be explained. The model cannot express what actually governs a safe agent action: this principal, this task, this moment, revocable when the task ends. Standing privilege is the default the model pushes toward, and it is exactly the wrong default for an actor that decides its own next step.

Forces

  • RBAC decides access once, at login, from a static role; agents decide their next action continuously, at runtime.
  • A goal-driven agent's permission needs are task-dependent and not fully enumerable when the role is defined.
  • Granting the role enough privilege to never block the agent means granting standing access far broader than any single task needs.
  • Reusing the organisation's existing RBAC machinery is faster than building runtime, task-scoped authorization.

Example

A team gives its new support agent a role in the existing identity provider: read the ticket store, call the refund API, query the customer database. It works until the agent, following a manipulated ticket, issues refunds it was never meant to — because the refund permission was standing, not task-scoped, and nobody was in the loop at the moment of action. To stop blocking the agent on edge cases, the team had already widened the role twice. They switch to runtime authorization: each consequential action is checked against the current task and principal, refund authority is granted as a short-lived token only for the ticket being handled, and it is revoked when the ticket closes — so privilege no longer outlives the work.

Diagram

Solution

Therefore:

Replace standing, role-based grants with runtime, task-scoped authorization. Decide each consequential action against the current principal, task intent, and context rather than against a role assigned once at login; issue least-privilege, short-lived, revocable credentials per task so privilege never outlives the work that needed it; expand access only as the agent demonstrates it needs and can be trusted with more. Mitigation patterns: delegated-agent-authorization for scoped, short-lived, revocable per-action credentials, and progressive-tool-access for minimal access that expands only as competency is shown. Static RBAC is not wrong for human users whose access is decided at login; it is wrong as the authorization model for an actor that chooses its own next step, which is the mismatch this anti-pattern names.

What this pattern forbids. No useful constraint; the missing constraint is runtime, task-scoped authorization — every consequential agent action checked against principal, task, and context, granted least-privilege and short-lived, and revoked when the task ends.

The patterns that counter or replace it —

  • alternative-toDelegated Agent Authorization★— Have an agent act for a principal using scoped, short-lived, revocable delegated credentials rather than the principal's own static secrets, so each action stays attributable across the principal-to-agent-to-subagent chain and a compromise is contained.
  • alternative-toProgressive Tool Access★— Grant tool permissions on a need-to-use basis, starting minimum and expanding only as the agent proves competency, mirroring how humans earn system access.
  • complementsAgent Privilege Escalation✕— Anti-pattern: let an agent's effective permissions be the union of its own identity, the identities of its tools, and the identities of the services those tools call.
  • complementsTool Over-Broad Scope✕— Anti-pattern: grant the agent tools scoped so broadly that a single hallucinated argument can escalate into a privilege incident.
  • complementsAgent Identity Sprawl✕— Anti-pattern: an agent fleet mints non-human identities at machine speed while scoping, rotation, ownership, and revocation stay human-speed, so over-privileged long-lived credentials accumulate, outlive their agents, and widen an ungovernable attack surface.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance