Control 3.1 — Portal Walkthrough: Agent Inventory and Metadata Management

Control ID: 3.1 Pillar: Reporting (Foundation) Playbook Type: Portal Walkthrough (Admin Center UI) Last UI Verified: April 2026 Estimated Time: 12–20 hours initial baseline build; 4–6 hours per quarterly attestation cycle thereafter Audience: AI Governance Lead, AI Administrator, Power Platform Admin, Entra Agent ID Admin, Entra Global Reader, Purview Compliance Admin, Purview Records Manager, SharePoint Admin, Compliance Officer, Designated Supervisor / Registered Principal, CISO observer Prerequisites: Pre-flight gates PRE-01 through PRE-05 (see §2) completed and evidenced; canonical metadata schema (§1.2) ratified by the AI Governance Council; SharePoint registry-of-record library provisioned and bound to a Purview retention policy

READ FIRST — Scope and routing

This walkthrough is the portal-driven operating procedure for the canonical agent register that every other Pillar 3 control consumes. It covers click-paths, evidence anchors, lifecycle-state procedures, and the quarterly attestation workflow across the six discovery planes enumerated in §0.3. It produces the stitched system of record that feeds Controls 3.2, 3.4, 3.6, 3.8, 3.9, 3.11, and 3.13.

Use the sibling playbooks for adjacent work:

If you need…	Use this sibling
Bulk export, scheduled reconciliation, SHA-256 hashing, idempotent diffing	PowerShell Setup
Pre-attestation readiness checks, evidence validation, audit-pack completeness	Verification & Testing
Stale exports, owner mismatches, missing-portal symptoms, sovereign-cloud surface gaps	Troubleshooting
Live-incident response when an inventory review surfaces an active high-risk or mis-scoped agent	AI Incident Response Playbook
The "why" — regulatory mapping, zone tiering, related controls	Control 3.1 specification

This is not… the surface that authors any of the following. Each row tells you where the authority actually lives:

If you are looking for…	Go to…
Agent registration, intake form, approval workflow	Control 1.2 — Agent Registry and Integrated Apps Management
Audit-log pipeline, UAL retention, Sentinel ingestion	Control 1.7 — Comprehensive Audit Logging
Records Management, Preservation Lock, SEC 17a-4(f) WORM binding	Control 1.9 — Records Management and Preservation Lock
eDiscovery case authoring, custodian holds, evidence preservation	Control 1.19 — eDiscovery for Agent Interactions
Adversarial-input detection and incident telemetry	Control 1.21 — Adversarial Input Logging
Managed Environments, environment classification, DLP grouping	Control 2.1 — Managed Environments
Validation evidence, regression testing, model-swap re-validation	Control 2.5 — Testing, Validation, and Quality Assurance
Conflict-of-interest evaluation, comparative monitoring	Control 2.11 — Bias Testing and Fairness Assessment
Orphan workflow execution, departed-owner remediation	Control 3.6 — Orphaned Agent Detection
Tenant-wide governance dashboard and reporting	Control 3.8 — Copilot Hub and Governance Dashboard
Inventory-enforcement gating (publish blocks on incomplete metadata)	Control 3.11 — Centralized Agent Inventory Enforcement
SharePoint grounding-source inventory and oversharing remediation	Control 4.6 — Grounding Scope Governance and Control 4.7 — Microsoft 365 Copilot Data Governance

Hedged-language reminder

Maintaining this inventory helps support compliance with FINRA Rule 4511 (books-and-records), FINRA Regulatory Notice 25-07 (AI/predictive-analytics supervision), SEC Rule 17a-3(a)(17) and 17a-4(b)(4) (six-year preservation), SOX Sections 302/404 (internal control over financial reporting), GLBA 501(b) (administrative safeguards inventory), OCC Bulletin 2011-12 / Federal Reserve SR 11-7 (model inventory and ongoing monitoring), CFTC Rule 1.31 (recordkeeping), NYDFS 23 NYCRR Part 500.13 / 500.16 / 500.17 (asset inventory and incident response), NIST AI RMF GOVERN 1.6, and FTC Safeguards Rule 16 CFR §314. It does not by itself satisfy any obligation. Inventory completeness, attestation timeliness, owner accountability, and evidence integrity are operational disciplines — not one-click settings.

Prohibited overclaims for this control (do not write into your WSP, attestation memo, or examiner cover letter): "complete inventory", "real-time discoverability", "guarantees agent visibility", "single pane of glass", "ensures lineage", "automatic enrollment", "zero shadow AI", "zero blind spots", "eliminates orphan risk", "will prevent unauthorized agents".

Mandatory hedged substitutes: helps support / required for / aids in / contributes to / supports / is intended to / organizations should verify / authoritative system of record fed by multiple discovery surfaces and periodic reconciliation.

License Requirements

Verify SKU and preview availability at deploy time against current Microsoft Learn licensing guidance and your tenant Message Center. Per-surface floor:

Microsoft 365 Copilot (E3/E5 + Copilot license) — required for the Microsoft 365 Copilot Hub Inventory surface (Plane 1) and Copilot Studio agent metadata surfacing.
Power Platform per-app / per-user / Process licenses — entitlement metadata flows into the Plane 2 export; Managed Environments is required to surface environment-level governance attributes (see Control 2.1).
Microsoft Entra ID P1 (P2 recommended for PIM-elevated reads of Enterprise App registrations and the emerging Agent Registry blade).
Microsoft Purview Audit (Standard or Premium) — required for retention of registry-mutation events; Premium is recommended for Zone 3 long-horizon (≥ 1 year) audit retention.
Microsoft Purview Records Management — required for Preservation Lock on the registry document library when the firm treats the registry export as a SEC 17a-4(f)-format record.
Microsoft Sentinel (Control 3.9) — required for cross-surface registry-deviation alerting (orphan, dormant, drift).
Microsoft Agent 365 (Plane 4) — preview-to-GA across 2026; verify entitlement and per-cloud availability before relying on it as a primary evidence source. Treat as additive, not authoritative, while in preview.
SharePoint Premium — may be required for some Plane 6 Connected Apps export and Data Access Governance (DAG) report exports; verify in your tenant.

Sovereign cloud parity (verify at deploy time)

Cross-cloud parity is not symmetric — verify at deploy time. The matrix below reflects the field as of April 2026 and is subject to change in any monthly release.

Surface / capability	Commercial	GCC	GCC High	DoD	21Vianet (Gallatin)
M365 Copilot Hub Inventory (Plane 1)	GA	GA	Lagging — verify	Lagging — verify	N/A
Power Platform Admin Center inventory (Plane 2)	GA	GA	GA — some columns lag	GA — some columns lag	Limited
Entra Enterprise Apps (Plane 3)	GA	GA	GA	GA	GA
Entra Agent Registry blade (preview)	Preview	Verify	Verify	Verify	Verify
Agent 365 Admin Center (Plane 4)	Preview / Frontier	Limited / verify	Likely not at first GA	Likely not at first GA	N/A
Purview retention binding (Plane 5)	GA	GA	GA — verify per release	GA — verify per release	Limited
SharePoint Connected Apps + DAG (Plane 6)	GA	GA	Rolling — verify	Rolling — verify	Limited
Programmatic agent inventory APIs / Graph exports	Rolling	Rolling — verify	Verify	Verify	Limited

Treat any parity gap as a compensating-control conversation, documented in the §1.5 sovereign-cloud determination memo and in the quarterly attestation memo. Do not assume feature equivalence across clouds.

§0. Coverage boundary, registry-plane inventory, and portal-vs-PowerShell decision matrix

This section sets the operational boundary of the walkthrough and tells the operator when to switch to automation.

0.1 What this playbook covers

Configuration and quarterly attestation of the canonical agent register across all six portal surfaces (the "discovery planes").
Authoring and validation of the canonical metadata schema (§1.2) for every agent record.
Lifecycle state transitions (Draft → In Review → Approved → Active → Deprecated → Decommissioned) executed via portal procedures with audit-log capture.
Orphaned-agent identification (departed-owner, dormant beyond zone threshold, unowned shared agent, license-stripped) using the Microsoft 365 admin center "Manage Ownerless" action and equivalents in PPAC, Entra, and Agent 365.
DLP-policy mapping verification per inventory entry, including the cross-plane reconciliation between Purview DLP for Microsoft 365 Copilot and Power Platform data policies for Copilot Studio.
Sensitivity-label inheritance check per registry entry against grounding sources (SharePoint sites, OneDrive containers, Dataverse tables, web URLs).
Zone-specific portal workflows with differentiated metadata depth, attestation cadence, and approval chains for Zone 1 / Zone 2 / Zone 3.
Quarterly attestation procedure with the three-signature workflow (Inventory Owner → AI Governance Lead → Compliance Officer).
Examiner audit-pull procedure for FINRA Rule 8210, OCC examination, Federal Reserve SR 11-7, SEC inquiry, NYDFS 500.13, and CFTC Rule 1.31, including point-in-time snapshot reconstruction and chain-of-custody record.
Sovereign-cloud caveats per surface, with compensating-control language for surfaces not yet GA in your cloud.
Connection to downstream controls that consume the register on the canonical AgentID join key.

0.2 What this playbook does NOT cover

Out of scope here	Where it lives
Agent intake form, approval workflow, registry of approved agents	Control 1.2
Unified Audit Log enablement, Sentinel ingestion, SIEM correlation rules	Control 1.7
Sensitivity-label authoring and policy publication	Control 1.13 — Sensitive Information Types
eDiscovery case management, custodian holds, search-and-export	Control 1.19
Managed Environments enablement, environment groups, tier classification	Control 2.1 and Control 2.2
Validation framework, regression suites, model-swap re-validation	Control 2.5
Orphan remediation workflow itself (this playbook detects and routes; remediation is here)	Control 3.6
Reporting, dashboarding, governance dashboard build-out	Control 3.8
Publish-time enforcement that blocks an agent without complete metadata	Control 3.11
SharePoint grounding-scope inventory and oversharing remediation	Control 4.6 and Control 4.7

0.3 The six registry-source planes

No single Microsoft surface returns the complete agent register for an FSI tenant as of April 2026. Each surface is authoritative for a subset. The register of record is the stitched export produced by the §7 manual stitching procedure, signed by the AI Governance Lead, and archived under Preservation Lock.

#	Plane	Source surface	Authoritative for	Typical refresh latency	Sovereign parity
1	M365 Copilot Hub plane	`https://admin.microsoft.com → Copilot → Inventory`	M365 Copilot agents, declarative agents, M365 Copilot extensions, Microsoft-provided agents	Hours (ad-hoc capture); some columns refresh on portal navigation	GA Commercial / GCC; lag in GCC High / DoD
2	Power Platform plane	`https://admin.powerplatform.microsoft.com → Resources → Copilot agents` (and `Manage → Inventory` legacy view)	Copilot Studio agents (custom and Studio-published declarative), environment-scoped attributes, Maker-side ownership	~15 minutes inventory refresh; up to 48 h for deletion visibility; PPAC display capped at ~500 agents	GA broadly
3	Entra plane	`https://entra.microsoft.com → Identity → Applications → Enterprise applications` plus the Agent Registry blade (preview) and App registrations	App-registered declarative agents, plugin/connector OAuth posture, agent service principal IDs	Minutes for app changes; near-real-time for sign-in telemetry	GA Enterprise apps; preview Agent Registry — verify per cloud
4	Agent 365 plane	`https://admin.agent365.microsoft.com` (preview hostname — verify at deploy time)	Cross-cloud agent observability, ownerless-agent queue, governance cards, agent identity → telemetry join	Hours	Preview / Frontier program; likely not in GCC High / DoD / Gallatin at first GA
5	Purview plane	`https://purview.microsoft.com → Solutions → Data lifecycle management` (and Records management)	Retention / Preservation Lock binding for the registry document library, evidence-package retention	Per policy; binding propagates within hours	GA Commercial / GCC; verify per release in GCC High / DoD
6	SharePoint plane	SharePoint Admin → Connected apps; SharePoint Admin → Reports → Data access governance	SharePoint-grounded agent inventory, Connected App registrations, container ownership	Hours	GA Commercial / GCC; rolling sovereign

