Chapter 18: Authorization for AI agents

Introduction

ACME’s experience shows why agents that choose and revise actions at runtime need explicit, ongoing authorization rather than access based merely on their ability to reach a tool.

• Authentication versus agent authority: Distinguish verifying which service or account makes an agent’s request from deciding what that agent is allowed to do. Explain why ACME’s practice of letting reachable tools and APIs be usable left authorization implicit.
  Why it matters: An agent can make a properly authenticated request that it should not be permitted to make.
• Authorization within agent planning: Explain why agents’ runtime tool choices and revised plans make authorization an ongoing concern rather than only a gate at the system’s edge.
  Why it matters: Checking only initial access cannot account for the actions an agent chooses later.
• Established principles for agent actions: Describe the authorization principles ACME applied to agents at runtime: identify the principal, action, resource, and context; evaluate policy before execution; preserve delegation boundaries; and make decisions observable. State that policy both constrains actions and guides behavior in a dynamic planning loop.
  Why it matters: Existing authorization principles remain useful even when the actor chooses its next action dynamically.

Key terms: authentication, authorization, internal APIs, dynamic planning loop, runtime, principal, action, resource, context, policy

18.1 Why authorization is the hard problem in agentic AI

This section explains why agents’ changing plans and tool use make authorization a continuous, action-by-action governance problem rather than a one-time application check.

• Unpredictable agent actions: Explain why dynamic planning, tool-based execution, and adaptation make agents harder to govern with static authorization assumptions.
  Why it matters: The agent’s flexibility is useful, but it changes what authorization must account for.
• Action-by-action policy evaluation: Describe the shift from an authorization gate at the application edge to evaluating each proposed agent action under current conditions, including ACME’s check before tool use or data access.
  Why it matters: Checking the proposed action at the time it occurs addresses plans that change during execution.
• Shared policy architecture: Explain how ACME governs agents through its existing enterprise policy architecture while adapting policies to agent behavior.
  Why it matters: Agent-specific controls can fit within the enterprise’s existing approach to policy governance.

Key terms: dynamic planning, tool-based execution, adaptive behavior, zero-trust principles, runtime decision-making process, policy engine, policy architecture, tool use, delegation, runtime constraints

18.2 How agents interact with external systems

This section explains how agents use external tools and why each proposed tool action needs authorization that accounts for the authority behind it.

• Agent interactions with external systems: Describe how agents use tools or commands to perform operations outside the model while working toward a goal.
  Why it matters: Those external operations are where an agent’s plans affect real systems and data.
• MCP integration and authorization boundary: Explain what MCP supplies for agent tools and distinguish that integration function from deciding whether a call is allowed.
  Why it matters: A standard way to connect tools does not remove the need to authorize their use.
• Tool requests and delegated authority: Apply PARC to an agent tool invocation and explain why the authority behind that action must be considered.
  Why it matters: An agent’s access to a powerful tool must not let an unauthorized requester use that power indirectly.
• Authorization at each tool action: Explain why authentication and occasional workflow checks are insufficient for agents, and describe where policy evaluation belongs.
  Why it matters: Checking each proposed action keeps dynamically planned behavior within policy limits.

Key terms: tool invocations, structured tool interfaces, command-line interfaces, Model Context Protocol, MCP server, input schema, PARC, confused deputy, principal, action

18.3 A policy-aware agent loop

This section explains how an agent checks each proposed action against policy before execution and replans when an action is denied.

• Continuous authorization for agents: Explain why an agent needs authorization checks throughout its execution rather than only at fixed checkpoints.
  Why it matters: Checking only anticipated steps can miss actions an agent chooses as its plan changes.
• Per-action PARC authorization request: Describe how a proposed agent action becomes an authorization request before the action executes.
  Why it matters: The check can account for the specific action the agent is trying to take and the context in which it is taken.
• Policy decision and agent replanning: Trace what happens to a proposed action after the PEP sends its request for a policy decision.
  Why it matters: A policy decision becomes part of the agent’s next step, rather than merely a one-time approval.

Key terms: agent, authorization decisions, execution loop, Policy Enforcement Point (PEP), PARC model, Principal, Action, Resource, Context, Policy Decision Point (PDP)

18.3.1 Authorization as part of the feedback loop

This subsection explains how authorization decisions become feedback that guides an AI agent’s next action.

• Authorization feedback in agent planning: Trace how an agent’s proposed action is evaluated and how the result affects its next step. Explain why a denial can prompt the agent to revise its plan rather than simply end with an error.
  Why it matters: Authorization does more than block unsafe requests; its decisions help steer what the agent tries next.

