Guided defense lab

Least Privilege

A guided exercise on judging whether an agent's authority envelope is minimized for its task class: effective and transitive reach, unique identity versus shared credentials, bounded JIT elevation and credential lifetime versus privilege lifetime.

Conceptual simulationAdvanced15 minutes2026-09-27

Conceptual simulation

This exercise uses authored, deterministic examples with fictional identities, resources and .example.test names. It calls no tools, APIs, agents or models, contains no credential material and does not predict how any real model or system behaves.

Step 3 of 63/6

Learning objectives

Distinguish standing authority from task-scoped authority.
Prefer a unique workload identity over shared credentials for attribution and revocation.
Review the effective permission union, including inherited, group, downstream and integration reach, not one role line.
Delegate only the task-required subset of a user's authority, not the whole user envelope.
Recognize bounded, recorded, auto-expiring JIT elevation as compatible with least privilege.
Separate credential lifetime from privilege lifetime.
Keep least privilege distinct from Agent Authorization, Information Flow Control, Egress and Sandboxing.
Explain why an accepted envelope authorizes no concrete action and why model statements never change provisioned authority.

Prerequisites

Least Privilege defense article (recommended)
Agent Authorization lab (recommended)

Choose a scenario

Each fictional scenario shows task and model text and, separately, the application-owned facts about the task baseline, identity, effective grants, tools, integrations and lifetime. You judge whether the authority envelope itself is minimized - not whether a particular action may execute.

Bounded read-only project taskA status summary for fictional workspace project-a runs under a dedicated identity with read-only access to one folder, two tools and a session-bound grant.Shared organization-wide service credentialA one-project read-only summary runs under a service credential shared by several assistants, with tenant-wide read, multi-workspace write, a send connector and an export integration. The current operation is a harmless read.Aggregate and transitive reachA read-only analysis of one fictional support workspace uses a narrow-looking direct role, but effective-access data shows inherited drive access, an export connector and a guest integration.JIT resource-scoped maintenanceA read-only baseline identity receives a separately approved, 20-minute write scope to exactly one fictional config resource, cfg-22.Short token, broad standing roleA task needing read-only access to one project uses tokens that live ten minutes but each carry a tenant-wide administrative write role, renewed continuously without a task end date.

Authority path

The application defines what a task class needs, provisions an identity and an effective envelope, and that envelope sets the reach of tools, data, integrations and network. User task content stays variable. Every concrete action is still decided separately at execution time.

Task class / required capabilitiesApplication-owned->
User task contentVariable content->
Workload or delegated identityApplication-owned->
Effective authority envelopeApplication-owned->
Tool / data / integration / network reachApplication-owned->
Execution-time authorization (separate)Application-owned

Task and model text

What the user asks and what a model says about its needs or intent. It cannot create, widen or extend a grant.

User task
Summarize this week's status notes for project-a.
Model note
I only need to read the status folder.

Application-owned authority facts

Task-class baseline, identity, direct and effective grants, exposed tools and integrations, and grant or elevation lifetime as recorded by the application.

Task-class baseline: status-summary: read-only project-a/status; retrieval + summarization; no write, send or export; session-bound grant
Identity: unique workload identity report-agent-17
Effective reach: read project-a/status only; tools: retrieve, summarize; no customer database; no outbound connector
Lifetime: grant bound to session sess-17, auto-expires after 45 minutes