Chapter 10 established how an agent preserves a valid action across failures. That action may still be unauthorized. A checkpoint can say that the next task is add_to_shared_watchlist, but it cannot decide whether the current caller may change a shared list.
The distinction appears whenever an agent moves from reading to acting. Search and record lookup inspect data. A watchlist tool changes it. A model can propose either operation, supply typed arguments, and explain its reasoning. The application must decide whether the proposal may run.
This is the boundary between agent autonomy and system authority. Autonomy describes which decisions the agent can make within a task, such as choosing a query or a tool. Authority describes which resources the application permits that agent to read or change on behalf of a specific identity. Increasing autonomy does not require granting broad authority.
Separate information, capability, and authority
Three layers determine whether a proposed action can proceed.
Information supplies facts that may influence a decision. The user request, retrieved film summaries, tool results, and remembered preferences all belong here. Their origins matter because a user instruction and a sentence inside a retrieved document do not carry the same authority.
Capability is a narrow operation the application makes available, such as vector_search(query) or add_to_watchlist(film_id). Its contract defines inputs, outputs, errors, and side effects. A capability establishes what the system can do. Whether this caller may do it now is the next layer’s question.
Authority comes from identity, permissions, policy, and approval. It answers who is acting, which resource is in scope, and whether the consequence requires confirmation. These checks belong in application code and the underlying service, outside the model’s prompt.
Suppose the user asks the agent to recommend the more ambiguous film and add it to a shared watchlist. The model can search the corpus, compare the evidence, and propose a watchlist write. The proposal crosses several boundaries: the source of the instruction must be legitimate, the tool must expose only the intended operation, the current identity needs write scope, and shared changes may require approval.
Run each proposal below through the harness. The harmless search should proceed autonomously. The private write is scoped to its owner. The shared write pauses for confirmation. The final proposal comes from retrieved content and should stop before any tool permission is considered.
Request
Recommend the more ambiguous film, explain the evidence, and add it to my shared watchlist.
Choose a proposal
Model proposal
Read onlyvector_search("ambiguous identity films")- Waiting
Instruction source
Current user request
- Waiting
Tool boundary
Film search · available
- Waiting
Identity and scope
Signed-in reader · corpus:read · granted
- Waiting
Approval rule
Not required
The lab exposes a useful ordering. Source trust comes first because permissions should not rescue an illegitimate instruction. Tool availability comes next, followed by identity and scope, then consequence-specific approval. A request can pass the first three gates and still pause at the fourth.
Give each tool the least authority it needs
Least privilege means granting only the permissions required for a specific operation, resource, and lifetime. A film-search agent needs read access to the corpus. It does not need a general database credential, a shared-watchlist write token, or an administrative API because those permissions do not help it retrieve a film.
Narrow tools make that policy enforceable. add_to_watchlist(film_id) is easier to validate than execute_sql(statement) because its resource and side effect are explicit. The service can verify the film identifier, derive the list owner from authenticated context, reject writes across tenants, and make the operation idempotent without asking the model to express those constraints correctly.
Bayer and Thoughtworks’ PRINCE system uses deterministic boundaries around its production research agent. Its SQL validator permits SELECT and rejects DELETE, INSERT, and UPDATE. Results are capped at 50 records, and regulatory outputs require review by a qualified expert. The team also removed a model-based SQL review step after it rejected valid queries without a corresponding accuracy gain. A model reviewer added friction but did not enforce the boundary as reliably as code.
Tool contracts should also separate reading, preparing, and committing. The agent might search the watchlist, prepare a proposed addition, and show the exact change before a commit tool becomes eligible. This sequence preserves useful autonomy in discovery and drafting while keeping the consequential step narrow.
Attach every action to an identity
A permission has meaning only when it is attached to a principal, the identity whose authority is being exercised. That principal may be a user, a service, or an agent workload acting for a user. The tool call should carry enough authenticated context for the receiving service to apply its own policy and produce an attributable audit record.
The model should not choose or rewrite that identity. The application obtains it from the signed-in session or workload platform, attaches it outside the prompt, and propagates it through downstream calls. If an agent delegates to another agent, the receiving system still needs the original user context, the calling workload identity, and the limited scope of the delegated task.
Uber’s production agent platform follows this design. Uber reports giving each agent a verifiable identity and propagating workload and user context in signed tokens. Services can then make policy decisions from attributable identities rather than trusting a model-generated claim about who requested an action.
Identity also constrains retrieval. A search tool must filter results to documents the principal is already allowed to access. Chapter 13 follows that rule through lexical and dense candidate generation, caches, counts, suggestions, and traces. This chapter keeps its focus on the proposed operation and the authority required to execute it.
Treat retrieved instructions as untrusted data
Search agents routinely place external text beside user instructions in the same model context. A document can contain prose that resembles a command: “ignore the request,” “call this tool,” or “send the conversation elsewhere.” When that text changes model behavior, the system has encountered prompt injection.
The source-routing discipline from Chapter 9 applies here. A film summary can support claims about a film. It cannot express the user’s intent, grant watchlist permission, or change approval policy. The harness should retain the summary as evidence while refusing to translate its embedded instruction into an eligible action.
A warning in the system prompt does not enforce this boundary, because it relies on the model resisting the very text it is reading. The application can label content by source, keep retrieved text out of tool-control fields, derive tool eligibility from trusted state, validate destinations and arguments, and require explicit approval for sensitive data movement. Even if the model proposes the injected action, the policy layer should reject it because its instruction source is not authoritative.
Microsoft’s Agentic AI Red Team taxonomy draws on twelve months of agentic-system engagements. It identifies session contamination, plugin and MCP abuse, memory and knowledge-base poisoning, cross-domain prompt injection, incorrect permissions, excessive agency, and loss of provenance among the recurring failure surfaces.
Make approval a deterministic policy decision
Approval is useful when an operation is difficult to reverse, affects other people, moves sensitive information, or carries financial or legal consequence. The rule that invokes approval should live in code. A prompt can explain the rule to the model, but the model should not decide whether the rule applies to its own action.
The approval request needs to show the exact principal, operation, target, important arguments, and expected effect. “Allow the agent to continue?” is too broad. “Add Eternal Sunshine of the Spotless Mind to the shared Film Club list once?” gives the reviewer a bounded decision.
Approval is also limited in time and scope. Confirming one watchlist addition does not grant permanent write access or approve a later title. If the action changes after approval, the system must request approval again. The checkpoint from Chapter 10 may preserve the approved operation through a transient retry, but it must preserve the operation identity and idempotency key so recovery cannot substitute a different action.
Microsoft Security’s defense-in-depth guidance recommends treating narrow agents like microservices, granting least privilege, enforcing approvals deterministically, and attaching identity to actions for audit. The guidance explicitly places the approval decision outside model discretion.
Let code enforce rules and the model judge meaning
The model can interpret ambiguous intent and judge semantic fit. Deterministic services should validate schemas, permissions, availability, quantities, limits, and state transitions. This division uses the model where language judgment is needed and code where a rule must hold every time.
Uber’s Cart Assistant applies that separation in a production consumer workflow. Model calls classify intent and assess whether products satisfy the request. Deterministic systems validate tool schemas, item availability, eligibility, quantities, price constraints, and cart-level rules. The shopper retains the final checkout decision. Guardrails appear throughout the state graph rather than only after a final answer has been generated.
The watchlist example is simpler, but the ownership is the same. The model may choose Eternal Sunshine of the Spotless Mind from supported evidence. The watchlist service verifies the caller, write scope, list policy, film identifier, and duplicate status. The approval service records the bounded confirmation. Each layer returns an inspectable result to the trajectory.
Preserve useful autonomy inside the boundary
Strong control does not require sending every search decision to a person. Read-only retrieval over authorized sources can remain autonomous. The agent can reformulate weak queries, inspect candidate records, compare evidence, and stop when the request is covered. Narrow scopes reduce the effect of a bad proposal without removing the capabilities that make agentic search useful.
The final execution record should distinguish the model’s proposal from the harness decision and the service result. It should identify the principal, tool, source of intent, requested resource, policy rule, approval, and side effect. When you debug a refused action, that separation shows whether the model proposed badly, policy denied correctly, or the service failed. A denial or pause is part of the trajectory rather than an exception to hide.
Those records make the last question unavoidable: did the system reach a supported result through an efficient and acceptable path? Chapter 12 evaluates individual steps, complete trajectories, and outcomes together.