Guided security lab

Agent Authorization

A guided exercise on authorizing concrete agent actions: separate authentication from authorization, bind the exact request to the initiating principal and delegated scope, re-authorize changed parameters and keep delegation from amplifying authority across hops.

Conceptual simulationAdvanced15 minutes2026-09-26

Conceptual simulation

This exercise uses authored, deterministic examples with fictional names and neutral synthetic content. It calls no tools, APIs, identity providers, agents or models, and it does not predict how any real model behaves.

Step 3 of 63/6

Learning objectives

Separate authentication from authorization.
Distinguish the acting agent identity from the initiating principal and the delegated user or task scope.
Treat the model's requested action and parameters as a proposal, not as authorization facts.
Evaluate one exact request against application-recorded policy facts.
Recognize when a broad capability, a registered tool, a valid credential or a prior allow is insufficient for the proposed request.
Re-authorize when execution-relevant parameters, resources or destinations materially change.
Prevent authority amplification across agent and tool hops.
Distinguish authorization decisions from separate information-flow, output-validation and human-approval controls.

Prerequisites

Tool Output Injection lab (recommended)
Trust Boundaries and Model Context lab (recommended)

Choose a scenario

Each fictional scenario shows what the model sees and, separately, the identity, delegation, grant, ACL and approval facts the application records. Authorization decisions belong to the application facts.

Authenticated, but out of scopeA signed-in support user asks the agent to summarize one synthetic case. The agent is authenticated and can see a case-management tool, but proposes modifying a different customer record outside the user's delegated case scope.Exact action within delegationThe signed-in user may update the status of one synthetic ticket, the agent workload may perform that operation on the user's behalf, and the exact ticket and new status value are within task scope. No separate flow restriction applies.Model-authored approval claimThe model's proposed action includes a note claiming the user already approved a consequential change. The application's approval and grant store contains no such record for this request.Parameter changed after an allowA draft send to one permitted synthetic recipient was authorized earlier. Before execution the destination changes to a different address, and the model proposes executing the changed request without a new decision.Bounded delegation per hopA parent agent delegates a read-only subtask to a sub-agent. The application records the initiating principal, the parent task and a strict-subset delegation to one permitted resource. The sub-agent proposes only that read.

Action request path and trust flow

A request is authenticated, the model proposes an action, a policy decision point evaluates the exact request and the target tool enforces it. Identity, policy and enforcement are system components; requests and proposals stay variable.

Signed-in user requestVariable content->
Identity provider (authentication)System component->
ModelSystem component->
Proposed tool callVariable content->
Policy decision pointSystem component->
Enforcement at the case toolSystem component

Model-visible request content

What the model reads. It contains no authorization facts.

User request
Please summarize case K-310.
Available tool list
case-management: read_case, update_record

Application-side authorization facts

Recorded by the identity provider, delegation service, grant and approval stores, ACL and destination policy outside model text.

Initiating principal: support-user-ana (authenticated session)
Acting agent identity: agent-workload support-assistant, authenticated to the case tool
Delegated scope: Read case K-310 on behalf of support-user-ana
Requested resource and operation: update_record on customer record R-588, not part of case K-310
Grant state: No grant for support-user-ana or this task to modify R-588