A search agent can find a film without having permission to change anything. The distinction becomes concrete when it proposes adding Eternal Sunshine of the Spotless Mind to the shared Film Club watchlist. Even if a retry would be safe, the application still needs to establish who requested the change, whether that person may edit the list, and whether the exact action requires approval.
The model can propose adding the film, supply its identifier, and explain the choice. Only the application can decide whether that proposal may become a real side effect. It does so by checking where the instruction came from, exposing only the required capability, binding the proposal to an authenticated identity and scope, and enforcing any approval rule at the service boundary.
These checks separate agent autonomy from system authority. Autonomy describes which choices the agent can make within a task, such as reformulating a query or selecting a tool. Authority describes which resources the application permits the agent to read or change on behalf of a specific identity. This chapter follows the watchlist proposal through that boundary and records each decision in the
Separate information, capability, and authority
Three layers determine whether the Film Club proposal can proceed. Information supplies facts that may influence the choice, including the user’s request, film summaries, tool results, and remembered preferences. Those facts can support a recommendation, but their origins determine whether any of them can also instruct the system to act.
Once the application recognizes a legitimate instruction, it can consider a capability: a narrow operation such as vector_search(query) or add_to_watchlist(film_id), with defined inputs, outputs, errors, and side effects. The capability gives the harness a specific action to evaluate. Before executing it, the application must establish whether the current caller has authority over the target resource.
That decision belongs to authority, which joins an authenticated identity with permissions, policy, and any required approval. For the proposed watchlist write, the application must establish who is acting, whether the shared list falls within that identity’s scope, and whether changing it requires confirmation. These checks run in application code and the receiving service, outside the model’s prompt.
Run each proposal below through the harness and watch where its path ends. The search proceeds because it only reads authorized data, while the private write remains within its owner’s scope. Changing the shared list introduces a consequence for other people, so that proposal pauses for confirmation. An instruction taken from retrieved content stops earlier because its source cannot establish user intent, which means tool permissions never enter the decision.
Request
Recommend the more ambiguous film, explain the evidence, and add it to my shared watchlist.
Proposal
Read onlyvector_search("ambiguous identity films")- Waiting
Instruction source
- Waiting
Tool boundary
- Waiting
Identity and scope
- Waiting
Approval rule
The instrument exposes the order in which those questions become useful. Instruction provenance comes first because permissions cannot rescue a command taken from an illegitimate source. The harness then checks tool eligibility, identity and scope, and consequence-specific approval. The shared write can pass the first three gates and still pause at the fourth.
Establish where the instruction came from
The user’s Film Club request reaches the model beside summaries retrieved from the movie corpus. Because the model reads both as text in one context, a sentence inside a summary can resemble an instruction to “ignore the request,” “call this tool,” or “send the conversation elsewhere.” Prompt injection occurs when content supplied as evidence changes the model’s behavior as though it came from an authoritative instruction source.
The source-routing discipline from Chapter 9 assigns each input a role based on its provenance. The user’s request can express intent that the application considers for action, while a film summary can support factual claims about a film. Carrying those roles into the execution record lets the harness preserve useful evidence without promoting an embedded command into a watchlist operation or a change to approval policy.
A system-prompt warning adds another instruction inside the same context and still depends on the model to follow it when hostile text competes for attention. Enforcement begins in the application, which carries provenance into the control layer, derives tool eligibility from trusted state, and constructs destinations and arguments outside retrieved prose. If the model proposes a write copied from a summary, the harness rejects that proposal at the source gate before tool permissions enter the decision.
Microsoft’s Agentic AI Red Team taxonomy draws on twelve months of agentic-system engagements to show how this failure can travel through an agentic system. It records session contamination and cross-domain prompt injection, abuse of plugins and MCP tools, poisoning of memory and knowledge bases, incorrect permissions, excessive agency, and lost provenance. Across those surfaces, enforcement depends on keeping retrieved data in its evidence role so that it cannot grant itself control over the system that retrieved it.
Expose only the capability the task 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.
Once the harness accepts the user’s instruction, it can expose only the capability needed for the next step. 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 applies this principle to a production research agent. Its SQL validator permits SELECT while rejecting DELETE, INSERT, and UPDATE, and it caps results at 50 records. Regulatory outputs require review by a qualified expert. The team also removed a model-based SQL review step after it rejected valid queries without improving accuracy, leaving deterministic code to enforce the boundary.
The watchlist contract can make the same separation explicit. The agent may read the list, prepare an addition, and show the exact change before a commit tool becomes eligible. Discovery and drafting remain autonomous, while the consequential operation stays narrow enough for the next gate to evaluate.
Bind the proposal to an authenticated identity and scope
A permission has meaning only when it is attached to a principal, the identity whose authority is being exercised. For the Film Club proposal, the application obtains the signed-in user’s identity from the session, joins it with the calling agent workload and target list, and passes that authenticated context to the watchlist service. The service can then apply its own policy and record who requested the change.
The model neither chooses nor rewrites this identity. The application attaches it outside the prompt and propagates it through downstream calls. If the agent delegates part of the task, the receiving system still needs the original user context, the calling workload identity, and the limited scope of the delegated operation.
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, but that decision belongs at an earlier boundary than the proposed watchlist write. Chapter 13 follows the principal through lexical and dense candidate generation, caches, counts, suggestions, and traces. Here, the authenticated principal and target give policy enough context to decide whether the write falls within scope.
Require approval for the exact consequential action
The user may have permission to write to the Film Club list and still need confirmation before changing a resource shared with other people. That consequence causes the proposal to pause. A private-list addition under the same identity may proceed because it affects only its owner. The policy that distinguishes those cases lives in code, where the model cannot waive it for its own proposal.
The approval request should show the exact principal, operation, target, important arguments, and expected effect. “Allow the agent to continue?” leaves the action open. “Add Eternal Sunshine of the Spotless Mind to the shared Film Club list once?” binds confirmation to a decision the reviewer can inspect.
That confirmation lasts only for the operation, target, film, policy context, and time window it names. It does not grant permanent write access or approve a later title. If any bound argument changes, the system must ask again. The checkpoint from Chapter 10 may carry 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.
Enforce the decision at the service boundary
After approval, the proposal reaches the watchlist service. The model has already done the semantic work: it interpreted the request and chose Eternal Sunshine of the Spotless Mind from supported evidence. The service now performs checks that must hold every time, including the schema, authenticated caller, write scope, list policy, film identifier, duplicate status, approval, and idempotency key.
Uber’s Cart Assistant uses the same division 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, while the shopper retains the final checkout decision. Guardrails appear throughout the state graph rather than only after an answer has been generated.
The watchlist service follows that pattern when it either commits the approved addition or returns a typed refusal. Its result does not overwrite the earlier decisions. The trajectory retains the model’s proposal, the harness policy decision, the bounded approval, and the service result as separate events.
Preserve useful autonomy and record the decision
While the shared watchlist write waits for confirmation, the agent can continue working within its authorized read scope. It may reformulate a weak query, inspect candidate records, compare evidence, and stop when the request is covered because none of those actions inherits permission to change the list. The narrow write boundary contains the effect of a bad proposal while leaving the search work autonomous.
Each gate adds its decision to the execution record instead of replacing the events that came before it. The Film Club proposal remains connected to the user instruction and authenticated principal, then to the eligible tool, target list, policy rule, approval state, and service result. That sequence makes a completed write attributable and gives a pause, denial, or service failure an exact location in the trajectory.
The chapter began with a supported film recommendation approaching a shared resource. By carrying the proposal through provenance, capability, identity, scope, approval, and service enforcement, the application can preserve the agent’s useful choices while keeping the resulting side effect inside the caller’s authority. The completed record now shows what the system proposed, why policy allowed or refused it, and what the service changed.
Chapter 12 takes that record as its evidence. Authorization established whether each action was permitted under the current identity and policy; evaluation will judge whether the complete route used those permitted actions to reach a supported result at an acceptable cost.