There is no single pane

There is no single Microsoft surface that returns the complete register for an FSI tenant as of April 2026. Each surface is authoritative for a subset; some agents surface in only one plane. The register of record is the stitched export produced by the §7 manual stitching procedure and signed by the AI Governance Lead. Operators who treat any single surface as "the inventory" will undercount agents and miss the orphan and shadow signals. The §11 quarterly attestation enforces stitching; the §12 examiner audit-pull procedure produces the regulator-facing artifact.

0.4 Portal-vs-PowerShell decision matrix

Use this table to decide whether to stay in this portal walkthrough or switch to PowerShell Setup. The criterion is scale, repeatability, and evidence integrity.

Task	Portal (this playbook)	PowerShell (sibling)	Reason for split
Initial register baseline (≤ 50 agents)	✅ Primary	Optional	Faster click-through; screenshot evidence anchors
Register baseline (> 50 agents, > 500 agents in PPAC)	⚠️ Reference only	✅ Primary	PPAC display capped at ~500 — Azure Resource Graph required for full enumeration
Quarterly attestation diff (snapshot N vs N-1)	❌	✅ Primary	Diff requires scripted hash and stable-sort key
Single-agent lifecycle state transition (record move)	✅ Primary	Optional	Click-through with named-human attribution
Bulk lifecycle state transition (e.g., environment retirement)	❌	✅ Primary	Repeatable, idempotent, audit-stamped
Orphan detection — departed-owner Graph join	⚠️ Spot-check only	✅ Primary	Tenant-scale Graph user enumeration
Dormant detection — no activity beyond Zone threshold	⚠️ Spot-check only	✅ Primary	Activity windows require unified-audit-log query
DLP-mapping verification per agent	✅ Primary (spot-check)	✅ Primary (bulk)	Zone-3 spot-check at attestation; bulk for full sweep
Sensitivity-label inheritance verification	✅ Primary (spot-check)	✅ Primary (bulk)	Same split
Examiner audit-pull packaging (FINRA 8210 etc.)	⚠️ Cover memo + signatures	✅ Primary	Hash + chain-of-custody manifest is scripted
Connected Apps export (SharePoint Plane 6)	✅ Portal-only in some clouds	Where Graph is available	Portal screenshot is sometimes the only artifact in sovereign clouds
Evidence-pack hashing (SHA-256 of all artifacts)	❌	✅ Primary	Tamper-evident manifest required for books-and-records

Rule of thumb: Portal for set-up, attestation review, single-agent transitions, and examiner-facing walkthroughs. PowerShell for scale, recurrence, hashing, and diffing. If you find yourself clicking the same blade more than three times in one session, switch to the sibling.

§1. Canonical metadata schema and surface inventory

The schema authored here is the contract that every other Pillar 3 control consumes. Get it wrong here and every downstream dashboard, report, and examiner pull is wrong.

1.1 Surface inventory (April 2026)

Surface	Hosting	Authoritative for	GA status (Commercial)	Authoring artifact	Owner role
M365 Copilot Hub — Agents tab	`admin.microsoft.com → Copilot → Inventory → Agents`	Custom Copilot agents (Studio-published), tenant-installed agents	GA	Per-agent metadata side-panel + CSV export	AI Administrator
M365 Copilot Hub — Declarative agents tab	Same path, separate tab	Declarative agents (manifest-authored)	GA	Manifest + admin-side metadata	AI Administrator
M365 Copilot Hub — Extensions / Connectors	Same path, Extensions tab	M365 Copilot extensions, Graph connectors, API plugins	GA	Per-extension Entra app ID + permissions	AI Administrator
Power Platform Admin — Resources → Copilot agents	`admin.powerplatform.microsoft.com → Resources → Copilot agents`	Copilot Studio agents (env-scoped)	GA	Per-agent side panel + CSV export	Power Platform Admin
Power Platform Admin — Manage → Inventory (legacy Maker Inventory)	`Manage → Inventory` with `Item type = Agent` filter	Departed-owner cross-check, System Account ownership detection	GA	Per-item view + CSV export	Power Platform Admin
Entra Admin — Enterprise applications	`entra.microsoft.com → Identity → Applications → Enterprise applications`	Service principals, app ownership, OAuth permissions	GA	App list + per-app properties + CSV download	Entra Global Reader / Entra App Admin (write)
Entra Admin — Agent Registry (preview)	`Identity → Applications → Agent Registry`	Agent-classified app identities, agent ID directory	Preview	Agent-classified app catalog	Entra Agent ID Admin
Entra Admin — App registrations	`Identity → Applications → App registrations`	Developer-side declarative agent registrations	GA	App registration manifest	Entra App Admin
Agent 365 Admin Center	`admin.agent365.microsoft.com` (verify at deploy)	Cross-cloud agent observability, ownerless queue	Preview	Governance cards + export	Agent 365 Admin
Purview compliance portal — Data lifecycle / Records management	`purview.microsoft.com → Solutions → Data lifecycle management`	Retention / Preservation Lock for register library	GA	Retention policy + label policy	Purview Records Manager / Purview Compliance Admin
SharePoint Admin — Connected apps	SP Admin → Settings → Manage Connected apps	Site-registered Copilot extensions, Graph connectors	GA	Per-app permission record	SharePoint Admin
SharePoint Admin — Reports → Data access governance	SP Admin → Reports → Data access governance	Sites with Copilot grounding scope (joins to Plane 1 agents)	GA	DAG report + CSV export	SharePoint Admin
(Optional) Microsoft Defender for Cloud Apps — App Governance	Defender XDR → Cloud Apps → App governance	Third-party agent visibility for shadow-AI cross-check	GA	App catalog + risk score	Entra Security Admin

1.2 The canonical metadata schema

This single authoritative table is the contract every other Pillar 3 control references. Any field added or removed here requires sign-off by the AI Governance Lead and a coordinated update across consuming controls (3.2, 3.4, 3.6, 3.8, 3.9, 3.11, 3.13).

Field	Type	Required for	Authoritative source surface	Refresh cadence	Examiner-facing label	Validation rule
AgentID (canonical)	string (GUID or composite)	All zones	Source-surface native ID — Power Platform `botId`, Entra `appId`, M365 Copilot Hub `agentId` — promoted to canonical at first registration	Immutable post-create	"System identifier"	Non-null; immutable; primary join key across all planes
Display Name	string	All zones	Source surface (Plane 1 / Plane 2)	Real-time	"Agent name"	Non-null; ≤ 80 chars; matches WSP naming convention
Agent Type	enum	All zones	Plane 1 + Plane 2	At promotion	"Agent classification"	Must be one enumerated value
Platform / Source Surface	multi-enum (Planes 1–6 a row was sourced from)	All zones	Stitching workbook	Per attestation	"Surfaces of record"	At least one plane sourced; "1+2+3" is healthy; "2 only" is a shadow-candidate
Owner	UPN	All zones	Plane 1 / Plane 2 / Plane 3	Real-time	"Named human accountable"	Must be active employee per Graph; named human, not a group
Backup Owner	UPN	Zone 2 + Zone 3	Manual; SharePoint register list	Quarterly review	"Backup accountable human"	Non-null for Zone 2/3; distinct from Owner; not a group
Business Justification	text	All zones	Manual; register list	At promotion + on material change	"Documented business purpose"	Non-null; ≥ 100 characters; references approving committee minute or change ticket
Zone	enum	All zones	Manual classification per Control 2.1 + Control 1.2	At promotion; reviewed quarterly	"Governance zone"	Must reconcile with environment Managed-Environment classification
Data Classification	enum	All zones	Sensitivity-label propagation per Control 1.13	At promotion + on grounding-source change	"Data sensitivity"	Must reconcile with §9 Sensitivity-label inheritance check; defaults to highest label across grounding sources
Regulatory Scope	multi-enum	All zones	Manual at promotion	At promotion + on regulatory change	"Regulations the agent's outputs may touch"	At least one entry for any Zone 3 customer-facing or recordkeeping-scope agent
Approval Records	URL list (SharePoint document IDs / change tickets)	Zone 2 + Zone 3	Manual at promotion	At promotion	"Approval evidence pack"	At least one record per zone-required signer
Lifecycle State	enum	All zones	Register list (canonical); source surface (advisory)	On state change	"Current lifecycle state"	Transitions logged with author UPN + timestamp; canonical state lives in the register, not in the source surface
Last Reviewed	date	All zones	Register list	At each attestation	"Last attestation date"	≤ 90 days for Zone 3; ≤ 180 days Zone 2; ≤ 365 days Zone 1
Next Review Due	date (computed)	All zones	Register list	Computed at attestation	"Next attestation due"	Non-null; future-dated; drives attestation queue
Connected Knowledge Sources	URL list (SP sites, OneDrive, Dataverse tables, web URLs, external knowledge)	All zones	Plane 1 / Plane 2 metadata side-panel + Plane 6 DAG	At promotion + on grounding change	"Sources the agent grounds on"	Reconciled to Control 4.6 grounding inventory at attestation
Connected Actions / Connectors	list of (action ID, connector ID, OAuth posture)	All zones	Plane 1 + Plane 2 + Plane 3 Enterprise apps	At promotion + on action change	"Actions the agent can invoke"	Each connector tagged with DLP business-data-group classification (Control 1.5)
Plugins / Connected Apps	list (name + Entra appId where applicable)	All zones	Plane 1 Extensions + Plane 6 Connected apps + Plane 3 App registrations	At promotion + on plugin change	"Plugins / extensions / connected apps"	Each entry mapped to Entra appId where applicable
Foundation Model / Runtime	string	Zone 2 + Zone 3	Copilot Studio model picker / Foundry deployment ID	At promotion + on model swap	"Foundation model in use"	Triggers re-validation under Control 2.5 on change
Effective Sensitivity Label	string (highest label across grounding sources)	Zone 2 + Zone 3	§9 verification procedure	At promotion + at each attestation	"Inherited sensitivity posture"	If grounding sources include Highly Confidential / NPI / MNPI, agent must be Zone 3
DLP Policy Mapping	URL / policy name	All zones	§8 verification procedure (Purview DLP for M365 Copilot + Power Platform data policies)	At promotion + on policy change	"Linked DLP policy"	Non-null Zone 3; documented exception otherwise
Sovereign Cloud Boundary	enum {Commercial, GCC, GCC High, DoD, Gallatin} + multi-region annotation	All zones	Tenant determination (per Control 4.7)	At promotion + on tenant move	"Cloud boundary"	Must match tenant's actual cloud; flagged at attestation if mismatch
Environment / Tenant / Region	string (Power Platform environment ID + tenant ID + Azure region)	All zones	Plane 2 + Plane 3	At promotion + on environment change	"Hosting environment"	Reconciled to Control 2.1 environment list
Enterprise App / Service Principal ID	GUID	Zone 2 + Zone 3 (where Entra-backed)	Plane 3	Real-time	"Entra service principal"	Non-null where the agent is Entra-backed; cross-join key
Audit-Log Reference	string (UAL operation prefix + Sentinel rule reference)	Zone 2 + Zone 3	Control 1.7 + Control 3.9 mapping	At promotion	"Audit pipeline binding"	Non-null Zone 3
Risk Register Reference	URL	Zone 2 + Zone 3	Control 1.2 risk register	At promotion + quarterly	"Risk register entry"	Non-null Zone 3
Validation Evidence Pack	URL	Zone 2 + Zone 3	Control 2.5 evidence pack	At promotion + on material change	"Validation evidence pack"	Non-null Zone 3
Incident History	list of incident IDs	Zone 2 + Zone 3	Control 3.4 incident records	On incident closure	"Linked incidents"	Reconciled at quarterly attestation
Decommission Date	date (nullable)	All zones (when applicable)	Register list	On Decommission transition	"Retirement date"	Non-null only when state = Decommissioned
Exception Reference	URL (nullable)	All zones (when applicable)	GRC tool / Compliance Officer log	On exception grant	"Approved exception"	Required when any field's validation rule is waived
Evidence Reference / Export Hash	string (SHA-256) + URL	Zone 2 + Zone 3	PowerShell hashing per `powershell-setup.md`	At each attestation	"Evidence pack ID + hash"	Non-null Zone 3; tamper-evident

