Start with the action, not the model
A capable model does not establish permission to act. List the resources an agent needs, the actions it can take, and the conditions under which those actions are allowed. Reading a document, changing a record, and sending a message are different permissions.
Make the authority traceable
Record the business owner, technical maintainer, identity, permitted tools, and approval gates. Distinguish actions taken with a user’s delegated authority from those taken with an application or agent identity. The distinction affects access decisions and evidence.
Test the boundary
Verify allowed actions and denied actions. Include revoked access, unavailable tools, unexpected input, and actions requiring review. A successful demonstration should not be the only test of an agent.
Plan for ownership to change
Assign a review cadence and a retirement path. When a sponsor leaves or the workflow changes, someone must decide whether the agent still needs its access. Useful autonomy requires an authority model that can change.
This note describes an architecture approach, not a compliance certification or a customer case study.