Lab 003 · Agent Access Control
Agent Access Control
When agents act on behalf of principals, every request needs live authority evaluation — not just a one-time network gate.
Network Access Control taught us to discover what is connecting, understand its posture, and decide what it should be allowed to reach. Agents make that harder. They interpret goals, use data, call tools, and sometimes delegate work to other agents. Access cannot be a one-time admission decision — the request has to be evaluated when the agent is ready to act.
Educational simulation with fictional Cedar Quill Markets principals, agents, delegations, and posture evidence. No real accounts, credentials, or transactions. Execution is never performed.
From NAC to agent access control
A device on the network might get one posture check at join time and then move freely inside a segment. An agent keeps asking for new actions — read this feed, call that tool, touch confidential data — and each request carries different evidence about who is acting and what they want to do.
An agent may be registered and recognizable, yet still be unable to act. Its authority, posture, tools, data, and current context all matter when the request is evaluated.
This Lab explores an emerging Agent Authority Model as a conceptual architecture for live request-time evaluation. It is not presented as an established industry standard.
How to use this Lab
- Pick a scenario — each preset is a complete fictional Cedar Quill Markets request.
- Choose Guided or Instant — watch checks unfold step by step, or see the full result immediately.
- Run evaluation — follow actor, request, authority, current state, and decision as the server returns canonical events.
Suggested order if you are demoing: Managed public data read → Sensitive action consent → Unknown agent protected tool → Unknown agent registration → Data boundary violation.
Scenario presets
Every preset evaluates policy only. No transaction is executed.
Valid and recoverable
Delegation failures
Identity failures
Restricted recovery
Profile and posture
Resource failures
Lifecycle failures
Purpose failures
Agent management state
What Cedar Quill’s management plane already knows about registration and inventory — before this specific request is judged.
- Agent ID
- —
- Principal ID
- —
- Classification
- —
- Registration state
- —
- Management status
- —
Request summary
The fictional inputs for the scenario you selected.
- Requested action
- —
- Requested tool
- —
- Requested resource
- —
- Data classification
- —
- Fictional amount
- —
- Stated purpose
- —
- Request time
- —
- Agent ID
- —
- Principal ID
- —
- Registration state
- —
View fictional request JSON
Select a scenario.
Evaluation mode
Live Authority Evaluation
Select a scenario and run evaluation.
Decision
Pick a scenario and run evaluation. The service returns a decision only — it never executes a tool action.
Evidence details
Technical evidence appears after evaluation.
Audit record
Audit metadata appears after evaluation.
Restricted recovery
The original decision remains unchanged. Restricted recovery does not execute the protected action. New evaluation required.
Live evaluation sequence
Incoming evidence about the actor and the request is evaluated separately, then authority and current state are checked before a decision. DENY outranks STEP_UP, CONFIRM, and ALLOW.
Management plane
Registry, inventory, and profiles keep management state current. That context informs evaluation at request time — it does not, by itself, grant operational authority.
Restricted mode
After DENY or a recoverable challenge, a restricted path may open for onboarding, posture refresh, or consent — without executing the protected action and without rewriting the original decision.
Re-evaluation after change
Stale posture evidence or a material context shift should trigger step-up and a full re-evaluation. You cannot assume yesterday’s ALLOW still applies.
Teaching notes
Registration tells you who showed up. Delegation, resource boundaries, purpose, limits, posture, and context tell you whether this specific action should proceed. Evaluation stays deliberately separate from execution — the gateway decides; something else performs.
Every evaluation reports execution: not_performed. ALLOW is
short-lived and bound to the evaluated request.