Key terms: agent loop, feedback loop, PEP, permit, deny, authorized boundaries

18.3.2 Defining operational boundaries with policy

This section shows how policies keep agents within task-specific resource boundaries and prevent them from changing the controls that govern their work.

• Task-Specific Resource Boundaries: Explain how policy can limit the resources an agent accesses while leaving it free to choose how to complete a task.
  Why it matters: The agent can remain flexible without gaining access to another customer's documents.
• Operational Versus Control-Plane Actions: Distinguish useful operational actions an agent may perform from changes to the systems that define those actions.
  Why it matters: An agent can use a system safely without being able to rewrite the rules of its work.

Key terms: policies, resources, current task, current customer, operational, control-plane actions, workflows, critical controls

18.3.3 From predefined workflows to governed behavior

The section explains why agents’ unpredictable action sequences require authorization at each action rather than only at predefined workflow checkpoints.

• Predictable and agentic workflows: Distinguish authorization in predefined software workflows from authorization in agentic systems, where the agent chooses its action sequence as it gathers information.
  Why it matters: The change in how actions are chosen explains why authorization must move into the agent’s execution loop.
• Policy evaluation for each action: Explain how ACME’s policy-aware execution loop assesses every agent action against the same rules as it occurs, without needing to predict the agent’s overall behavior.
  Why it matters: Per-action evaluation keeps authorization applicable even when the agent’s path cannot be specified in advance.
• Zero-trust action verification: Explain why per-action access control for agents aligns with zero trust: each action is verified in real time using current conditions rather than presumed safe behavior.
  Why it matters: An agent’s expected behavior is not a substitute for checking what it actually does.

Key terms: predefined workflows, agentic systems, static authorization models, policy-aware loop, policy evaluation, execution loop, per-action access control, zero-trust principles, current conditions

18.3.4 Practical implications

This section explains the practical effects of checking agents’ actions against policy and shows how an external policy layer can govern tool use without preventing agents from adapting.

• Policy Checks During Agent Operation: Explain how embedding authorization in an agent’s operation provides continuous enforcement, adapts to changing behavior, sets boundaries, and uses denials as planning feedback.
  Why it matters: Checking actions as they happen lets agents remain adaptable without giving them unrestricted access.
• Agents Within Existing Authorization: Describe how ACME governed agents that used enterprise tools and automated workflows.
  Why it matters: Existing authorization principles can govern agent activity even as agents plan and adapt.
• External Policy for Tool Invocations: Explain how AgentCore Policy illustrates governing agent tool use through an external policy layer.
  Why it matters: External checks let organizations govern tool access consistently without relying on an agent’s prompt to enforce limits.

Key terms: continuous enforcement, dynamic adaptability, operational boundaries, behavioral feedback, principal, policy framework, AgentCore Policy, Cedar, enforcement gateway, external policy layer

18.4 Beyond denial: Guiding agent behavior with policy constraints

The section explains why permitting or denying each attempted tool call is not enough to guide an agent toward actions policy allows.

• Limits of denial-only authorization: Explain why checking each tool invocation and returning permit or deny can leave an agent repeatedly trying actions that policy will never allow, and why policy guidance should identify possible actions before the agent attempts them.
  Why it matters: Guidance can help an agent pursue allowed paths instead of repeatedly discovering restrictions through denials.

Key terms: policy-aware loop, permit or deny, trial and error, policy constraints

18.4.1 From reactive enforcement to constraint-aware planning

This section explains how an agent can query policy during planning to identify actions or resources that policy permits, rather than discovering constraints only after proposing an action.

• Policy constraints in agent planning: Explain how ACME uses Cedar’s Typed Partial Evaluation to let an agent query policy with part of an authorization request unspecified, then use the resulting constraints to plan actions likely to succeed.
  Why it matters: Policy can guide an agent’s choice of actions before it tries them, rather than only rejecting unsuitable actions afterward.

Key terms: Typed Partial Evaluation (TPE), partial authorization request, PARC model, policy-derived constraints

18.4.2 Integrating constraints into the planning loop

This subsection shows how an agent uses policy-derived constraints to plan while leaving authorization decisions to runtime checks.

• Constraint-guided planning sequence: Trace how the agent identifies a possible action or resource, sends a partial request to the policy system, receives a policy residual, and plans within the resulting constraints.
  Why it matters: Policy guidance can steer an agent away from plans that policy will not allow.
• Planning guidance versus enforcement: Distinguish a constraint query from an authorization check: the former guides planning but grants no permission, while the latter makes the final decision at execution with the complete request.
  Why it matters: A plan that fits policy guidance must still be checked when the agent acts.