Schema contract notice: This schema is the contract that Controls 3.2, 3.4, 3.6, 3.8, 3.9, 3.11, and 3.13 consume. Any field added or removed here requires sign-off by the AI Governance Lead and a coordinated update across consuming controls. Versioned schema definitions are stored in the register-of-record SharePoint library under /_schema/3.1-canonical-schema-v{n}.json.

1.3 Propagation and refresh latency

Operators must understand how long a portal-side change takes to surface in the next plane's view. Quarterly stitching that runs immediately after a bulk owner change will surface false-positive orphans.

Change	Typical propagation	Worst case observed	Validation step
New Copilot Studio agent published → Plane 2 visibility	< 15 minutes	1 hour	Refresh PPAC Resources view
New Copilot Studio agent published → Plane 1 visibility (when published to M365 Copilot)	1–4 hours	24 hours	Re-open Copilot Hub Inventory
Agent deletion in PPAC → removal from Plane 2	Immediate visual; ledger row may persist	48 hours	Confirm via the legacy Maker Inventory
Owner change in Entra (UPN updated, manager-of-record updated) → Plane 1 / Plane 2 owner column	1–24 hours	48 hours	Re-open agent detail page
License strip / user soft-delete → orphan signal in Plane 1 / Plane 2	1–4 hours	24 hours	PPAC `Owner = System Account` filter
Entra Enterprise apps refresh (new app installed)	Minutes	1 hour	Refresh app list
Agent Registry (preview) refresh	Hours	Verify	Re-open blade
Agent 365 (preview) refresh	Hours	Verify	Re-open blade
Purview retention policy publish → SharePoint library binding	1–24 hours	48 hours	Confirm In-place hold indicator on a library item
SharePoint Connected apps inventory update	Hours	24 hours	Refresh SP admin Connected apps view
DAG report re-computation	Daily by default	7 days	Confirm last-run timestamp on the report card

Pilot soak time

Allow at least 24 hours between any owner change and quarterly stitching to avoid stale-state false positives. For tenant-wide owner-bulk events (e.g., reorganization, M&A integration), allow 72 hours soak before treating any orphan signal as actionable.

1.4 The "shadow AI" callout

The most common FSI inventory failure is agents created in the personal-productivity Default environment that never enter the register. They are visible only via the PPAC Maker Inventory and the Entra Enterprise apps blade — they will not appear in the M365 Copilot Hub Agents tab if they were never published to M365 Copilot.

Pre-attestation requirement: the §11 procedure must stitch all six planes; running attestation off Copilot Hub alone will undercount.
Cross-link to Control 2.1 — Managed Environments (Default environment governance) and Control 3.6 — Orphaned Agent Detection (shadow-agent intake workflow).

1.5 Sovereign-cloud determination memo

Before any baseline build, the AI Governance Lead and CISO sign a one-page memo documenting:

The tenant's primary sovereign cloud (Commercial / GCC / GCC High / DoD / Gallatin).
Multi-geo or multi-region annotation if applicable.
The list of surfaces (per the §1.1 table) that are not GA in this cloud as of the memo date.
The compensating control adopted for each gap (e.g., manual screenshot evidence for Plane 6 in DoD; quarterly Defender for Cloud Apps cross-check while Agent 365 is preview).

The memo is filed in the register-of-record library under /_governance/3.1-sovereign-cloud-determination-{YYYY-MM}.pdf and re-signed annually.

§2. Pre-flight gates

Five gates must be signed off before opening any portal in §3 onward. Each gate is a checklist the operator countersigns. Failure of any gate halts the baseline build and is logged as a Sev-2 governance finding under Control 1.2.

2.1 Gate PRE-01 — License gate

Confirm and document each licensing floor:

Microsoft 365 Copilot — at least one E3/E5 + Copilot license is active in the tenant; the Copilot node appears in admin.microsoft.com. (Verify via admin.microsoft.com → Billing → Licenses.)
Power Platform Managed Environments — at least one Managed Environment is configured (verify in admin.powerplatform.microsoft.com → Manage → Environments, filter Managed = Yes).
Entra ID P1 (P2 recommended) — verify in entra.microsoft.com → Identity → Overview → Licenses.
Purview Audit (Standard or Premium) — verify the Audit solution is provisioned in purview.microsoft.com.
Purview Records Management — verify the Records management solution is enabled if Preservation Lock will be used on the register library.
Microsoft Sentinel — verify the AI content hub solution is installed (Control 3.9 dependency).
Agent 365 — entitlement verified or marked "preview not entitled" in the §1.5 sovereign-cloud determination memo.
SharePoint Premium — verified or marked "compensating screenshot evidence" in the memo.

Sign-off: Compliance Officer countersigns the license-gate checklist; archive as 3.1-PRE-01-license-gate-{YYYY-MM-DD}.pdf.

2.2 Gate PRE-02 — Role gate

Use only the framework's canonical role names from docs/reference/role-catalog.md. Do not revert to long-form Microsoft titles in the WSP, the attestation memo, or the examiner cover letter.

Role	Tenant scope	Surface coverage	PIM posture
AI Governance Lead	Owns the register of record	All six planes (read across)	Standing
AI Administrator	M365 Copilot Hub Inventory authoring	Plane 1	Standing read; PIM for write
Power Platform Admin	PPAC Resources → Copilot agents; Maker Inventory	Plane 2	PIM-elevated for environment-scoped writes
Entra Global Reader	Enterprise apps + Agent Registry read	Plane 3	Standing
Entra App Admin	App registrations write (rare)	Plane 3	PIM-only
Entra Agent ID Admin	Agent Registry blade (preview) write	Plane 3 / Plane 4 boundary	PIM-only
Agent 365 Admin	Agent 365 Admin Center	Plane 4	PIM-only (preview surface)
Purview Compliance Admin	Retention / Records Management linkage	Plane 5	Standing
Purview Records Manager	Preservation Lock for register library (Control 1.9 handoff)	Plane 5	Standing
SharePoint Admin	Connected apps inventory + DAG	Plane 6	Standing
Compliance Officer	Quarterly attestation third signer; examiner-pull approver	Cross-surface	Standing
Designated Supervisor / Registered Principal	FINRA Rule 3110 supervisory sign-off on examiner pull	Cross-surface	Named per WSP
CISO observer	Sovereign-cloud determination; sign-off on shadow-AI register	Tenant-wide	Standing

Separation-of-duties rule: A single human MUST NOT hold both Owner of an agent and AI Governance Lead sign-off on the attestation for that agent — collapsing those roles undermines the FINRA 3110 supervisory-independence defense and the FINRA 25-07 governance posture.

Sign-off: AI Governance Lead countersigns 3.1-PRE-02-role-gate-{YYYY-MM-DD}.pdf.

2.3 Gate PRE-03 — Tenant settings gate

Confirm pre-existing controls that the register depends on:

Control 1.7 Unified Audit Log is enabled and capturing AgentCreate, AgentUpdate, AgentDelete, OwnerChanged, and SharePoint list Update operations on the register library.
Control 1.7 Advanced Audit retention for Zone 3 (≥ 1 year) is configured (Premium SKU).
Control 1.13 Sensitivity labels are published to all in-scope sites (drives Data Classification inheritance check in §9).
Control 1.9 Retention policies authored and reconciled with the Records Manager for register-export Preservation Lock.
Control 2.1 Managed Environments enabled (drives Zone classification reconciliation).
Control 4.6 Grounding-source inventory current (joins on AgentID at §9).
Control 1.2 Risk register active (joins on AgentID).
Control 3.9 Sentinel content hub for AI installed (register-deviation alerts).

Sign-off: AI Governance Lead + Entra Global Reader cross-confirm; archive as 3.1-PRE-03-tenant-settings-{YYYY-MM-DD}.pdf.

2.4 Gate PRE-04 — WSP / change-control gate

The Written Supervisory Procedures (WSP) must include the following elements before the baseline build is considered authoritative:

Register-of-record location, owner, and retention horizon (≥ 6 years per SEC 17a-4(b)(4); longer if firm policy requires).
Quarterly attestation cadence and three-signature workflow (§11).
Lifecycle state-transition approval matrix (who can move Draft → In Review → Approved → Active → Deprecated → Decommissioned).
Orphan-remediation SLA: Zone 3 = 5 business days; Zone 2 = 10 business days; Zone 1 = 30 business days.
Examiner audit-pull SLA: target ≤ 5 business days for FINRA 8210; ≤ 30 calendar days for OCC; ≤ 24 hours for ad-hoc supervisory request.
Sovereign-cloud determination procedure (per agent, per environment).
Shadow-AI handling procedure: discovered agent placed in Draft state with Owner assigned within 5 business days, otherwise transitioned to Decommissioned.

Sign-off: Compliance Officer + Designated Supervisor; archive as 3.1-PRE-04-wsp-excerpt-{YYYY-MM-DD}.pdf.

2.5 Gate PRE-05 — Test fixtures gate

Before walking through §3 in production, validate the procedure in a sandbox or non-prod tenant:

Sandbox tenant or non-prod environment available with at least one Managed Environment.
Test agent in each Zone (1, 2, 3) with full canonical metadata populated.
Canary agent with traceable naming pattern FSI-CANARY-3.1-{YYYYMMQ}-{n} for round-trip verification through the register.
Test "departed-owner" account (license-stripped, soft-deleted Graph user) for the §6 orphan-detection drill.

Sign-off: AI Administrator + Power Platform Admin; archive as 3.1-PRE-05-test-fixtures-{YYYY-MM-DD}.pdf.

§3. Plane 1 — Microsoft 365 Copilot Hub Inventory walkthrough

This is the primary first-party governance surface for organization-wide Copilot agents. Refresh cadence is on-demand at portal navigation; some columns (License consumption, Last activity) lag the underlying telemetry.

3.1 Open the Copilot Hub Inventory

Sign in to https://admin.microsoft.com as AI Administrator (or Entra Global Reader for read-only review).
In the left navigation, expand Copilot. If the Copilot node is not present:
Verify the Microsoft 365 Copilot SKU is licensed in the tenant (Gate PRE-01).
Verify the operator holds at least AI Administrator or Entra Global Reader.
In sovereign clouds where the node label differs, look for AI agents or Copilot agents as alternate labels.
Click Inventory (label may read Agent inventory or Copilot agent inventory depending on monthly build — verify exact heading at deploy time and capture in the §13 evidence pack).
Confirm the page header reads as expected. Screenshot description: M365 admin center top breadcrumb showing Home > Copilot > Inventory, with the page heading "Copilot agent inventory" and three tabs labeled "Agents", "Declarative agents", and "Extensions" visible at the top of the content area.

Legacy navigation note

The older path Settings → Integrated apps → Agents is legacy as of April 2026. Operators may still see it during a tenant rollout window; treat it as a compatibility fallback only and migrate to Copilot → Inventory as soon as the new node appears.

3.2 The Agents tab

The Agents tab enumerates Custom Copilot agents (Studio-published), tenant-installed agents, and Microsoft-provided agents that have been enabled.

