What Autonomous Agents Change

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.

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^[3]. The token confirmed it could call the purchasing API. The role confirmed it could create orders^[4]. 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^[5]. Access control asks whether the door opens. Computable authority asks whether the institution authorised what was done once inside. The best objection comes from access-control engineering itself. Attribute-based access control can express a monetary limit, a supplier's onboarding date, and an approver count as attributes^[6]; a well-built policy layer would have refused this order. Concede it: the specific failure here is reachable with existing tools. What attribute rules do not carry is where those attributes come from — which instrument set the $1m limit, which version was in force, who delegated requisition but not award, and what record lets an auditor confirm that the rule the gate enforced is the rule the institution issued. The checks can live in access-control machinery; the authority they enforce needs an issuer and a version. The limit is architectural. A runtime boundary governs only the actions routed through it. An agent that can reach the purchasing system by another path — a second credential, a direct database write, a tool nobody wired to the gate — is outside the boundary however well the authority is expressed. Security practice for language-model systems names this risk 'excessive agency'^[7], and its first mitigation is the unglamorous one: grant the agent no capability the authority layer cannot see.

• 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?
• Which of your agents' capabilities reach a system without passing the point at which authority is checked?

No responses yet. Be the first to answer one of the questions above.

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.
6. 06Identify any path by which the agent could act without passing the authority check at all.