Lecture 1.5
Traditional automation runs a path a human designed: if X, do Y. An autonomous agent interprets the objective, chooses the tools, calls the APIs, and picks among actions the designer never enumerated. This lecture examines why that shift moves the authority question from design time to runtime — and why knowing which agent is acting is not the same as knowing it is allowed to.
Supports Law 7 — The Boundary of Authority Must Be Enforced, Not Assumed. →Learning objectives
After this lesson, the reader should understand:
Concept framework
Three questions, three layers
Case study
A procurement agent holds valid credentials, a scoped API token, and a role that permits it to create purchase orders. It raises a £2.1m order to a supplier onboarded that morning. Every access check passed. What failed?
Nothing in the access layer — and that is the point. Identity confirmed which agent acted. The token confirmed it could call the purchasing API. The role confirmed it could create orders. None of them expressed the institution's actual authority: that orders above £1m require a second human approver, that a supplier must clear a fourteen-day integrity check, that this agent's delegation covers requisition but not award. Those live in a policy document nobody wired into the runtime, so the agent operated inside its permissions and outside its authority. Access control asks whether the door opens. Computable authority asks whether the institution authorised what was done once inside.
Discussion questions
Exercise
Map one agent-driven task against the three layers.
Research notes