A bounded agent access platform
How do you preserve the human delegator, the agent identity and the limits of delegated access?
D03 · Authorization & Access Control · D04 · Identity Protocols & Cryptography · D09 · Non-Human Identity (NHI) · D10 · Cloud & Workload Identity · D11 · Identity Security & Zero Trust · D12 · Emerging Identity Technologies
Scenario
A fictional support agent reads tickets and proposes customer record updates. Sensitive writes require a person to approve the specific action.
Learning outcomes
- Design agent identity and delegated authorization.
- Evaluate MCP access controls and verifiable credentials.
- Define a read-only task, a denied action and a write requiring human approval.
Engineering investigation
- Record the initiating human, agent workload and target tool as distinct principals.
- Propose audience-bound, narrowly scoped access and a policy decision for each sensitive tool call.
- Require approval for high-impact writes and correlate request, delegation, tool decision and result.
Proposed trust flow
- Human delegator
- Agent workload
- Policy + approval
- Bounded tool call
This flow is an editorial model to investigate, not a verified deployment.
Engineering trade-off
OAuth token exchange can express delegation, but product support and enforcement must be validated. Agent-specific controls here are a design proposal.
Verified source statement
Primary reference: IETF RFC 8693 · Token Exchange. Reviewed 3 November 2026.
Only the bounded statement above is source-backed. The company context, investigation, controls and flow are teaching proposals. Confirm support and behavior in your chosen environment.
Produce evidence
Define a read-only task, a denied action and a write requiring human approval.
Use L1 to explain the mechanism, L2 to analyze trade-offs, L3 to implement and test, and L4 to design and justify. Reading alone does not establish competence.