Key terms: constraint query, partial request, policy residual, policy-derived constraints, authorization check, runtime enforcement, policy engine

18.4.3 Reducing trial and error

This subsection shows how checking policy constraints before acting prevents an agent from repeatedly attempting prohibited access.

• Constraint-aware access planning: Contrast reactive access attempts with constraint-aware planning for an agent seeking credential files, and explain why checking policy first reduces trial and error.
  Why it matters: Checking constraints early saves wasted attempts and reduces unnecessary or risky requests.

Key terms: constraint-aware planning, policy system, trial-and-error behavior

18.4.4 Policy as a source of guidance

This subsection contrasts policy as a reactive gate with policy as guidance that helps an agent plan within authorized boundaries.

• Policy guidance during planning: Explain how exposing policy constraints during planning lets an agent work within policy boundaries instead of discovering them through failed requests, while policy still blocks requests that violate rules.
  Why it matters: An agent can plan within allowed limits rather than relying on rejected requests to find them.

Key terms: policy constraints, constraint-aware model, planning, gate, guide

18.4.5 From control to collaboration

This section explains how authorization can guide an agent’s planning and control the order of its actions through policy context or changing delegation.

• Policy as planning guidance: Explain how constraint-aware authorization guides an agent without replacing its ability to plan and adapt, and describe the effect reported at ACME.
  Why it matters: Policy can help agents act effectively within safe boundaries, not just reject their mistakes.
• Task stage as authorization context: Explain why permission to perform an action may depend on when it occurs in an agent’s task, and how policy can evaluate that sequence.
  Why it matters: Checking task progress lets a system permit an action only when its prerequisites have been met.
• Evolving authority through delegation: Describe how delegation data can enforce an action sequence as an alternative to durable policy rules.
  Why it matters: Delegation offers another way to make an agent’s available actions match its progress through a task.

Key terms: constraint-aware authorization, policy, replan, sequencing, contextual attributes, authorization request, task progression, delegation data, authority, runtime

18.5 Childproofing the control plane

This section explains how ACME lets agents perform useful tasks while using policy to keep the system’s configuration and governing rules out of their reach.

• Control plane modification risk: Explain what the control plane includes and why letting agents modify it would threaten the safeguards that constrain them.
  Why it matters: An agent’s ability to use a system should not include the ability to change the rules governing that use.
• Policy enforced action separation: Distinguish operational actions from control-plane actions and describe how ACME’s policies keep the latter reserved for trusted administrative principals, even when agents have delegated authority.
  Why it matters: This separation lets agents do useful work without giving them authority to rewrite how that work is controlled.
• Safeguarded expansion of agent tasks: Describe how ACME could expand agents’ permitted operational tasks as it learned more about risks, without removing core control-plane protections.
  Why it matters: Agent permissions can evolve without granting agents control over the rules that constrain them.

Key terms: control plane, safeguards, operational actions, control-plane actions, delegated authority, trusted administrative principals, operational boundaries, control-plane protections

18.6 Delegation and subagents

The section introduces the authorization problem created when a primary AI agent delegates work to specialized subagents and explains why delegation must be explicit.

• Explicit authority for subagents: Explain why assigning work to subagents raises the question of whose authority they use, and why ACME represents delegation as structured data that policies can evaluate.
  Why it matters: Dividing a task among agents should not silently expand what those agents are allowed to do.

Key terms: primary agent, subagents, implicit delegation, structured data, policies

18.6.1 Delegation as data

The section explains how a subagent’s delegated authority can be represented as data or attached policies, and how either approach remains subject to authorization policy.

• Delegation record scope: Describe what a delegation record identifies and how it bounds a subagent’s authority.
  Why it matters: The record makes the intended limits of a subagent’s authority explicit.
• Runtime evaluation of delegation: Trace how a delegation record is used when a subagent invokes a tool, and explain why the record alone is not a grant of access.
  Why it matters: A handoff remains governed by an authorization decision when the subagent acts.
• Data and attached policy models: Distinguish delegation as data from delegation through attached policy sets, including how the approaches can be combined.
  Why it matters: The distinction shows two ways to make delegated authority explicit without abandoning policy control.

Key terms: delegation record, delegator, delegate, delegation scope, expiration, PEP, authorization request, policy system, Policy as Data, Policy as Code

18.6.2 Enforcing delegation at runtime

This section explains how a subagent’s proposed action is authorized at runtime using both general policies and the limits of its delegation.

