Before an AI agent acts, decide who owns its authority

The hardest AI-governance question is often not “Can the model answer correctly?” It is “What can the system change, under whose authority, and how would we recover if it acts incorrectly?”

Use this worksheet to make that decision explicit. It is an original JLS practitioner aid, not an industry standard, certification, compliance determination or scoring model. Apply it to one defined workflow at a time.

Start with the action, not the product label

Describe the consequential action in plain language. “An agent helps finance” is too broad. “The agent drafts a vendor payment recommendation; a named employee approves it; the agent cannot release funds” exposes the actual boundary.

Capture the business purpose, systems touched, information accessed, actions permitted, approval owner and recovery owner. Separate read access from write access. Separate recommendations from external commitments.

An authority matrix to complete before launch

Action boundary	Evidence to request	Approval and recovery decision
Read and summarize approved information	Source permissions, data handling and evaluation against representative inputs	Who approves the data scope and can revoke access?
Draft a change for human review	Clear draft labeling, review procedure and separation from submission tools	Who reviews the draft, and what prevents automatic execution?
Execute a bounded, reversible change	Narrow tool permissions, validated limits, activity logs and tested reversal	What limits are enforced outside the model, and who can stop the workflow?
Create an external commitment or high-impact result	Explicit authority, independent authorization checks, relevant legal/risk review and incident procedure	Which actions require human authorization or must remain outside the agent’s authority?

The rows are not automatic maturity levels. A lower-risk action does not grant permission for a higher-risk one. Some actions should remain unavailable regardless of model performance.

Record the decision

For each proposed capability, complete this short record:

Purpose and owner: the business result and the person accountable for it.
Access and actions: exact information, systems and operations allowed; explicit exclusions.
Evidence: the evaluation, permission tests and recovery exercise supporting the decision.
Acceptance: who accepted the remaining risk, under which limits and until what review date.
Change triggers: supplier, model, tool, data, permission or business-process changes that require reassessment.
Stop and recover: who can intervene, what is disabled and how the activity record is preserved.

A useful record can say “not approved.” Missing evidence is not the same as a failed control, but neither supports silently expanding authority.

Walk through a payment example

An organization wants an agent to reduce manual invoice handling. Its first approved scope might be extracting invoice details and drafting a match recommendation from approved records.

Before allowing write access, management would need to define which fields can change, enforce those permissions independently, test conflicting and incomplete invoices, establish review rules and demonstrate recovery. Permission to update a draft does not imply permission to change bank details, approve a vendor or release funds.

This is an illustrative workflow, not a JLS client result or a universal payment-control design.

Make expansion an explicit decision

Review actual exceptions, incidents and outcomes before widening the action boundary. Confirm that the person accountable for the workflow understands the changes—not only that the engineering team can make them.

The NIST AI Risk Management Framework can inform a broader risk-management program. This worksheet focuses on the narrower operating decision about authority and evidence.

For the service context, read JLS AI governance. If a discussion is needed, use the existing strategic technology session; do not submit sensitive information through the public form.