Updated 17 October 2026. An agent’s most important boundary is often the point where a suggestion becomes an action. That transition deserves a product decision, not an accidental default.
Design the moment of action
Identify what the system can change outside the conversation. Sending a message, updating a record and requesting a payment have different consequences. Document the scope at the level needed to distinguish permitted from disallowed behaviour.
An illustrative agent may prepare a draft freely but require approval before sending it. Bind the approval to the actual recipient and content. If either changes materially, the system should follow the defined review process rather than treating the earlier approval as unlimited permission.
Test the refusal path as carefully as the permitted path. Does the system stop when approval is absent? Does it explain what is needed next? Can a user continue through an authorised alternative without being encouraged to bypass the boundary?
Then test the outcome. An action request, an accepted request and a completed change are different states. The interface should not announce completion merely because the request left the agent.
| Question | Evidence or action |
|---|---|
| Before action | Scope and approval conditions |
| At action | Enforced permission decision |
| After action | Observed result and recovery path |
The practical next step
Choose one consequential action and trace it through the product. The exercise often makes a vague governance discussion concrete within minutes, which is more than most committees can claim.
Keep the resulting decision, its owner and unresolved questions in a short decision record. For claims about agent behaviour, connect the decision to evaluation evidence rather than relying on a successful demonstration alone.
Further primary reading: NIST AI Risk Management Framework. The review map and product recommendations above are my analysis, not a certification or a legal assessment of a particular deployment.