• Delegation-aware runtime enforcement: Trace how a subagent’s proposed tool action becomes an authorization decision: the PEP retrieves the delegation record, includes its data in the request context, and the policy engine evaluates the action against both base policies and delegation constraints.
  Why it matters: A subagent’s authority can be checked for each action rather than assumed from the fact that work was delegated.

Key terms: subagent, PEP, delegation record, authorization request, context, base policies

18.6.3 Policies that enforce delegation

This section explains how layered Cedar policies enforce an agent’s delegation by checking the named delegate and limiting the grant to its recorded scope.

• Layered delegation enforcement: Explain how a forbid guardrail and a narrower permit policy use a delegation record to control a subagent’s requests. Describe when a request is denied.
  Why it matters: The agent’s authority stays tied to the delegation it was actually given.

Key terms: delegation record, delegate, subagent, forbid policy, permit policy, allowed actions

18.6.4 Allowed and denied behavior

This subsection shows how authorization decisions keep a subagent’s actions within its delegated authority.

• Delegated scope enforcement: Explain how the policy engine permits actions within a subagent’s delegated scope and denies actions beyond it, requiring the agent to revise its plan.
  Why it matters: A subagent’s identity alone does not establish permission to act outside the authority delegated to it.

Key terms: subagent, delegated scope, delegation constraints, authorization request, permit decision, deny decision

18.6.5 Delegation as constrained authority

This section explains that delegation lets agents share work only within authority already granted by policy and narrowed by task-specific constraints.

• Limits of delegated authority: Explain why delegation cannot grant an agent new permissions: each delegated action must satisfy both base policies and delegation constraints, which narrow authority to a specific task.
  Why it matters: This prevents an agent from gaining or passing on authority it never had.
• Controlled subagent work: Describe how evaluating each subagent action in context makes delegation a controlled and auditable way to distribute work without giving up control.
  Why it matters: Sharing work does not require giving subagents unchecked freedom to act.

Key terms: base policies, delegation constraints, delegation data, task-bound scope, controlled and auditable, subagent, evaluated in context

18.6.6 Extending the policy-aware architecture

The section shows how policy-aware authorization extends to delegated agents, using bounded mandates, checks before issuance, and enforcement at every tool call.

• Delegation within policy-aware authorization: Explain how delegation lets subagents work independently without replacing the existing policy engine or trusting agents implicitly.
  Why it matters: Agents can cooperate on complex tasks without treating cooperation as permission to exceed their authority.
• Bounded mandates before issuance: Describe how Clawdrey gives child agents explicit, time-limited authority and checks that authority before issuing a credential.
  Why it matters: Checking a proposed mandate prevents excess authority from reaching a child agent in the first place.
• Analyzed guardrails and tool enforcement: Explain why Clawdrey combines analysis of policy guardrails with policy enforcement before tool calls.
  Why it matters: Analyzed policies and enforced tool-call decisions provide protection even when an agent’s instructions or behavior cannot be trusted.

Key terms: policy-aware architecture, delegation record, policy engine, subagents, OVID, OVID-ME, Cedar mandate, attenuated authority, ambient authority, Carapace

18.7 Cross-domain delegation among agents

The section explains how agents can delegate authority across organizations while preserving local authorization boundaries, and how changing authorization context affects decisions in agentic systems.

• Cross-domain cooperation foundations: Explain why cross-domain delegation cannot rely on one organization enforcing another agent’s behavior, and how policies, promises, and reputation support reliable cooperation.
  Why it matters: Cooperation between agents needs a basis for trust when neither organization controls the other’s systems.
• Promise-to-payment delegation flow: Trace how the partner’s promise, ACME’s delegation credential, the partner’s policy decision, and recorded outcomes fit together in the reimbursement example.
  Why it matters: The sequence separates a statement of intended behavior from delegated authority and from the final payment decision.
• Authorization signals across agent hops: Describe how authorization context changes as agents plan and delegate, and distinguish signals that steer intermediate agents from signals needed at final enforcement.
  Why it matters: A signal protects an action only if it reaches, and is considered by, the parts of the agent chain that need it.
• Request-time evidence of authority: Distinguish traditional, pre-established access relationships from agentic requests whose agents and delegated authority may not be known until request time.
  Why it matters: The resource needs to establish responsibility and authority for the agent actually making each request.
• Deterministic final access decision: Justify using models or tooling to handle complex authorization signals while keeping the final permit-or-deny decision in deterministic policy.
  Why it matters: Handling more context should not make decisions about people’s data or money unaccountable.

Key terms: society of agents, promises, reputation, local policies, promise, verifiable credential, delegated authority, reputation database, authorization context, steering signals

18.8 Summary