Module 1 · The Policy Problem

Lecture 1.5

What Autonomous Agents Change

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 7The Boundary of Authority Must Be Enforced, Not Assumed.
Lesson 5 / 39Start the course to keep your place and get the rest by email.

Learning objectives

After this lesson, the reader should understand:

  • 01Distinguish a fixed workflow from an agent operating in a space of possible actions.
  • 02Separate identity, access, and institutional authority as three distinct layers.
  • 03Explain why the execution boundary becomes the governance boundary once no human adjudicates each action.

Concept framework

Three questions, three layers

  1. 01Identity — which agent is this?
  2. 02Authentication — can it prove that?
  3. 03Access — may it reach this resource?
  4. 04Authority — is this action, now, within the institution's delegated boundary?
  5. 05Boundary state — what happens when that cannot be established?

Case study

The agent that was allowed in

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

  • Is 'the agent had permission' ever a sufficient account of an automated action?
  • What can an autonomous agent do that a scripted integration cannot — and which of those need fresh authority?
  • Should an agent's authority be checked once at the start of a task, or at each consequential step?
  • Who holds the delegation when an agent sub-delegates a task to another agent?

Exercise

Map one agent-driven task against the three layers.

  1. 01Describe the task and the actions the agent may take within it.
  2. 02For each action, note how identity and access are established.
  3. 03For each action, state the institutional authority it requires and where that authority is currently written.
  4. 04Identify the step at which the agent could stay inside its permissions and exceed its authority.
  5. 05State what the runtime should return when the authority for a step cannot be established.

Research notes

  • NIST NCCoE (2026) — software and AI-agent identity and authorization, concept paper.
  • Agentic architectures — planning, tool selection, and delegation between systems.
  • Access control theory — RBAC/ABAC and the resource-permission model.
  • Safety engineering — the operating envelope and actions outside the designed path.
  • Computable Authority, §4 — 'Why Autonomous Agents Change the Problem'.