Skip to main content

GOVERNANCE RECORD

Agent Authorization Document

No platform ships this document. Every AI governance framework requires it. The Agent Authorization Document is the organizational record that answers the question no control plane can answer: who formally decided what this agent is authorized to do, and whose name is on that decision.

v1.5 · August 2026Sougata Roy, sougataroy.com

Free to read and cite with attribution to Sougata Roy and sougataroy.com. Do not republish, rebrand, or claim authorship of any framework, term, or model as your own.

Document preview

Agent Authorization Record

Complete one record per deployed agent. Retain as a governance artifact.

AGENT NAME

The display name used in the agent registry, admin center, or internal inventory.

BUSINESS PURPOSE

One to three sentences explaining the problem this agent solves and the workflow it supports.

AUTHORIZED ACTIONS

List each action the agent is permitted to take, using precise language tied to specific systems or workflows.

EXPLICIT PROHIBITIONS

List what the agent must not do. If this field is blank, the authorization record is incomplete.

DATA ACCESS SCOPE

Name the systems, libraries, sites, datasets, or applications the agent can read from and write to.

BUSINESS SPONSOR

Full name and title of the named human the organization maps from the Sponsor role in Microsoft Entra Agent ID. The platform Sponsor can be a user or supported group accountable for purpose, lifecycle decisions, and access reviews; this record requires one named accountable human for the business authorization decision.

TECHNICAL OWNER

Full name and title of the administrator responsible for this agent's operational management, permissions, and identity configuration. Maps to the Owner role in Microsoft Entra Agent ID. Not the approving authority.

REVIEW TRIGGER CONDITIONS

Describe the events that require re-authorization, such as a change in purpose, data access, ownership, regulation, or an incident.

NEXT SCHEDULED REVIEW DATE

Set the date when the organization will confirm the record is still accurate and complete.

AUTHORIZATION SIGNATURE

Capture the approving person's name, title, and date. This should be the accountable business owner, not only the developer or IT administrator.

Type

Governance record

Version

v1.5

Published

August 2026

Time to use

20 min per agent

Audience

Agent owners, risk, security, and compliance teams

Output

One completed authorization record

Use this first

Complete one record per deployed agent and retain it as governance evidence.

Primary object

Agent Authorization Record Preview

Use as a working artifact

Primary object

Capture identity, authorized scope, accountability, review, and approval in one dated record.

Agent identity

Authorized purpose

Permitted actions

Named owner

Review cadence

Approval evidence

Standing trigger

View completed example

Limitation

This object can record an authorization decision and its evidence. It cannot prove that the agent behaved within scope, that the record is complete for every deployment, or that the approval was substantively wise.

Revision history

v1.5, August 2026: Added the standing trigger clause as section 05 of the record, covering unattended runs started by timers, schedules, and external events. Introduced in the August 11, 2026 newsletter edition. Record fields 01 through 04 unchanged.

Copyable citation

Sougata Roy, "Agent Authorization Document," v1.5, August 2026, https://sougataroy.com/frameworks/agent-authorization-document

Why this document exists

Why this document exists

Microsoft Entra Agent ID gives agents an identity. Within it, a Sponsor records the user or supported group accountable in the platform for an agent's purpose, lifecycle decisions, and access reviews, and an Owner is the technical administrator responsible for configuration and operations. The platform permits a group in that role; this record requires the organization to map it to one named accountable human. Neither role documents what the agent was formally authorized to do before it was deployed. Microsoft Purview helps organizations search and retain audit evidence for AI activity. Those systems help answer what an agent did, when it acted, and what resources it could reach. They do not capture the business authorization decision that should exist before an agent is deployed.

Active reason
Choose a reason
Item 1 of 4

Platform evidence

The platform records identity, permissions, and activity. It does not record the organizational decision that authorized the agent to operate. That decision requires a separate document.

The document

Agent Authorization Record

Complete one record per deployed agent. Retain as a governance artifact.

Agent Authorization Record

