Take this into your next conversation
The lesson in three points
- An approval should identify the action and its limits.
- Check delegated authority at the point of execution.
- Make escalation and ownership explicit when a request falls outside the boundary.
Free member resources · Sign-in required for downloads
- Define the action
- Check current authority
- Execute within limits
- Record the outcome
Try it before you read
Teaching exercise: an agent prepares a refund. Specify the order, amount, policy version and expiry of the approval, then explain what happens if any of them changes.
You approved a trailer for one territory, one channel, and one release window. Before publication, the asset changes.
Should the agent still publish it?
The approval was real. The request now in front of the system is different. An “approved” flag may have lost the information needed to recognize that difference.
Bring this question to your next system design interview or architecture review: what exactly was authorized, and which service checks that the action still matches?
I created two separate, free prep assets for this lesson: an Empower Interview Practice Guide for rehearsing your answer, and a System Design & Architecture Review Prep Pack for preparing a team decision. Both include fillable worksheets; you can download them below.
This is the Empower lesson in my LLM-SHIELD framework, from the October 31 AI Architect Circle session. A model can identify a useful next step. The architecture must establish whether that step is authorized. The trailer example is a fictional teaching scenario.
Define permission around one specific action
Start with the effect. Reading a document, changing a delivery address, and publishing a trailer carry different consequences.
For each action, define the actor, tenant, resource, operation, parameters, and permitted state. A trailer request might identify the asset version, territory, channel, and release window. A refund needs an amount and a specific transaction. An address change needs the order, proposed address, and state in which the change remains permitted.
These details form an action contract: a concrete description of what the system may do and under which conditions. The model’s confidence cannot supply a missing authorization decision.
Try this before your next review: replace “the agent can publish” with a sentence that names the exact asset, version, destination, and conditions.
Bind approval to the action the reviewer saw
Suppose a reviewer approves trailer A17, version 3. The execution queue later receives version 4 with the original approval reference.
The publishing service should detect that mismatch and preserve the draft for a new decision. An approval for version 3 does not cover a different version merely because the asset name looks familiar.
Approval binds to the reviewed action. A changed asset version needs a decision that covers the new request.
Make the approval’s scope, expiry, and revocation rules explicit. Define what happens if the channel changes, the release window closes, or the actor loses permission while the request waits.
Review question: what did the reviewer actually see, and how does the execution service prove that it is about to perform that same action?
Give each decision an enforcing owner
Separate these responsibilities so every check has a component that enforces it:
1. Propose: the model produces a structured request with explicit parameters.
2. Authorize: the policy or domain service checks the actor, resource, tenant, and applicable rules.
3. Approve when required: a reviewer approves the specific action and its conditions.
4. Execute: the execution service rechecks current authority and state before committing the effect.
5. Record: retain the decision and observed outcome so another engineer can inspect what happened.
A useful design names the service that rejects an unauthorized action and the state that remains when execution cannot proceed.
Explain how the service keeps its validation and commitment consistent. Depending on the system, that may require a conditional version check or transaction. Do not assume a request remains valid simply because it passed a check earlier.
OWASP’s excessive-agency guidance supports limiting capabilities and enforcing authorization in downstream systems. An instruction telling the model to respect permissions is not sufficient enforcement by itself.
Test the capabilities the agent actually receives
Consider an assistant asked to summarize an email. The email contains an instruction to find confidential information and forward it elsewhere.
Does the summarizer have a sending capability? If it asks to send, would the service authorize that operation? Instructions inside the email do not grant authority from the user.
Give the task the smallest tool set and identity scope that supports its legitimate work. Apply the same reasoning to retrieval: “read-only” describes an operation; it does not establish whose information may be read.
Test the service directly: alter the resource identifier or tenant in an otherwise valid request. Check both the response and the resulting business state. The permission boundary must hold outside the expected conversation path.
Verify the environment behind the prompt
The episode uses teaching simulations to explore permission boundaries. Its fictional cross-tenant example is not evidence that a named vendor’s model shared memory across tenants.
Keep that example separate from documented evaluations. Anthropic’s published assessment describes cybersecurity evaluations in which models were told they lacked internet access, but a misconfiguration left access available. Those evaluations also lacked the cyber safeguards shipped with the released models.
The architecture question I take from that report is specific: does the environment enforce the scope described to the agent? Verify the relevant tool, network, and service controls. A prompt cannot establish network isolation.
Make stopping a useful outcome
When authorization cannot be established, preserve useful work: keep the draft, request missing information, or route the case for review. Record what was proposed, which check could not complete, and why execution did not proceed.
The workflow should not broaden its own permissions to finish the task.
Distinguish a rejected action from an unknown outcome. If a publishing call times out after submission, determine what the provider actually did before initiating a new operation. A missing response is not proof that no effect occurred.
Human approval also has a cost. Choose escalation rules according to impact, reversibility, and uncertainty. Test a legitimate action alongside the prohibited one, so the design demonstrates useful work as well as rejection.
Choose the prep asset for your next conversation
Preparing for a system design interview? Use the four-page Empower Interview Practice Guide. It includes a 20-minute drill, a worked answer, five interviewer challenges, a practice rubric, and a fillable answer worksheet.
PDF downloads are free with your AI Architect Circle account. Sign in or create a free account to access them.
Preparing a system design or architecture review at work? Use the separate five-page System Design & Architecture Review Prep Pack. Bring its worked action contract, validation cases, 30-minute review agenda, trade-off prompts, and fillable decision record to your team.
Choose one capability. Write its contract. Run a legitimate request, then change an approved parameter, change the tenant, or introduce an injected instruction. Inspect the service decision and the actual effect.
Your finished prep asset should explain what is permitted, where an unauthorized action stops, what happens under uncertainty, and who owns the remaining gaps.
Watch Empower and continue with the book
The 19-minute lesson was edited from the October 31, 2026 live session. It covers scoped tools, authorization, useful stopping states, and the trailer approval exercise. Editorial clarifications distinguish teaching simulations from documented evaluations.
For the broader framework and more detail, explore my book, System Design with AI Interview Guide, published by Apress.
Get the book on Amazon · Read on O’Reilly
Continue the series with AI Agent Security Starts Before the Agent Acts and AI Agent Hardening: Who Can Change Your Agent’s Authority?. Bring your next architecture or interview question to AI Architect Circle.
Before giving your agent another tool, make the permission for one existing action inspectable. What would you change after testing your action contract?
You approved a trailer for one territory, one channel, and one release window. Before publication, the asset changes.
Should the agent still publish it?
The approval was real. The request now in front of the system is different. An “approved” flag may have lost the information needed to recognize that difference.
Bring this question to your next system design interview or architecture review: what exactly was authorized, and which service checks that the action still matches?
I created two separate, free prep assets for this lesson: an Empower Interview Practice Guide for rehearsing your answer, and a System Design & Architecture Review Prep Pack for preparing a team decision. Both include fillable worksheets; you can download them below.
This is the Empower lesson in my LLM-SHIELD framework, from the October 31 AI Architect Circle session. A model can identify a useful next step. The architecture must establish whether that step is authorized. The trailer example is a fictional teaching scenario.
Define permission around one specific action
Start with the effect. Reading a document, changing a delivery address, and publishing a trailer carry different consequences.
For each action, define the actor, tenant, resource, operation, parameters, and permitted state. A trailer request might identify the asset version, territory, channel, and release window. A refund needs an amount and a specific transaction. An address change needs the order, proposed address, and state in which the change remains permitted.
These details form an action contract: a concrete description of what the system may do and under which conditions. The model’s confidence cannot supply a missing authorization decision.
Try this before your next review: replace “the agent can publish” with a sentence that names the exact asset, version, destination, and conditions.
Bind approval to the action the reviewer saw
Suppose a reviewer approves trailer A17, version 3. The execution queue later receives version 4 with the original approval reference.
The publishing service should detect that mismatch and preserve the draft for a new decision. An approval for version 3 does not cover a different version merely because the asset name looks familiar.
Approval binds to the reviewed action. A changed asset version needs a decision that covers the new request.
Make the approval’s scope, expiry, and revocation rules explicit. Define what happens if the channel changes, the release window closes, or the actor loses permission while the request waits.
Review question: what did the reviewer actually see, and how does the execution service prove that it is about to perform that same action?
Give each decision an enforcing owner
Separate these responsibilities so every check has a component that enforces it:
1. Propose: the model produces a structured request with explicit parameters.
2. Authorize: the policy or domain service checks the actor, resource, tenant, and applicable rules.
3. Approve when required: a reviewer approves the specific action and its conditions.
4. Execute: the execution service rechecks current authority and state before committing the effect.
5. Record: retain the decision and observed outcome so another engineer can inspect what happened.
A useful design names the service that rejects an unauthorized action and the state that remains when execution cannot proceed.
Explain how the service keeps its validation and commitment consistent. Depending on the system, that may require a conditional version check or transaction. Do not assume a request remains valid simply because it passed a check earlier.
OWASP’s excessive-agency guidance supports limiting capabilities and enforcing authorization in downstream systems. An instruction telling the model to respect permissions is not sufficient enforcement by itself.
Test the capabilities the agent actually receives
Consider an assistant asked to summarize an email. The email contains an instruction to find confidential information and forward it elsewhere.
Does the summarizer have a sending capability? If it asks to send, would the service authorize that operation? Instructions inside the email do not grant authority from the user.
Give the task the smallest tool set and identity scope that supports its legitimate work. Apply the same reasoning to retrieval: “read-only” describes an operation; it does not establish whose information may be read.
Test the service directly: alter the resource identifier or tenant in an otherwise valid request. Check both the response and the resulting business state. The permission boundary must hold outside the expected conversation path.
Verify the environment behind the prompt
The episode uses teaching simulations to explore permission boundaries. Its fictional cross-tenant example is not evidence that a named vendor’s model shared memory across tenants.
Keep that example separate from documented evaluations. Anthropic’s published assessment describes cybersecurity evaluations in which models were told they lacked internet access, but a misconfiguration left access available. Those evaluations also lacked the cyber safeguards shipped with the released models.
The architecture question I take from that report is specific: does the environment enforce the scope described to the agent? Verify the relevant tool, network, and service controls. A prompt cannot establish network isolation.
Make stopping a useful outcome
When authorization cannot be established, preserve useful work: keep the draft, request missing information, or route the case for review. Record what was proposed, which check could not complete, and why execution did not proceed.
The workflow should not broaden its own permissions to finish the task.
Distinguish a rejected action from an unknown outcome. If a publishing call times out after submission, determine what the provider actually did before initiating a new operation. A missing response is not proof that no effect occurred.
Human approval also has a cost. Choose escalation rules according to impact, reversibility, and uncertainty. Test a legitimate action alongside the prohibited one, so the design demonstrates useful work as well as rejection.
Choose the prep asset for your next conversation
Preparing for a system design interview? Use the four-page Empower Interview Practice Guide. It includes a 20-minute drill, a worked answer, five interviewer challenges, a practice rubric, and a fillable answer worksheet.
PDF downloads are free with your AI Architect Circle account. Sign in or create a free account to access them.
Preparing a system design or architecture review at work? Use the separate five-page System Design & Architecture Review Prep Pack. Bring its worked action contract, validation cases, 30-minute review agenda, trade-off prompts, and fillable decision record to your team.
Choose one capability. Write its contract. Run a legitimate request, then change an approved parameter, change the tenant, or introduce an injected instruction. Inspect the service decision and the actual effect.
Your finished prep asset should explain what is permitted, where an unauthorized action stops, what happens under uncertainty, and who owns the remaining gaps.
Watch Empower and continue with the book
The 19-minute lesson was edited from the October 31, 2026 live session. It covers scoped tools, authorization, useful stopping states, and the trailer approval exercise. Editorial clarifications distinguish teaching simulations from documented evaluations.
For the broader framework and more detail, explore my book, System Design with AI Interview Guide, published by Apress.
Get the book on Amazon · Read on O’Reilly
Continue the series with AI Agent Security Starts Before the Agent Acts and AI Agent Hardening: Who Can Change Your Agent’s Authority?. Bring your next architecture or interview question to AI Architect Circle.
Before giving your agent another tool, make the permission for one existing action inspectable. What would you change after testing your action contract?
Resources for this article
Put the lesson to work.
Practice defining exactly what an agent may do and where the system checks its authority.
Read the article freely. Sign in once for these PDFs; we’ll bring you back to this article’s resources. Newsletter updates are optional.
For your next interview
Interview Practice Guide
Explain scoped permissions, approvals and action contracts.
4 pages · Free member PDF
Get the interview guide ↓For your next design review
System Design & Architecture Review Prep Pack
Review delegated authority, execution checks and operational ownership.
5 pages · Free member PDF
Get the review pack ↓Go deeper with the book.
Use Part Two’s authority and commitment lenses to separate a recommendation from an authorized action. System Design with AI Interview Guide develops these ideas through methods, fundamentals and applied systems.