Teaching scenario: An assistant prepares a purchase order for a fictional team. The workflow, limits, and tests below are proposed design choices for this exercise.
Name the effect precisely“The agent can help with purchasing” is too broad to implement. List the effects separately: read an approved catalog, propose an order, save a draft, submit an order to a supplier, and cancel an order. Each effect has different consequences and may need different authority.
For this example, allow the assistant to prepare a draft using authorized catalog data. Submission requires a separate decision. A draft can be useful even when submission is unavailable, so keep those states visible in both the service and the interface.
Put enforcement at the actionBefore the order is sent, an enforcement component should check the authenticated requester, organization, permitted supplier, approved items, amount, and any required approval. These checks belong in the execution path, outside the model's assertion that the action is safe.
OWASP's agent security guidance recommends scoped tools, independent authorization for consequential actions, and controls against approval bypass. Those principles inform this example; the exact limits and approval policy belong to the organization operating the system. Primary reference: OWASP AI Agent Security.
The model can propose an action and explain its reasoning. The executing service decides whether the proposal is allowed under the current policy. If the model lacks authority to change a limit, a persuasive explanation must not change that result.
Bind approval to the proposalA person approves an order for ten units from Supplier A. After approval, retrieved content suggests a different supplier endpoint. The application must not silently treat the earlier approval as permission for the altered order.
Store the approved action details, the approver, relevant resource versions, and the validity conditions. Immediately before execution, compare the current proposal with those approved details. A changed recipient, destination, amount, or material item should trigger the policy's required revalidation. Approvals should not be reusable permission slips for arbitrary later actions.
Check
Evidence in this exercise
If it fails
Requester may order for this team
Current authenticated organization and role
Preserve the draft and deny submission
Proposal matches the approval
Approved supplier, items, amount, and version
Request review of the changed proposal
Destination is permitted
Supplier destination validated by the executing service
Stop before the external request
Approval is still valid
Current approval state and validity window
Return to review
Result is established
Provider response or reconciliation evidence
Preserve an unknown outcome for investigation
Decide degraded behavior in advanceSuppose the verification service is unavailable. An acceptable policy for this exercise is to retain the draft, explain that submission is paused, and allow a later retry of verification. The application must not expand its authority simply to keep the workflow moving.
If verification recovers, repeat the checks against the current proposal. If submission itself times out, use the unknown-outcome approach: determine whether the external order exists before creating a second effect. “Waiting for verification” and “submission outcome unknown” describe different problems and should not share one generic failure message.
Collect evidence a reviewer can examineTest an approved proposal, an altered supplier, an expired approval, a requester from a different organization, and an unavailable verification service. In the provider simulator, count external submissions and inspect their parameters. For denied or paused actions, the expected count is zero; the draft should remain available.
Keep an audit record with operation identifiers, policy version, authorization result, approval reference, and outcome. Include only the data needed to explain and investigate the decision; avoid copying sensitive document contents into every log entry.
For an interview: Mark the point in the sequence where a proposal becomes an external effect. Explain what is checked there. For a team: Complete the Agent Action Review Worksheet with the product owner and the person accountable for operations. The design is stronger when someone can state what the agent may do, what stops it, and how an uncertain action is resolved.
Teaching scenario: An assistant prepares a purchase order for a fictional team. The workflow, limits, and tests below are proposed design choices for this exercise.
Name the effect precisely“The agent can help with purchasing” is too broad to implement. List the effects separately: read an approved catalog, propose an order, save a draft, submit an order to a supplier, and cancel an order. Each effect has different consequences and may need different authority.
For this example, allow the assistant to prepare a draft using authorized catalog data. Submission requires a separate decision. A draft can be useful even when submission is unavailable, so keep those states visible in both the service and the interface.
Put enforcement at the actionBefore the order is sent, an enforcement component should check the authenticated requester, organization, permitted supplier, approved items, amount, and any required approval. These checks belong in the execution path, outside the model's assertion that the action is safe.
OWASP's agent security guidance recommends scoped tools, independent authorization for consequential actions, and controls against approval bypass. Those principles inform this example; the exact limits and approval policy belong to the organization operating the system. Primary reference: OWASP AI Agent Security.
The model can propose an action and explain its reasoning. The executing service decides whether the proposal is allowed under the current policy. If the model lacks authority to change a limit, a persuasive explanation must not change that result.
Bind approval to the proposalA person approves an order for ten units from Supplier A. After approval, retrieved content suggests a different supplier endpoint. The application must not silently treat the earlier approval as permission for the altered order.
Store the approved action details, the approver, relevant resource versions, and the validity conditions. Immediately before execution, compare the current proposal with those approved details. A changed recipient, destination, amount, or material item should trigger the policy's required revalidation. Approvals should not be reusable permission slips for arbitrary later actions.
Check
Evidence in this exercise
If it fails
Requester may order for this team
Current authenticated organization and role
Preserve the draft and deny submission
Proposal matches the approval
Approved supplier, items, amount, and version
Request review of the changed proposal
Destination is permitted
Supplier destination validated by the executing service
Stop before the external request
Approval is still valid
Current approval state and validity window
Return to review
Result is established
Provider response or reconciliation evidence
Preserve an unknown outcome for investigation
Decide degraded behavior in advanceSuppose the verification service is unavailable. An acceptable policy for this exercise is to retain the draft, explain that submission is paused, and allow a later retry of verification. The application must not expand its authority simply to keep the workflow moving.
If verification recovers, repeat the checks against the current proposal. If submission itself times out, use the unknown-outcome approach: determine whether the external order exists before creating a second effect. “Waiting for verification” and “submission outcome unknown” describe different problems and should not share one generic failure message.
Collect evidence a reviewer can examineTest an approved proposal, an altered supplier, an expired approval, a requester from a different organization, and an unavailable verification service. In the provider simulator, count external submissions and inspect their parameters. For denied or paused actions, the expected count is zero; the draft should remain available.
Keep an audit record with operation identifiers, policy version, authorization result, approval reference, and outcome. Include only the data needed to explain and investigate the decision; avoid copying sensitive document contents into every log entry.
For an interview: Mark the point in the sequence where a proposal becomes an external effect. Explain what is checked there. For a team: Complete the Agent Action Review Worksheet with the product owner and the person accountable for operations. The design is stronger when someone can state what the agent may do, what stops it, and how an uncertain action is resolved.
Put this lesson to work.
Download the PDF worksheet to use in your next practice session or design review. It is free with your AI Architect Circle account.