Complete one record per deployed agent. Retain as a governance artifact.

01, IDENTIFICATION

AGENT NAME

The display name used in the agent registry, admin center, or internal inventory.

BUSINESS PURPOSE

One to three sentences explaining the problem this agent solves and the workflow it supports.

02, AUTHORIZATION SCOPE

AUTHORIZED ACTIONS

List each action the agent is permitted to take, using precise language tied to specific systems or workflows.

EXPLICIT PROHIBITIONS

List what the agent must not do. If this field is blank, the authorization record is incomplete.

DATA ACCESS SCOPE

Name the systems, libraries, sites, datasets, or applications the agent can read from and write to.

03, ACCOUNTABILITY

BUSINESS SPONSOR

Full name and title of the named human the organization maps from the Sponsor role in Microsoft Entra Agent ID. The platform Sponsor can be a user or supported group accountable for purpose, lifecycle decisions, and access reviews; this record requires one named accountable human for the business authorization decision.

TECHNICAL OWNER

Full name and title of the administrator responsible for this agent's operational management, permissions, and identity configuration. Maps to the Owner role in Microsoft Entra Agent ID. Not the approving authority.

04, REVIEW AND APPROVAL

REVIEW TRIGGER CONDITIONS

Describe the events that require re-authorization, such as a change in purpose, data access, ownership, regulation, or an incident.

NEXT SCHEDULED REVIEW DATE

Set the date when the organization will confirm the record is still accurate and complete.

AUTHORIZATION SIGNATURE

Capture the approving person's name, title, and date. This should be the accountable business owner, not only the developer or IT administrator.

05, STANDING TRIGGERS

The Standing Trigger Clause

An agent that runs on a schedule was authorized once. The schedule that wakes it was not.

Most authorization records approve an agent and stop there. When that agent runs unattended on a timer, a cron schedule, or an external event, a second decision exists and is almost never written down: who decided the run should happen, why it must happen without a person present, and when anyone will ask whether it still should. Complete this section once per standing trigger attached to the agent.

TRIGGER DEFINITION

The timer, schedule, or external event that starts an unattended run, recorded in the form the platform stores it, together with the action it starts.

CONSEQUENCE OWNER

Full name and title of the person accountable for what the unattended runs cause. Distinct from the Technical Owner who configured the trigger and from the Business Sponsor who approved the agent.

ACTIVATION JUSTIFICATION

One sentence stating why this run must occur without a person present, and what fails if it does not.

TRIGGER REVIEW DATE

The date the organization will confirm the run still needs to exist. Separate from the agent's Next Scheduled Review Date, because an agent can remain justified while a schedule attached to it no longer is.

Two operating rules

Orphaned triggers. A standing trigger whose Consequence Owner has left the organization is treated as an unauthorized deployment from the date of departure, suspended until a new owner signs. Reassigning the agent does not carry the trigger. Authority to run and authority to begin running are separate grants, and this section records the second one.

Offboarding. The offboarding checklist lists every standing trigger the departing person configured and reassigns each by name before final-day access is removed. A trigger that reaches the departure date unassigned is suspended, not inherited.

Limitation

This section records who authorized a run to begin and when that authorization expires. It cannot prove the run still serves the purpose stated, and it does not surface triggers the organization has never enumerated.

The standing trigger clause was introduced in The Governance Gap, "The Agent Was Authorized. The Schedule Never Was.", August 11, 2026.

ROLE MAPPING

Where the other named roles live.

