Before an agent goes live, define what it is allowed to do.

Start with a constrained use. ASD's careful-adoption guidance recommends restricting agentic AI to low-risk, non-sensitive situations. If the proposed boundary cannot be made appropriate for the use, do not release it, and consider a less autonomous approach or the specialist work needed first.

Purpose and accountable owner. Can the owner explain the outcome, users, context, included actions and exclusions? Who operates the system, accepts the release and can stop it? Bring a written use-case boundary and responsibility map approved by the relevant owners.

Information and permissions. What can the agent read, retrieve, write, send, delete or purchase, and which identities and systems does it reach? Permissions should be limited to the task rather than inherited from a powerful user's whole session. Bring the implemented permission map, the identity owner and the access-removal process, with technical validation.

Meaningful action approval. Which actions require a person to review the exact proposed change, and does the reviewer see enough context, including the recipient, record, amount or information affected? Restrictions should be enforced outside the model where appropriate. Bring evidence that unapproved and prohibited actions are blocked.

Untrusted content and failures. What happens when a document, message or tool response contains hostile instructions, or when records are missing, information contradicts, a tool fails repeatedly or a dependency is unavailable? No single filter or prompt establishes immunity to prompt injection. Bring representative and adversarial test results, unresolved findings and the specialist assessment of residual exposure.

Output acceptance needs an independent judge. Someone has to define a correct result, and testing should include normal, difficult and stop-or-escalate cases. The same model approving its own output is not independent verification. Bring an evaluation set, acceptance criteria, observed errors and the limits of what the test proves.

Monitoring, interruption and recovery decide what happens when something goes wrong. Authorised operators need to identify the request, system version, action and outcome, and to interrupt operation and revoke access. Define a fallback the organisation can execute, remembering that some actions cannot be fully reversed once information is disclosed or a message sent.

Operating cost and change are part of the same decision. Establish who maintains the system and handles exceptions, what the usage, support and review costs are, and which changes require reassessment. A low model price does not establish a low cost per accepted outcome, so compare the complete process with a simpler alternative.

Two contrasts show what the checklist is testing.

Permissions: an agent whose access is scoped to the task is a different proposition from one that inherits a powerful user's whole session. The stated purpose can be identical while the exposure is not.

Approval design: an instruction to ask before doing anything risky is not a complete permission design. A meaningful approval shows the reviewer the exact proposed change, including the recipient, record, amount or information affected, and blocks the prohibited action outside the model.

Record the decision in one of four forms: approved within a defined boundary, approved subject to specified actions, not approved, or more evidence required. Identify the triggers for re-review, including new tools, permissions, information, users or autonomy.