Click the Agents tab (or All agents depending on build).
Click the column picker (gear icon top-right of the grid) and enable at minimum:
Name
Owner
Type (Custom / Declarative / Extension)
Source (Copilot Studio / Agent Builder / Marketplace)
Created date
Modified date
Status (Published / Draft / Disabled)
Environment (Power Platform environment binding)
Sovereign cloud (where exposed)
Risks (where exposed — flags ownerless, departed-owner, license-stripped)
License consumption (preview as of April 2026 — verify availability in your build)
Last activity (preview as of April 2026)
Sort by Modified date descending to surface recent activity.
For each Zone 3 agent in the grid, click into the agent row → confirm the metadata side-panel exposes:
Owner (with hover tooltip showing UPN)
Description (maps to canonical Business Justification)
Knowledge sources (maps to canonical Connected Knowledge Sources)
Actions (maps to canonical Connected Actions / Connectors)
Plugins (maps to canonical Plugins / Connected Apps)
Screenshot description: Agents tab grid view with all canonical-schema columns visible, the Risks column showing one "Ownerless" red badge and two "Owner inactive" amber badges, and the side-panel open on a Zone 3 agent revealing Knowledge sources listing two SharePoint sites and one Dataverse table, Actions listing three connectors with their OAuth posture, and the Owner field showing the displayName + UPN.

Evidence capture: Screenshot the Agents tab with all canonical-schema columns visible. Save as 3.1-Plane1-Agents-{YYYY-MM-DD}.png in the register-of-record SharePoint library under /_evidence/{YYYY-Qn}/.

3.3 The Declarative agents tab

Declarative agents are manifest-authored (Copilot Studio Lite, Agents Toolkit, Copilot Studio declarative-agent path). They are the most likely surface for partner-published or developer-side agents.

Click the Declarative agents tab.
Enable columns: Name, Owner, Manifest version, Capabilities (Knowledge / Actions / Code Interpreter), Last published, Source.
For each row, capture the manifest provenance — the manifest is the source of truth for plugins/connected apps; the register mirrors but does not author the manifest.
Screenshot description: Declarative agents tab grid with eight rows visible, columns showing Manifest version (e.g., "1.4"), Capabilities cells with chips for "Knowledge" and "Actions", and a side-panel open on one agent showing the manifest JSON snippet with the plugin Entra appId highlighted for the §5 cross-check.

Evidence capture: 3.1-Plane1-Declarative-{YYYY-MM-DD}.png plus CSV export per §3.6.

3.4 The Extensions tab

Microsoft 365 Copilot extensions (formerly "plugins") include message extensions, Graph connectors, and API plugins. Each entry maps to an Entra App ID — capture the App ID for the §5 Entra cross-check.

Click the Extensions tab (or Connectors depending on build).
Enable columns: Name, Publisher, Type (Message extension / Graph connector / API plugin), Entra App ID, Permissions, Status, Owner.
For each Zone 3 extension, click the row → side-panel shows the OAuth permission scopes (delegated vs application) and the consent state.
Screenshot description: Extensions tab showing twelve extensions, three flagged with "Admin consent required" amber badges, and the side-panel open on a Graph connector revealing the App ID 00000003-0000-0000-c000-000000000000-style GUID copyable to clipboard.

Evidence capture: 3.1-Plane1-Extensions-{YYYY-MM-DD}.png and CSV.

3.5 Filters, views, and the Risks column

The Copilot Hub provides governance filters that drive the §6 orphan workflow:

Filter	Value	What it surfaces
Status	`Published`	Active agents — count for Zone-classification reconciliation
Status	`Disabled`	Deprecated candidates that may need state transition to Decommissioned
Owner	`(any user filter)`	Per-owner enumeration for departed-owner detection
Risks	`Ownerless`	Surface for the Manage Ownerless action (see below)
Risks	`Owner inactive`	Departed-owner candidates — feed §6 orphan workflow
Type	`Declarative`	Cross-check against manifest source-of-truth
Sovereign cloud	(current cloud)	Confirm no agents are mis-tagged across cloud boundary

Save filtered views per Zone for the quarterly attestation. Click Save view at the top of the grid; name as 3.1-Z{n}-attestation-{YYYY-Qn}.

Manage Ownerless action: When the Risks column shows one or more Ownerless badges, the toolbar exposes a Manage Ownerless button. Click it to open the ownerless-agent dialog:

Select agents to remediate.
Choose: Assign Owner (UPN picker — must be a named human, not a group) or Disable (transitions the agent to a non-published state pending decision).
The action is logged in the Unified Audit Log as OwnerChanged with the operator's UPN — capture this entry in the §11 attestation evidence.
Screenshot description: "Manage ownerless agents" dialog overlay showing four agents with checkboxes, an "Assign Owner" picker with autocomplete, and a "Disable" option below; the dialog footer shows "Action will be logged" with a tooltip "This action is recorded to the Unified Audit Log as OwnerChanged".

3.6 Bulk export from Plane 1

With the desired filter applied (or no filter for full export), click Export (top-right; label may read Export to CSV).
Confirm the export contains all visible columns. If the export omits columns visible in the grid, document the omission in the §13 evidence pack and capture additional screenshots as compensating evidence.
Save the file with the naming convention: 3.1-Plane1-Export-{YYYY-MM-DD}-{cloud}.csv (e.g., 3.1-Plane1-Export-2026-04-15-Commercial.csv).

Compute SHA-256 immediately (one-liner):

Get-FileHash -Algorithm SHA256 .\3.1-Plane1-Export-2026-04-15-Commercial.csv

Record the hash in the §13 evidence manifest. Defer recurring scheduled exports to PowerShell Setup.
Upload the export to the register-of-record SharePoint library under /_evidence/{YYYY-Qn}/. The library must already be bound to a Purview retention policy per Gate PRE-03.

3.7 What this surface does NOT show

Mandatory operator awareness — Plane 1 alone undercounts the register:

Agents in non-Default environments created via Copilot Studio but never published to M365 Copilot.
Agents in the Power Platform Default environment that have not been promoted to a Managed Environment.
Custom Engine Agents (CEAs) hosted in Azure that authenticate via Entra App Registration only.
Agent Builder–authored agents pending publish.
Third-party agents enrolled via Entra Workload Identity Federation (visible only in Plane 3 / Plane 4).

These gaps are filled by §4 (Plane 2) and §5 (Plane 3). Do not treat Plane 1 alone as the register.

§4. Plane 2 — Power Platform Admin Center: Resources → Copilot agents (and the legacy Maker Inventory)

This is the authoritative surface for Copilot Studio agents and the only surface that exposes environment-scoped governance attributes. The PPAC display is capped at approximately 500 agents; tenants exceeding that threshold must use the PowerShell Setup Azure Resource Graph procedure for full enumeration.

4.1 Open Resources → Copilot agents

Sign in to https://admin.powerplatform.microsoft.com as Power Platform Admin (PIM-elevated).
In the left navigation, expand Resources.
Click Copilot agents.
The grid loads with the tenant-scoped Copilot Studio agent list. Confirm the breadcrumb reads Resources > Copilot agents. Screenshot description: PPAC left rail expanded to Resources > Copilot agents; the grid shows columns Name, Owner, Environment, Status, Created, Modified, with twelve agents visible and a "Filter" pill row above showing the current filter set.

4.2 Configure columns

Click Choose columns and enable at minimum:

Name / Display name
Owner (UPN)
Environment (joins to Control 2.1 environment list — drives Zone classification reconciliation)
Status (Published / Draft / Disabled)
Type (Custom Copilot / Declarative / Connected)
Authentication (No auth / Microsoft / Manual / Custom — drives Plane 3 cross-check)
Channels (Teams / Web / Custom — drives examiner-facing exposure surface mapping)
Created on + Modified on
botId / Bot ID (canonical AgentID join key for Plane 2 → Plane 3 stitching)
Solution (the Power Platform solution containing the agent — joins to ALM evidence)

4.3 Filter, sort, and per-environment pivot

Filter	Operational use
Environment = Default	Surface candidate shadow agents — every row here is a §11 review item
Owner contains `(System Account)` or `# (deleted)`	Departed-owner orphan signal — feed §6 orphan workflow
Status = Disabled + Modified on < 90 days ago	Recent disablement — possible candidate for state transition to Decommissioned
Authentication = No auth + Channels contains `Web`	High-risk public-facing agent — Zone-classification escalation candidate

Save per-environment views named 3.1-Plane2-Env-{environment-name}-{YYYY-Qn} for the §11 attestation pack.

4.4 Per-agent metadata side panel

Click into a row to open the agent details. Capture for each Zone 3 agent:

Owner (must reconcile with Plane 1 owner if also published to M365 Copilot).
Environment (must reconcile with Control 2.1 Managed-Environment classification).
Knowledge sources (must reconcile with Plane 6 SharePoint Connected apps and Control 4.6 grounding inventory).
Topics / Actions (each connector mapped to its DLP business-data-group classification per Control 1.5).
Authentication mode (joins to Plane 3 Entra service principal where Microsoft auth is used).
Solution (joins to ALM evidence per Control 2.7).

Screenshot description: PPAC Copilot agent details blade for a Zone 3 customer-service agent; the Knowledge sources section lists three SharePoint URLs with "Inherited sensitivity: Confidential" badges; the Actions section lists five connectors with green "DLP Business" or amber "DLP Non-Business" pills; the Authentication section reads "Microsoft" with the Entra App ID copyable.

4.5 The legacy Maker Inventory (Manage → Inventory)

The legacy Manage → Inventory view remains the most reliable surface for departed-owner cross-check because it surfaces the System Account ownership transition and the per-environment ledger. Use it in addition to (not instead of) Resources → Copilot agents.

In PPAC, navigate to Manage → Inventory.
In the Item type filter, select Agent (or Bot depending on build label — verify in your tenant).
The grid surfaces the per-environment, per-item ledger. Filter columns:
Owner = System Account → license-stripped or deleted owner
Owner contains # (deleted) → soft-deleted Graph user
Last modified < threshold → dormant candidates
Export to CSV via the toolbar Export action.
Screenshot description: PPAC Manage > Inventory grid filtered to Item type = Agent and Owner = System Account, showing four rows highlighted amber, with the Owner column reading "System Account" and the Environment column showing one Default-environment row that the operator should escalate to a §11 review item.

Evidence capture: 3.1-Plane2-MakerInventory-{YYYY-MM-DD}.csv and screenshot.

4.6 Bulk export from Plane 2

From Resources → Copilot agents, click Export to CSV in the toolbar.
PPAC export caps at ~500 rows in the UI. If the tenant exceeds 500 Copilot Studio agents, do not rely on the UI export — switch to PowerShell Setup (Azure Resource Graph + Power Platform admin connectors).
Save as 3.1-Plane2-Export-{YYYY-MM-DD}.csv. Compute SHA-256 and record in the evidence manifest.

4.7 What this surface does NOT show

M365 Copilot extensions / Graph connectors (Plane 1).
Entra-registered service principals for Custom Engine Agents that are not Power Platform–hosted (Plane 3).
SharePoint-grounded site exposure (Plane 6).
Agent telemetry beyond the activity timestamp (Control 3.9 / Sentinel).

§5. Plane 3 — Microsoft Entra: Enterprise applications + Agent Registry blade + App registrations

The Entra plane is the identity authoritative source for any agent that holds an Entra service principal — declarative agents with plugins, Custom Engine Agents, M365 Copilot extensions backed by an Entra App, and any third-party agent installed via Entra App Gallery.

5.1 Enterprise applications view

Sign in to https://entra.microsoft.com as Entra Global Reader (read) or Entra Cloud Application Admin (PIM-elevated for write).
Navigate to Identity → Applications → Enterprise applications.
Set Application type = All applications and Application status = Any.
Apply filter: Application visibility = Hidden or All (some agent-class apps register hidden).
Use the search field with the agent name pattern from your WSP. For broad sweep, filter by Created date to surface recent installs.
Screenshot description: Entra Enterprise applications list filtered to Application type = All applications, showing a search bar populated with Copilot returning 47 hits; columns visible include Name, Object ID, Application ID, Homepage URL, Created date, Sign-in date.

