AS-301a · Module 1

Least Privilege at Scale

3 min read

Least privilege sounds simple: give agents only the access they need. In practice, at scale, it is one of the hardest security principles to implement correctly. The problem is not technical — it is organizational. Teams grant broad permissions because it is faster than figuring out the minimum set. Agents accumulate permissions over time as new features are added but old permissions are never revoked. Six months after deployment, every agent has three times the access it needs because nobody audits the delta between what was granted and what is actually used.

Just-in-time access is the architectural pattern that makes least privilege sustainable at scale. Instead of granting permanent standing access, agents request access to specific resources for specific tasks. A policy engine evaluates the request against the agent's role, the resource's sensitivity, and the current context — time of day, concurrent requests, recent behavior patterns. If the request is approved, access is granted for a defined duration and automatically revoked when the duration expires. No standing access means no permission drift.

Do This

  • Implement just-in-time access with automatic expiration for all non-trivial resource access
  • Audit actual usage against granted permissions monthly — revoke anything unused for 30 days
  • Define permission profiles per task type, not per agent — the task determines the access, not the identity
  • Log every permission grant, every access event, and every revocation for audit and forensic purposes

Avoid This

  • Grant broad permissions to "unblock" agents and plan to tighten later — later never comes
  • Copy permission sets from existing agents when deploying new ones — copied permissions include accumulated drift
  • Treat permission reviews as annual events — permission drift happens weekly, not yearly
  • Allow agents to request their own permission escalations without council or human approval