The Consequence Owner named across this framework library maps to the Business Sponsor field in this record. For a Tier 2 agent (tier definitions in Who Owns the Agent?, DOI 10.5281/zenodo.20481551) they are typically the same individual. For a Tier 3 agent with external communications, financial transaction execution, or record modification authority in regulated systems, the Consequence Owner is a distinct individual at a higher level of the accountability structure, and their name is recorded in the Business Sponsor field with the Tier 3 distinction noted. The Accuracy Owner and the Suspension Authority required by the Disposition Protocol are recorded in this document's accountability group as two additional named entries when the agent operates under a Disposition Protocol, which every production agent should. One record. Every named role in it. Role consolidation scales the model. For a Tier 1 agent, one named individual may hold Business Sponsor, Consequence Owner, Accuracy Owner, and Suspension Authority together, provided the record names them in each capacity. For Tier 2, the Suspension Authority must be a different individual from the Accuracy Owner, because the person who raises the signal should not be the only person who can act on it. For Tier 3, all roles are distinct named individuals and the Consequence Owner sits at a level with board access. Five role names describe five obligations, not five headcount. For large Tier 3 portfolios, the Consequence Owner may own a defined class of agents rather than a single one, with the record still naming them on each agent, and the roles map onto existing titles, the Accuracy Owner to the head of model risk, the Suspension Authority to operations leadership, rather than creating new headcount.

RECORD INTEGRITY

A record that cannot prove its own date is not evidence.

The value of this document is that it predates the incident, and predating must be provable. Store the completed record in a system that timestamps creation and preserves versions immutably, such as a document management system with retention holds or a repository with a signed commit history. A record that can be silently edited or backdated satisfies every field in this template and fails the only test that matters. When an examiner asks whether the authorization preceded the deployment, the storage system answers, not the author. Retention follows the strictest obligation that applies to the agent's context, and a record under legal hold is preserved regardless of schedule.

AGENT AUTHORIZATION SEQUENCE

Agent Authorization Sequence FlowAgent Authorization SequenceThe authorization record is the evidentiary artifact.Without it, the deployment exists but the decision does not.Most organizations have no formal recordof owner assignment, authorization, and approval.01Request SubmittedBusiness need identified02Use Case DocumentedScope and boundaries defined03Human Owner AssignedNamed individual, not a team04Authorization Record CreatedFormal approval documented05Deployment ApprovedOrganizational sign-off recorded06Agent Registered in TenantDisplay name matched to record07Review Trigger SetCondition or date establishedDeployment is reportable only when every decision has a durable record.

How to use this document

How to use this document

Complete one record per deployed agent and keep it beside the technical inventory that tracks identity, access, and audit evidence.

Active step
Choose a step
Item 1 of 4

Create the record

Complete one record for every agent currently deployed in your environment, starting with agents that can reach sensitive data, customer records, or financial systems.

Download the document

Use it as a governance artifact, not a marketing asset

The template is a base, meant to be adapted into the organization's own GRC forms, not adopted verbatim. No gate. No form. Free to read and cite. Use in your own work with attribution to Sougata Roy and sougataroy.com.

This template is informed by accountability and oversight expectations in NIST AI RMF, OMB M-25-21, FINRA's 2026 Regulatory Oversight Report, and Article 26 of the EU AI Act. Free to read and cite. Use in your own governance work with attribution to Sougata Roy and sougataroy.com. Do not republish, rebrand, or claim authorship of the template as your own.

REVISION HISTORY

What changed in this document

v1.5, August 2026: Added the standing trigger clause as section 05 of the record, covering unattended runs started by timers, schedules, and external events. Introduced in the August 11, 2026 newsletter edition. Record fields 01 through 04 unchanged.

v1.4, August 2026: Added a related-work reference to the Vendor Authorization Record, a v0.1 vendor-governance concept note, in Related Frameworks.

v1.3, July 2026: fact corrections verified against primary sources; clarified Microsoft Entra Agent ID Sponsor and Owner platform-role precision.

v1.2, July 2026: Added role consolidation guidance, record retention handling, and template adaptation language.

v1.1, July 2026: Added role mapping for Consequence Owner, Accuracy Owner, and Suspension Authority, and added record integrity guidance for timestamped authorization evidence.

v1.0, April 2026: Original publication.

COPYABLE CITATION

Cite this clause

Sougata Roy, "The Standing Trigger Clause," Agent Authorization Document v1.5, August 2026, https://sougataroy.com/frameworks/agent-authorization-document#standing-trigger-clause