Scope of action
A clinician's privileges name what they may do — not what they may not. An agent's scope works identically: a finite, written list of permitted action types. Anything not on the list is a breach by definition, which is what makes the list enforceable by software rather than by hope.
Writing a scope that can be enforced
Scopes fail when written as prose ("assists with prior
authorization workflows") and work when written as verbs on objects:
draft_pa_request, submit_pa_request,
check_pa_status. Three tests for each entry: an engineer
could log it unambiguously; a reviewer could recognize a violation
without interpretation; and removing it would meaningfully reduce what
the agent does. If an entry fails any test, split it until it passes.
The autonomy axis
Scope says what; autonomy says how unsupervised. Three levels cover practice: suggest (agent drafts, a human executes), supervised (agent acts, a human reviews on a defined cadence), autonomous (agent acts unreviewed). Privileges are granted per scope-entry at a stated level — an agent can be autonomous for status checks and supervised for submissions. Escalating autonomy is a privileging decision with a named grantor, never a configuration change.
The vendor conversation
Ask the vendor for the complete list of actions the agent can technically perform — not the marketed list. The gap between the two is your risk surface: an agent that can modify orders but is only marketed for drafting them needs the modification pathway either disabled or explicitly scoped and audited. A vendor unable to produce the technical action list is telling you the agent cannot yet be governed.