5.2 Per-app deep dive

Click into a Zone 3 agent's enterprise app entry and capture:

Application ID (the canonical Entra appId — primary join key for Plane 3 stitching).
Object ID (service principal object ID).
Owners (named human owners of the app — reconcile with the agent's canonical Owner).
Permissions → Configured permissions — list every Graph and connector permission scope, classify each as delegated or application; flag any application-level permission for the §11 review.
Sign-in logs (last sign-in timestamp — joins to Plane 4 / Sentinel for activity reconciliation; informational only — authoritative activity reporting lives in Control 3.9).
Properties → Assignment required — must be Yes for any Zone 3 agent unless an explicit exception is filed.
Properties → Visible to users — set per WSP.

Screenshot description: Enterprise app overview blade for a Custom Engine Agent showing Application ID and Object ID GUID values; the Permissions section reveals two delegated Graph scopes (Files.Read, Sites.Read.All) and one application scope (Sites.Selected) flagged with a red "Application permission" badge that must be reviewed at §11.

5.3 The Agent Registry blade (preview, April 2026)

The Agent Registry is the emerging Entra surface that promotes Entra App Registrations into a first-class Agent ID taxonomy. Treat as additive evidence while preview; do not retire Plane 1 / Plane 2 procedures based on it.

In entra.microsoft.com, navigate to Identity → Applications → Agent Registry (preview — verify exact label at deploy time; sovereign-cloud parity not assured).
The blade enumerates apps that the tenant administrator has classified as Agent type.
Capture the agent ID, classification, owners, and any agent-specific governance attributes (Risk band, Sovereign cloud binding) the blade exposes in your build.
Cross-reference each Agent Registry entry with the Enterprise apps view to confirm no agent-classified app is missing the canonical Owner field.
Screenshot description: Agent Registry preview blade showing ten classified agents with columns Agent ID, Display name, Classification, Owners, Risk band; the toolbar exposes a "Promote from Enterprise apps" action and a "Demote" action with PIM elevation banner at the top.

Preview status

The Agent Registry is preview as of April 2026 with rolling sovereign-cloud availability. Maintain the §1.5 sovereign-cloud determination memo entry stating whether your tenant treats this surface as authoritative or as additive cross-check evidence.

5.4 App registrations (developer-side)

App registrations surface developer-authored declarative agents and Custom Engine Agents pre-publish.

Navigate to Identity → Applications → App registrations.
Filter by Created date and your firm's app-naming convention.
For each agent-class app registration, capture: Application (client) ID, Object ID, Supported account types, Redirect URIs, API permissions, Owners.
Reconcile every developer-side registration with the Enterprise apps tenant view (the tenant install creates the matching Service Principal). Any app registration without a corresponding Enterprise app entry is a pre-publish or ungoverned object — feed to §11 review.

5.5 Bulk export from Plane 3

From Enterprise applications, click Download (Export) in the toolbar (top right). The export covers the visible columns only; ensure the column picker includes Application ID, Object ID, Created date, and Last sign-in.
Save as 3.1-Plane3-EnterpriseApps-{YYYY-MM-DD}.csv.
From App registrations, the portal does not provide a bulk-export button as of April 2026 — switch to PowerShell Setup (Get-MgApplication).
Compute SHA-256 and record in evidence manifest.

5.6 What this surface does NOT show

Power Platform environment binding (Plane 2).
M365 Copilot Hub agent classification (Plane 1).
Grounding-source exposure (Plane 6 / Control 4.6).
Cross-cloud agent telemetry (Plane 4).

§6. Plane 4 — Agent 365 Admin Center (preview)

Agent 365 is the cross-cloud agent observability surface rolling to GA across calendar 2026. Verify availability and entitlement at deploy time. Treat as additive cross-check evidence while in preview; treat as a primary surface only after GA in your sovereign cloud and after the §1.5 memo is updated.

6.1 Open Agent 365

Navigate to https://admin.agent365.microsoft.com (preview hostname — verify with Microsoft Learn at deploy time; the hostname has changed during preview).
Sign in as Agent 365 Admin (PIM-elevated).
If the tenant is not entitled, the portal returns a "not provisioned" page — capture screenshot, file under /_governance/3.1-agent365-not-entitled-{YYYY-MM-DD}.png, and document the compensating control in the §1.5 memo.

6.2 Cross-cloud agent inventory

Where entitled, the Agent 365 Admin Center exposes:

A consolidated agent list spanning Microsoft 365 Copilot, Copilot Studio, Custom Engine Agents, and (where rolled out) third-party agent integrations.
Governance cards per agent surfacing Owner, Sensitivity, Risk band, Last activity.
An Ownerless agents queue analogous to the Manage Ownerless action in Plane 1 — drives the §6 orphan workflow.
Cross-tenant agent visibility for B2B-collaborated agents (where tenant has B2B agent invitations enabled).

6.3 Sovereign-cloud caveat

Agent 365 is likely not GA in GCC High, DoD, or Gallatin at first GA. For sovereign-cloud tenants:

File the determination memo entry stating Plane 4 is not in scope for this attestation cycle.
Use the compensating quarterly cross-check via Microsoft Defender for Cloud Apps → App Governance (where licensed) plus the §5 Entra Enterprise apps export.
Re-evaluate scope at every Microsoft Roadmap update; transition Plane 4 into scope only after GA-in-cloud is confirmed and the §1.5 memo is re-signed by the AI Governance Lead and CISO.

6.4 Evidence capture from Plane 4

If entitled, export the cross-cloud agent list and ownerless queue. Save as 3.1-Plane4-AgentList-{YYYY-MM-DD}.csv and 3.1-Plane4-Ownerless-{YYYY-MM-DD}.csv. Compute SHA-256.

If not entitled, the screenshot evidence of the entitlement-denied page plus the determination-memo entry is the compensating artifact. Both must be present in the §13 evidence pack for any quarter where Plane 4 is referenced in WSP.

§7. The manual stitching procedure (Plane 1 + 2 + 3 + 4 → register of record)

The register of record lives in a SharePoint list (or Dataverse table, where the firm prefers) under the AI Governance Lead's ownership. The stitching procedure converts the per-plane exports into a single canonical-schema row per agent. This procedure is the contract that defines "the inventory" for examiner purposes.

7.1 Prerequisites

Per-plane exports captured per §3.6, §4.6, §5.5, §6.4.
All exports SHA-256 hashed and timestamped.
Register-of-record SharePoint list provisioned per the §1.2 schema and bound to a Purview retention policy per Gate PRE-03.
Stitching workbook template under version control (the template is owned by the AI Governance Lead; changes follow Control 1.2 change-control).

7.2 The join keys

Join	Primary key	Fallback keys
Plane 1 ↔ Plane 2	Plane 1 `agentId` ↔ Plane 2 `botId` (where M365-published)	Display Name + Owner UPN + Environment
Plane 2 ↔ Plane 3	Plane 2 `Microsoft auth → App ID` ↔ Plane 3 `appId`	Display Name + Owner UPN
Plane 3 ↔ Plane 4	Plane 3 `appId` ↔ Plane 4 `agentId`	Display Name + Owner UPN
Any ↔ Plane 6	Connected Knowledge Sources URL list ↔ Plane 6 site URL	Site display name
Any ↔ Control 4.6 grounding inventory	Connected Knowledge Sources URL ↔ grounding-source URL	Site URL

7.3 Stitching steps

Open the stitching workbook (Excel or Power BI desktop file under version control).
Load each plane's export as a separate query.
Apply the join keys per §7.2 to produce a single canonical-schema row per agent.
Where multiple planes disagree (e.g., Plane 1 owner = alice@, Plane 2 owner = bob@), flag the row with Owner-mismatch and route to §11 review. Do not silently pick a winner.
Where an agent appears in only one plane (e.g., Plane 2 only), flag with Single-plane and route to §11 review.
Where an agent has been newly created since last stitching, flag with New and confirm Owner + Zone + Lifecycle State are populated before promoting to the register.
Where an agent appeared in last stitching but is missing from this stitching, flag with Disappeared and route to §6 orphan workflow before transitioning to Decommissioned.
Save the stitched output as 3.1-Register-{YYYY-MM-DD}.xlsx and 3.1-Register-{YYYY-MM-DD}.csv. Compute SHA-256 of both. Upload to the register-of-record library.
The AI Governance Lead reviews and signs the stitched register; signature is a SharePoint list item update with the AI Governance Lead's UPN and the timestamp captured in the Unified Audit Log.
Once signed, the SharePoint list is the authoritative register; downstream controls (3.2, 3.4, 3.6, 3.8, 3.9, 3.11, 3.13) read from it on the canonical AgentID.

7.4 Stitching cadence

Cadence	Trigger	Owner
Quarterly	Calendar-based, per WSP attestation cycle	AI Governance Lead
Ad-hoc	Examiner request, M&A integration, Sev-1 governance incident	AI Governance Lead
Continuous (advisory)	Sentinel detects register-deviation alert (Control 3.9)	AI Administrator triages within SLA

7.5 What to do when a row will not stitch

Owner-mismatch: Open a Plane 1 / Plane 2 / Plane 3 reconciliation ticket; the canonical Owner is decided by the AI Governance Lead with documentation in the ticket. Update all planes to converge on the canonical value within the orphan SLA.
Single-plane (Plane 2 only): This is the shadow-AI signal. Open a Draft register entry, assign a tentative Owner (the Plane 2 ownership row), and run the §6 orphan/shadow workflow.
Disappeared: Confirm via the Plane 2 Maker Inventory that the agent was not silently deleted by an unauthorized user. If deletion was authorized, transition the register row to Decommissioned with the deletion ticket reference. If unauthorized, escalate to Sev-2 governance incident under Control 3.4.
Plane 4 entitlement gap: Note the gap in the stitching workbook and reference the §1.5 memo. Do not block the cycle on a non-GA preview surface.

§8. Plane 5 — Microsoft Purview: retention and Records Management binding for the register library

The register-of-record SharePoint library MUST be bound to a Purview retention policy (and, for SEC 17a-4(f) WORM treatment, a Records Management Preservation Lock). This binding is what makes the register itself a record — without it, the register is operational data, not evidence.

8.1 Open Purview

Sign in to https://purview.microsoft.com as Purview Compliance Admin (read) or Purview Records Manager (write).
Navigate to Solutions → Data lifecycle management for retention; Records management for Preservation Lock.

8.2 Author / verify the retention policy

Under Data lifecycle management → Policies, confirm a policy exists named per WSP convention (e.g., Retention - Pillar3 Register - 7yr).
Confirm the policy is scoped to the SharePoint sites that host the register-of-record library (do not scope tenant-wide).
Confirm the retention period meets or exceeds 6 years (SEC 17a-4(b)(4) floor; Zone 3 firm policy may extend to 7 years).
Confirm the policy is published (not draft).
Screenshot description: Purview retention policy details page showing Name "Retention - Pillar3 Register - 7yr", Locations restricted to two SharePoint site URLs, Retention period 7 years, Action at end of period "Do nothing", Status "On".

8.3 Author / verify Preservation Lock (Records Management)

For tenants treating the register export as a SEC 17a-4(f)-format record:

Under Records management → Retention labels, confirm a label exists with Records mark = Yes (regulatory record) or Records mark = Yes with Apply Preservation Lock = Yes.
Apply (or auto-apply) the label to the register-of-record library.
Once Preservation Lock is applied, the policy is immutable (cannot be reduced in scope, cannot be deleted, cannot have retention period shortened). This is the WORM guarantee for SEC 17a-4(f).
Screenshot description: Records management retention label details showing "Mark items as records" toggled on, "Apply Preservation Lock" toggled on with the warning banner "Preservation Lock cannot be turned off — this is irreversible", and the auto-apply policy showing it is bound to the register library URL.

Preservation Lock is irreversible

Preservation Lock cannot be removed once applied. Verify the policy scope, retention period, and library binding twice before applying. Record the application event in the §13 evidence pack and obtain Compliance Officer countersignature in the WSP-approved evidence template.

8.4 Verify retention is binding

Navigate to the SharePoint register-of-record library.
Open a recent evidence file (e.g., a stitched register CSV).
Open file properties → Compliance details. Confirm the retention label is visible and shows the policy name and retention period.
Screenshot description: SharePoint file Compliance details flyout showing Retention label "Pillar3 Register Record", Status "Applied via auto-apply policy", Retention period "7 years from creation", Records declaration "Yes — record (Preservation Lock)".

8.5 Cross-link to Control 1.9

Records-Management procedure detail, retention-policy authoring, and Preservation Lock operational procedure live in Control 1.9 — Records Management and Preservation Lock. This playbook only verifies the binding to the register library — it does not author records policy.

§9. Plane 6 — SharePoint Admin: Connected apps and Data Access Governance

The SharePoint plane provides two distinct surfaces:

Connected apps — the per-site registration of M365 Copilot extensions and Graph connectors (joins to Plane 1 Extensions tab).
Data Access Governance (DAG) report — the tenant-wide report of sites with Copilot grounding scope, oversharing risk indicators, and last-activity timestamps.

9.1 Connected apps inventory

Sign in to the SharePoint Admin Center (https://{tenant}-admin.sharepoint.com) as SharePoint Admin.
Navigate to Settings → Manage Connected apps (label may vary by build; in newer builds, Settings → Connected apps).
The grid surfaces every Connected App registered against the tenant or against any site, with columns Name, Publisher, Type, Created date, Status.
For each entry, click into the row and confirm the App ID and Permissions. Cross-join to Plane 1 Extensions tab and Plane 3 Enterprise apps on the App ID.
Screenshot description: SharePoint Admin Connected apps grid showing eight registered apps, three with "Tenant-wide" scope and five with site-scoped registrations; the side-panel open on a Graph connector revealing the Permissions list and the App ID copyable to clipboard.

Evidence capture: 3.1-Plane6-ConnectedApps-{YYYY-MM-DD}.csv (export via toolbar). If the export action is unavailable in your sovereign cloud, capture the screenshot as compensating evidence.

9.2 Data Access Governance report

In SharePoint Admin, navigate to Reports → Data access governance.
Locate the Sites with Copilot grounding scope report (label may vary). Click into it.
The report enumerates sites with at least one Copilot agent grounding on them, with oversharing-risk indicators and "Everyone except external users" (EEEU) and "People in your organization" link counts.
Each row joins to the Connected Knowledge Sources canonical-schema field on Site URL.
Export to CSV via the report toolbar. Save as 3.1-Plane6-DAG-{YYYY-MM-DD}.csv.
Screenshot description: DAG report card "Sites with Copilot grounding scope" showing twelve sites, three flagged with red "EEEU - Org wide" badges, the Last activity column populated, and the Export button visible at top right.

DAG and Control 4.6 / Control 4.7 boundary

The DAG report is the discovery surface. The grounding-source inventory and the oversharing-remediation procedure live in Control 4.6 and Control 4.7. This playbook only consumes the DAG output to populate the Connected Knowledge Sources field of the canonical schema.

9.3 Sensitivity-label inheritance check

For each Zone 2/3 register row:

From the canonical Connected Knowledge Sources list, take each grounding URL.
For SharePoint URLs, navigate to the site → Settings → Site information → Site classification (or the new Information protection → Sensitivity path) and capture the site sensitivity label.
For OneDrive URLs, navigate to the user's OneDrive root → confirm the container sensitivity label (or default to "no container label — file labels apply").
For Dataverse tables (Copilot Studio knowledge), capture the environment sensitivity label per Control 2.1.
Compute the effective sensitivity as the highest label across all grounding sources.
Update the canonical-schema Effective Sensitivity Label and Data Classification fields. If any grounding source is Highly Confidential / NPI / MNPI, the agent's Zone classification must be 3 — escalate to §11 review for any mismatch.
Screenshot description: SharePoint site information panel showing Sensitivity label "Confidential - FSI Internal Restricted" applied at site scope; below it the SharePoint label-policy banner reads "Inherited by all files and Copilot grounding".

9.4 DLP-policy mapping verification

For each Zone 3 register row, verify the agent is in scope of at least one DLP policy:

For Microsoft 365 Copilot agents (Plane 1): Sign in to Purview → Solutions → Data Loss Prevention → Policies. For each policy, expand Locations and confirm whether Microsoft 365 Copilot is listed and whether the policy scope includes the agent's owners or the tenant.
For Copilot Studio agents (Plane 2): Sign in to PPAC → Policies → Data Policies. Confirm the agent's environment is in scope of the data policy and that the connectors used by the agent are correctly classified into Business / Non-Business / Blocked groups per Control 1.5.
Capture the policy name(s) and update the canonical-schema DLP Policy Mapping field for the register row.
Cross-plane reconciliation: an M365-published Copilot Studio agent (visible in both Plane 1 and Plane 2) must be in scope of both Purview DLP for M365 Copilot and the Power Platform data policy for its environment. A gap here is a §11 review item.
Screenshot description: Purview DLP policy details showing Locations checkbox list with "Microsoft 365 Copilot" toggled on, Scope set to "All users", and Status "On"; alongside, the PPAC Data Policies blade showing the matching environment-scoped data policy.

§10. Lifecycle state transitions (the canonical state machine)

The canonical Lifecycle State lives in the register list, not in any source surface. State transitions follow this state machine:

Draft  →  In Review  →  Approved  →  Active  →  Deprecated  →  Decommissioned
                ↓             ↑           ↑              ↓
                └─────────────┴───────────┴──────── Withdrawn (back to Draft)

State	Authoritative meaning	Allowed transitions	Required signature
Draft	Newly registered or returned-from-review	→ In Review, → Decommissioned	Owner
In Review	Submitted for governance review	→ Approved, → Withdrawn, → Decommissioned	AI Governance Lead
Approved	Approved but not yet promoted to production	→ Active, → Withdrawn, → Decommissioned	AI Governance Lead + (Zone 3) Compliance Officer
Active	Live, in production, in scope of attestation	→ Deprecated, → Decommissioned	Owner with notification to AI Governance Lead
Deprecated	Scheduled for decommission; no new use; existing use grandfathered	→ Decommissioned, → Active (rare; requires Compliance Officer countersignature)	Owner + AI Governance Lead
Decommissioned	Removed from service; record retained	(terminal)	AI Governance Lead + Records Manager (binds the record under retention)

10.1 Portal procedure for a single state transition

Open the register-of-record SharePoint list as the operator authorized for the target state per the table above.
Locate the register item by AgentID (canonical join key).
Click Edit. Update the Lifecycle State field. Update Last Reviewed and Next Review Due. Add a comment entry stating the transition reason and reference (change ticket, attestation cycle, incident ID).
Save. The SharePoint list update is logged in the Unified Audit Log under operations SharePointFileOperation / ListItemUpdated with the operator's UPN and timestamp.
Screenshot description: SharePoint register list item edit form with Lifecycle State dropdown changed from "Active" to "Deprecated", a Comments box populated with "Deprecated per change ticket CHG-2026-04-0119; superseded by AgentID 8c3f...; deprecation effective 2026-05-01", and the audit-log timestamp banner at the top.

10.2 Bulk state transition — defer to PowerShell

For environment retirement, bulk-deprecation, or any transition exceeding ~10 register items, switch to PowerShell Setup. The portal procedure is acceptable but loses the idempotency and hashing guarantees of the scripted flow.

10.3 Decommission gating

A transition to Decommissioned requires, in addition to the signatures above:

Confirmation that the underlying agent has been disabled in its source surface (Plane 1 / Plane 2 / Plane 3) and that the disablement event is in the Unified Audit Log.
Confirmation that all grounding sources have been re-evaluated (Control 4.6 hand-back).
Confirmation that any in-flight conversations or transcripts have been preserved per Control 1.19 and the records have been bound under Control 1.9.
Capture of the final-state evidence pack (3.1-Decommission-{AgentID}-{YYYY-MM-DD}.zip).

10.4 Withdrawn transition (recovery from In Review or Approved)

A Withdrawn transition returns an agent to Draft. It is used when the Owner wishes to revise the registration before re-submission, or when the AI Governance Lead identifies a gap that requires Owner-side rework. Withdrawn is not the same as Decommissioned; the register row remains in Draft and is not a record-of-removal event.

§11. Orphaned, dormant, and shadow-agent workflows (portal procedure)

This playbook detects and routes. The remediation procedure itself lives in Control 3.6. The handoff is on the AgentID.

11.1 Orphan categories and detection

Category	Definition	Primary detection surface	Secondary detection
Departed-owner	Owner UPN is soft-deleted, hard-deleted, or marked as `# (deleted)`	Plane 2 Maker Inventory `Owner = System Account` filter	Plane 1 Risks column "Owner inactive"; Graph user enumeration via PowerShell
License-stripped	Owner's M365 Copilot or Power Platform license was removed	Plane 1 Risks column; Plane 2 owner inactivity	Entra license assignment audit log
Group-owned (anti-pattern)	Owner is a security group rather than a named human	Manual scan of Owner column	Stitching workbook validation rule
Dormant	No agent activity beyond the zone threshold	Plane 1 Last activity column (preview); Sentinel telemetry per Control 3.9	Plane 2 Modified date as proxy
Shadow	Agent exists in Plane 2 / Plane 3 but not in the register list	§7 stitching `Single-plane` flag	Manual sweep of PPAC Default environment
Mis-registered	Register row exists but no live agent in any plane	§7 stitching `Disappeared` flag	Owner attestation contradiction

11.2 Departed-owner portal workflow

From Plane 1 (Copilot Hub Inventory → Agents tab), filter Risks = "Owner inactive" or "Ownerless".
For each result:
Click Manage Ownerless → assign Owner to a named human (the agent's business-line manager or the AI Governance Lead's designate); never assign to a group.
The action logs OwnerChanged in the Unified Audit Log; capture the entry as evidence.
From Plane 2 (PPAC Manage → Inventory), filter Owner = System Account for cross-confirmation.
Update the register row to reflect the new Owner; transition Lifecycle State to In Review until the new Owner countersigns the attestation.
SLA: Zone 3 = 5 business days from detection to new-Owner sign-off; Zone 2 = 10 business days; Zone 1 = 30 business days.

11.3 Dormant workflow

Identify dormant candidates from Plane 1 Last activity (where exposed) and Plane 2 Modified date.
Open the agent details and confirm zero activity beyond the zone threshold (default: Zone 3 = 90 days, Zone 2 = 180 days, Zone 1 = 365 days; verify firm-specific WSP).
Notify the Owner with a 30-day cure period.
If the Owner does not respond, transition Lifecycle State to Deprecated and notify the AI Governance Lead. After a further 60 days, transition to Decommissioned per §10.3.

11.4 Shadow-agent workflow

Shadow agents — created in Plane 2 (typically Default environment) but never registered — are the most common Zone-classification bypass.

From Plane 2 (PPAC Resources → Copilot agents), filter Environment = Default. Every row is a candidate.
For each candidate, open a Draft register row. Capture the Plane 2 owner as the tentative Owner. Notify the tentative Owner with a 5-business-day cure window.
If the Owner accepts ownership: complete the canonical metadata, classify Zone (most Default-environment agents are Zone 1; any with Highly Confidential grounding must escalate to Zone 3 and migrate to a Managed Environment per Control 2.1).
If the Owner rejects ownership or does not respond within the cure window: transition to Decommissioned with the AI Governance Lead's countersignature. The deletion event must be captured in the §13 evidence pack.

11.5 Mis-registered (Disappeared) workflow

From the §7 stitching flag list, take each Disappeared row.
Cross-check the Plane 2 Maker Inventory ledger for a deletion event.
If deletion is authorized (change ticket on file): transition to Decommissioned.
If deletion is unauthorized: open a Sev-2 governance incident under Control 3.4. The unauthorized-deletion event is also a Records Management investigation per Control 1.9.

§12. Quarterly attestation procedure (the three-signature workflow)

The quarterly attestation is the operational discipline that makes the register defensible. Every Zone 3 agent must be attested every 90 days; Zone 2 every 180 days; Zone 1 every 365 days.

12.1 Pre-attestation readiness

Per-plane exports captured per §3.6, §4.6, §5.5, §6.4 within 7 calendar days of the attestation date.
Stitching completed per §7 and AI Governance Lead has signed the stitched register.
Orphan workflows from §11 cleared (no open orphan tickets older than the zone SLA).
DLP and sensitivity-label checks per §9.3 and §9.4 completed for every Zone 2/3 register row.

12.2 The three signatures

The attestation requires three signatures, in this order, by three distinct human individuals. Group sign-off is prohibited; SoD requires that the same human MUST NOT sign as both Owner and AI Governance Lead for the same register row.

Signer	Attests to	Signature artifact
Inventory Owner (the agent's named-human Owner)	Per-row attestation: "I confirm the canonical metadata is current and the agent operates within the registered Zone, grounding scope, and DLP/sensitivity posture."	SharePoint list item update with Owner UPN + timestamp + free-text comment
AI Governance Lead	Per-row review: "I have reviewed the per-plane evidence, confirmed the stitching, reconciled orphan workflows, and confirm the register accurately reflects the agent estate as of {date}."	SharePoint list item update with AI Governance Lead UPN + timestamp + free-text comment
Compliance Officer (Zone 3 only; Zone 2 may be delegated to a Compliance Officer designate per WSP)	Per-cycle attestation: "I have reviewed the AI Governance Lead's sign-off, the orphan SLA report, the sovereign-cloud determination, and confirm the cycle satisfies the firm's WSP and the regulatory commitments enumerated in the attestation memo."	Cycle-level signed PDF attestation memo countersigned by Compliance Officer

12.3 The attestation memo

Each cycle produces a single attestation memo (PDF) with:

Cycle ID ({YYYY-Qn}).
Cycle date and signature timestamps.
Counts: total agents, by Zone, by Lifecycle State, by Sovereign Cloud.
Orphan SLA report (open / closed / SLA-breach).
Stitching evidence reference (SHA-256 of the stitched register).
Per-plane evidence reference (SHA-256 of each plane export).
Sovereign-cloud determination reference.
Hedged-language attestation statement (per §0.0 above).
Three signatures (Owner row-level signatures referenced; AI Governance Lead and Compliance Officer per-cycle signatures embedded).
Next cycle target date.

The memo is filed under /_attestations/3.1-Attestation-{YYYY-Qn}.pdf, hashed (SHA-256), and the hash is recorded in the register library metadata.

12.4 Cadence and calendar

Zone	Attestation cadence	Calendar gating
Zone 3	≤ 90 days	Calendar-quarter-aligned; no exception without Compliance Officer countersignature
Zone 2	≤ 180 days	Calendar-half-aligned
Zone 1	≤ 365 days	Calendar-year-aligned

A missed attestation by more than the cadence threshold is a Sev-2 governance finding; by more than 2× the threshold is a Sev-1 escalation to the CISO and the AI Governance Council.

12.5 Bulk Owner attestation (portal-supported pattern)

For tenants with > 50 Zone 3 agents per attestation cycle, the per-row Owner sign-off is most efficiently driven via a SharePoint list view filtered by Owner UPN, surfaced to each Owner via Microsoft Lists desktop or mobile. Each Owner sees only their own rows and can attest in-place by editing the Last Reviewed and Comments fields, which records the SharePoint audit event. Do not use a Forms survey or generic SharePoint page for Owner attestation — the SharePoint list edit IS the audit-of-record event; a survey is not.

§13. Examiner audit-pull procedure

The examiner audit-pull is the highest-stakes operational use of this playbook. The procedure is invoked by FINRA Rule 8210 request, OCC examination, Federal Reserve SR 11-7 inquiry, SEC inquiry, NYDFS Part 500.13/.16/.17 request, CFTC Rule 1.31 request, or ad-hoc supervisory request from the Designated Supervisor / Registered Principal.

13.1 SLA targets (verify against firm WSP)

Trigger	Target SLA	Notes
FINRA Rule 8210 written request	≤ 5 business days from receipt	WSP-confirmed
OCC examination request (in-cycle)	≤ 30 calendar days	Per OCC examination procedures
Federal Reserve SR 11-7 inquiry	≤ 30 calendar days	Per firm escalation procedure
SEC inquiry (formal)	Per SEC subpoena timeline	Coordinate with General Counsel
NYDFS Part 500.17 (cybersecurity event)	≤ 72 hours notification; 90 days remediation	Coordinate with CISO
CFTC Rule 1.31 (recordkeeping)	Per CFTC request timeline
Ad-hoc supervisory (Designated Supervisor)	≤ 24 hours	Per FINRA Rule 3110 supervision

13.2 Point-in-time snapshot reconstruction

The examiner request will specify a date (or date range). Reconstruction proceeds as follows:

Locate the most recent stitched register snapshot on or before the examiner-specified date in /_evidence/{YYYY-Qn}/3.1-Register-{YYYY-MM-DD}.csv.
If no snapshot exists on or before the date, the next-best evidence is the per-plane exports captured nearest the date plus the prior cycle's stitched register; document the gap in the cover memo.
Verify SHA-256 of each artifact against the manifest. Any hash mismatch is an evidence-integrity escalation per Control 1.9.
Pull the corresponding Unified Audit Log range covering register-list mutations (operations ListItemUpdated / FileModified on the register library) for the period bracketing the snapshot — these are the Owner-attestation timestamps that prove the register was attested as of the snapshot date.
Pull the corresponding attestation memo PDF(s).

13.3 Examiner package contents

The package delivered to the examiner contains:

Cover memo (signed by Designated Supervisor / Registered Principal): describes scope, date range, snapshot reconstruction approach, hedged-language statement of what the inventory does and does not represent, list of attached artifacts with SHA-256 hashes.
Stitched register CSV (or the closest-available snapshot, with gap memo if applicable).
Per-plane exports for the snapshot period.
Attestation memos covering the period.
Sovereign-cloud determination memo in force at the snapshot date.
Orphan-SLA report for the period.
Unified Audit Log extract for register mutations during the period.
Schema definition file (3.1-canonical-schema-v{n}.json) in force at the snapshot date.
Manifest (text or PDF) listing every file with SHA-256.

13.4 Chain of custody

Every examiner-pull invocation creates a chain-of-custody record stored under /_examiner-pulls/{YYYY-MM-DD}-{request-ID}.pdf containing:

Examiner identity, agency, and request reference.
Designated Supervisor / Registered Principal who authorized the pull.
Manifest of artifacts included with SHA-256 hashes.
Delivery method (encrypted file transfer, secure portal, paper) with delivery confirmation.
Receiving examiner acknowledgement (where obtainable).

13.5 Reverse-burden language

The cover memo MUST include the hedged-language statement from §0.0. Do not state "this is a complete record of all AI agents in the tenant." State instead: "This package represents the canonical agent register stitched from the six discovery surfaces enumerated in §0.3 of the firm's Control 3.1 procedure, attested as of {date}, with the limitations and sovereign-cloud caveats documented in the attached determination memo."

§14. Zone-specific portal workflow differentials

Step	Zone 1 (Personal)	Zone 2 (Team)	Zone 3 (Enterprise)
Required canonical fields (§1.2)	Owner, Display Name, Agent Type, Platform, Zone, Lifecycle State, Last Reviewed, Next Review Due	Above + Backup Owner, Business Justification, Data Classification, Connected Knowledge Sources, Connected Actions, Plugins, Foundation Model, Environment, Effective Sensitivity Label, DLP Policy Mapping, Sovereign Cloud, Approval Records	All fields
Pre-flight gates (§2)	PRE-01, PRE-02 (subset)	PRE-01, PRE-02, PRE-03, PRE-04	All five gates
Stitching cadence (§7)	Annual	Semi-annual	Quarterly
Orphan SLA (§11)	30 business days	10 business days	5 business days
Attestation cadence (§12)	≤ 365 days	≤ 180 days	≤ 90 days
Attestation signers (§12.2)	Owner	Owner + AI Governance Lead	Owner + AI Governance Lead + Compliance Officer
Examiner-pull readiness (§13)	Best-effort within SLA	Standard	Pre-staged; ≤ 5 business days for FINRA 8210
Audit-Log Reference (§1.2)	Optional	Recommended	Required
Risk Register Reference	Optional	Recommended	Required
Validation Evidence Pack	Optional	Recommended	Required
Sovereign-cloud determination memo	Tenant-level	Tenant-level	Per-agent annotation
Sentinel register-deviation alert (Control 3.9)	Optional	Recommended	Required
Preservation Lock on register library (§8.3)	Recommended	Required	Required
Per-row Owner attestation interface (§12.5)	Annual reminder email	Semi-annual SharePoint list view	Quarterly Microsoft Lists dashboard

14.1 Zone-3 customer-facing reverse burden

Any Zone 3 agent that touches customer interactions, customer NPI/MNPI data, recordkeeping outputs, or trade-related decisions carries a reverse-burden posture: in any examination, the firm must affirmatively demonstrate the agent was registered, attested, and DLP/sensitivity-mapped at the time of the customer touch. The §13 procedure is the demonstration vehicle.

14.2 Zone migration

When an agent's grounding scope, data classification, or business use changes such that its Zone classification must change:

Up-zone (Zone 1 → 2 or 2 → 3): Required immediately upon discovery; freeze the agent (transition to In Review) until the higher-zone metadata is fully populated and the higher-zone signers attest. Migrate environment per Control 2.1. The §11 §11.4 shadow-agent workflow may be the trigger.
Down-zone (Zone 3 → 2 or 2 → 1): Allowed only with Compliance Officer countersignature and only after a full attestation cycle's evidence supports the lower-risk classification. Down-zoning a Zone 3 agent is a §11 governance review item.

§15. Anti-pattern catalog

Each anti-pattern below has been observed in FSI tenants. Detection is part of the §11 review and the §12 attestation. Any occurrence is a finding.

15.1 The "spreadsheet register"

Pattern: Register lives in an Excel file on a shared drive or in a Teams chat. Why it fails: No retention binding, no audit log of mutations, no Preservation Lock, fails SEC 17a-4(f), fails Control 1.9. Fix: Migrate to a SharePoint list with auto-apply retention label per §8 within 30 days.

15.2 The "single-pane illusion"

Pattern: Operator treats the M365 Copilot Hub Inventory (Plane 1) as the complete register. Why it fails: Plane 1 misses Copilot Studio agents not published to M365, Custom Engine Agents with Entra-only registration, Default-environment shadow agents. Fix: Stitch all six planes per §7 every cycle; no exceptions.

15.3 The "group-owner" anti-pattern

Pattern: Owner field set to a security group, distribution list, or dynamic group. Why it fails: Group ownership defeats FINRA 3110 supervisory accountability, defeats orphan detection (no individual to leave the firm), defeats attestation (no individual to sign). Fix: Owner MUST be a named human; Backup Owner MUST be a distinct named human. Group ownership is a finding at any zone.

15.4 The "service-account-as-Owner" anti-pattern

Pattern: Owner is a service account or unattended automation account. Why it fails: Same supervisory failure as group ownership; service accounts cannot attest. Fix: Service-account creation may be acceptable for runtime authentication, but the Owner field must be a named human accountable for the service account.

15.5 The "self-attest" anti-pattern

Pattern: The same human signs as both Owner and AI Governance Lead for the same register row. Why it fails: Defeats SoD; defeats FINRA 3110 supervisory independence; defeats FINRA 25-07 governance posture. Fix: Enforced by the §12.2 SoD rule; flagged at attestation.

15.6 The "annual-only" anti-pattern

Pattern: Zone 3 agent attested only annually because Zone 1 cadence was applied by default. Why it fails: Misses 3 quarterly cycles of FINRA 4511 / SEC 17a-4 evidence; reverse-burden defeated. Fix: Drive attestation cadence from Zone field; flag any Zone 3 with Last Reviewed > 90 days.

15.7 The "Default environment" anti-pattern

Pattern: Production agents created in the Power Platform Default environment. Why it fails: Default environment cannot be a Managed Environment in many tenant configurations; DLP-policy mapping is weakest; orphan signal is silent. Fix: Migrate to a Managed Environment per Control 2.1; use the §11.4 shadow workflow for any Default-environment agent surviving discovery.

15.8 The "missing AppID" anti-pattern

Pattern: Register row has no Enterprise App / Service Principal ID for an Entra-backed agent. Why it fails: Breaks the Plane 3 ↔ Plane 1/2 join; breaks Sentinel correlation per Control 3.9; breaks the §6 orphan workflow when a service principal is removed independently. Fix: Stitching workbook validation rule must reject a Zone 2/3 register row missing the AppID.

15.9 The "stale stitching" anti-pattern

Pattern: Stitching is run once and treated as authoritative for multiple cycles. Why it fails: Misses new agents, owner changes, environment moves, orphan emergence. Fix: Stitching MUST be run at every attestation cycle; ad-hoc on examiner trigger; opportunistically on Sentinel deviation alert.

15.10 The "preview-as-authoritative" anti-pattern

Pattern: Treating Plane 4 (Agent 365 preview) as the sole or primary register surface. Why it fails: Preview surfaces lack stable schema, lack sovereign-cloud parity, may regress between monthly builds. Fix: Preview surfaces are additive cross-check evidence until GA in the operating cloud and re-signed in the §1.5 memo.

15.11 The "screenshot-only" anti-pattern

Pattern: Attestation evidence consists of screenshots only, with no CSV exports and no SHA-256 hashes. Why it fails: Screenshots are not tamper-evident; not machine-comparable cycle-over-cycle; weak under SEC 17a-4(f). Fix: Screenshots are supplementary; the CSV export with SHA-256 hash is the primary artifact.

Pattern: AI Governance Lead "approves" attestation by failing to object within a window. Why it fails: Implicit approval is not a signature; not auditable; defeats the three-signature workflow. Fix: Each signer MUST explicitly attest in the SharePoint list (rows) and in the memo PDF (cycle); silence is not consent.

15.13 The "Copilot Studio = inventory" anti-pattern

Pattern: Power Platform Admin treats PPAC as the register and ignores M365 Copilot Hub, Entra, SharePoint. Why it fails: Misses Plane 1 declarative agents, Plane 3 Custom Engine Agents, Plane 6 Connected Apps. Fix: AI Governance Lead owns the cross-plane stitching; PPAC alone is not the register.

15.14 The "license-strip = decommission" anti-pattern

Pattern: Operator believes that revoking the Owner's M365 Copilot license decommissions the agent. Why it fails: License strip removes the Owner's ability to use the agent but does not remove the agent itself; the agent persists ownerless and may continue to serve other users until disabled in source surface. Fix: Decommission is a Lifecycle State transition per §10.3 with explicit source-surface disablement; license strip is a §11 orphan-detection signal, not a decommission.

15.15 The "exception without evidence" anti-pattern

Pattern: A canonical-schema validation rule is waived without a corresponding Exception Reference. Why it fails: Defeats the schema contract; downstream controls cannot distinguish a populated waiver from a missing field. Fix: Every waived field MUST have an Exception Reference URL pointing to a Compliance Officer–signed exception with expiry; the exception expiry MUST be re-attested at the next attestation cycle.

§16. Verification handoff

Verification of this playbook's outputs lives in Verification & Testing. The handoff is:

This playbook produces the per-plane exports, the stitched register, the attestation memo, the chain-of-custody record, and the §13 examiner package.
Verification & Testing validates the integrity, completeness, and SLA-conformance of those outputs.

Verification entry criteria:

All §2 pre-flight gates signed off.
Per-plane exports captured per §3.6, §4.6, §5.5, §6.4 with SHA-256 in the manifest.
Stitching completed per §7 with the AI Governance Lead's signature.
Orphan workflow per §11 closed within zone SLA.
Attestation memo per §12 prepared and ready for Compliance Officer countersignature.

Verification will return one of: PASS (Compliance Officer can sign), CONDITIONAL (named gaps to remediate before sign), or FAIL (cycle restart required).

§17. Troubleshooting handoff

Symptom-driven diagnosis lives in Troubleshooting. Most-common entry points:

"Plane 1 export is missing columns visible in the grid" — Troubleshooting §T-01.
"Plane 2 grid is capped at 500 rows but the tenant has more agents" — Troubleshooting §T-02.
"Plane 3 Agent Registry blade is unavailable in our cloud" — Troubleshooting §T-03.
"Stitching produces a high Owner-mismatch count" — Troubleshooting §T-04.
"Manage Ownerless action returns an error" — Troubleshooting §T-05.
"Attestation Owner cannot edit the SharePoint list" — Troubleshooting §T-06.
"DAG report shows zero sites with Copilot grounding scope" — Troubleshooting §T-07.
"Preservation Lock cannot be applied — error 'records management not enabled'" — Troubleshooting §T-08.
"Examiner pull SHA-256 hash mismatch" — Troubleshooting §T-09.
"Per-plane export hash matches manifest but stitched register hash does not" — Troubleshooting §T-10.

§18. Evidence pack — the 25 artifacts

A complete cycle produces (at least) the following artifacts, all hashed and stored under the register-of-record library with retention/Preservation Lock binding:

#	Artifact	Naming	Source
1	Plane 1 Agents export	`3.1-Plane1-Agents-{date}.csv`	§3.6
2	Plane 1 Declarative agents export	`3.1-Plane1-Declarative-{date}.csv`	§3.3
3	Plane 1 Extensions export	`3.1-Plane1-Extensions-{date}.csv`	§3.4
4	Plane 2 Resources → Copilot agents export	`3.1-Plane2-Resources-{date}.csv`	§4.6
5	Plane 2 Maker Inventory export	`3.1-Plane2-MakerInventory-{date}.csv`	§4.5
6	Plane 3 Enterprise apps export	`3.1-Plane3-EnterpriseApps-{date}.csv`	§5.5
7	Plane 3 App registrations export (PowerShell-sourced)	`3.1-Plane3-AppRegistrations-{date}.csv`	sibling PowerShell
8	Plane 3 Agent Registry export (where GA)	`3.1-Plane3-AgentRegistry-{date}.csv`	§5.3
9	Plane 4 Agent 365 export (where entitled)	`3.1-Plane4-AgentList-{date}.csv`	§6.4
10	Plane 4 Agent 365 ownerless queue (where entitled)	`3.1-Plane4-Ownerless-{date}.csv`	§6.4
11	Plane 6 Connected Apps export	`3.1-Plane6-ConnectedApps-{date}.csv`	§9.1
12	Plane 6 DAG report export	`3.1-Plane6-DAG-{date}.csv`	§9.2
13	Stitched register	`3.1-Register-{date}.csv` (+ `.xlsx` workbook)	§7
14	Schema definition in force	`3.1-canonical-schema-v{n}.json`	§1.2
15	Sovereign-cloud determination memo	`3.1-sovereign-cloud-determination-{YYYY-MM}.pdf`	§1.5
16	Pre-flight gate sign-offs (PRE-01 through PRE-05)	`3.1-PRE-{n}-{name}-{date}.pdf`	§2
17	Per-Owner row attestation log (SharePoint list export)	`3.1-OwnerAttestations-{YYYY-Qn}.csv`	§12.5
18	AI Governance Lead cycle sign-off	embedded in attestation memo	§12.2
19	Compliance Officer cycle sign-off	embedded in attestation memo	§12.2
20	Cycle attestation memo	`3.1-Attestation-{YYYY-Qn}.pdf`	§12.3
21	Orphan-SLA report	`3.1-OrphanSLA-{YYYY-Qn}.csv`	§11
22	Sentinel register-deviation alert log (Zone 3)	`3.1-SentinelDeviations-{YYYY-Qn}.csv`	Control 3.9
23	Unified Audit Log extract for register library mutations	`3.1-UAL-RegisterMutations-{YYYY-Qn}.csv`	Control 1.7
24	Manifest with SHA-256 of all above	`3.1-Manifest-{YYYY-Qn}.txt` (or `.pdf`)	sibling PowerShell
25	Examiner-pull chain-of-custody record (when invoked)	`3.1-ExaminerPull-{date}-{request-ID}.pdf`	§13.4

The manifest is the first artifact a Compliance Officer or examiner reads. Without it, the package has no integrity.

§19. Cross-references

This playbook depends on or is consumed by the following controls. Implementers must verify each link is current at deploy time.

Upstream (this playbook depends on):

Control 1.2 — Agent Registry and Integrated Apps Management — agent intake and approval that feeds Lifecycle State Draft → In Review.
Control 1.7 — Comprehensive Audit Logging — UAL pipeline that captures register-mutation events.
Control 1.9 — Records Management and Preservation Lock — Preservation Lock on register library.
Control 1.13 — Sensitive Information Types — sensitivity-label authoring that feeds §9.3 inheritance check.
Control 1.19 — eDiscovery for Agent Interactions — preserves transcripts at §10.3 decommission.
Control 2.1 — Managed Environments — environment classification reconciled at §1.2 Zone field.
Control 2.5 — Testing, Validation, and Quality Assurance — Validation Evidence Pack referenced in §1.2.
Control 1.5 — DLP and Sensitivity Labels — DLP business-data-group classifications consumed at §9.4.
Control 4.6 — Grounding Scope Governance — grounding inventory joined at §9.3.
Control 4.7 — Microsoft 365 Copilot Data Governance — sensitivity-label propagation reference.

Downstream (this playbook is consumed by):

Control 3.2 — Usage Analytics and Activity Monitoring — reads the canonical register on AgentID.
Control 3.4 — Incident Reporting and Root-Cause Analysis — joins incidents to register on AgentID.
Control 3.6 — Orphaned Agent Detection and Remediation — receives orphan handoffs from §11.
Control 3.8 — Copilot Hub and Governance Dashboard — surfaces register data to executive dashboards.
Control 3.9 — Microsoft Sentinel Integration — register-deviation alerts.
Control 3.11 — Centralized Agent Inventory Enforcement — publish-time gating on register completeness.
Control 3.3 — Compliance and Regulatory Reporting — examiner-pull packaging shares the §13 procedure.

Sibling playbooks for this control:

PowerShell Setup — bulk export, scheduled reconciliation, hashing, idempotent diffing.
Verification & Testing — pre-attestation readiness validation; evidence-pack completeness check.
Troubleshooting — symptom-driven diagnosis for portal, surface, stitching, and evidence problems.

§20. Closing reminders

No single surface is the inventory. The register of record is the stitched export, signed by the AI Governance Lead, bound to retention.
Owners are humans, not groups. Every Owner and Backup Owner is a named individual; group ownership is a finding at any zone.
Three signatures, three humans. Owner, AI Governance Lead, and (Zone 3) Compliance Officer; same human cannot occupy two attestor roles for the same row.
Preview surfaces are additive. Plane 4 Agent 365 and the Plane 3 Agent Registry blade are cross-check evidence until GA in your sovereign cloud and re-signed in the §1.5 memo.
Hash everything. Every exported artifact carries SHA-256 in the cycle manifest; the manifest is the first artifact in any examiner package.
Hedge the language. "Helps support compliance with" — never "ensures compliance" or "guarantees" or "complete inventory" or "single pane of glass" or "real-time discoverability".

Updated: April 2026 | Version: v1.4.0 | Maintained by: AI Governance Team