Practical guides / Agent governance

Who can authorize an AI agent to act?

A practical AI agent governance example covering human accountability, bounded actions, identity, approval, failure tests and revocation.

Operational ITAM · Practical guidance · September 21, 2026

  1. Name the owner
  2. Bound the action
  3. Test refusal
  4. Approve release
  5. Prove revocation
A decision sequence to adapt to your own operating environment.

An agent needs authority as well as an identity

Knowing which service identity made a request does not prove that the requested action was permitted. Name the human accountable for the use case, define the resources and actions within scope, and record who may approve changes. A broad role such as “AI team” does not establish a decision boundary.

Describe a bounded action

An agent might be allowed to prepare a proposed purchase request for review, but not submit an order or change bank details. State the action, permitted systems, data scope, transaction limits where relevant, and the conditions requiring human approval. Separate read, draft, approve and execute permissions.

Test what must be refused

A useful test suite includes allowed work and prohibited work. Try an out-of-scope record, an expired approval and a repeated request. Verify that refusal leaves evidence and reaches an accountable person when escalation is needed. A demonstration that the happy path works is not sufficient authority evidence.

A compact example

An agent drafts an asset-recovery ticket after a leaver event. It may read the approved asset assignment and draft the ticket. It may not disable unrelated accounts, erase a device or close the ticket as recovered. Those actions remain with separately authorized workflows. A replayed event should not create an uncontrolled series of duplicate actions.

Prove the ending

Test how to revoke the agent identity, invalidate delegated access and stop queued work. Preserve records needed for investigation and continuity. Recheck authority after tool, model, integration or use-case changes. Approval for yesterday’s bounded workflow is not blanket approval for new capabilities.

Source context

Methods can be adapted internationally. The paid collection’s jurisdiction-specific operating guidance centers on the United States and Canada; apply local requirements and actual contracts. Examples are illustrative, not guaranteed savings or certification.

Browse free starter resources · All practical guides