# Control 3.6: Orphaned Agent Detection and Remediation

**Control ID:** 3.6<br>
**Pillar:** Reporting<br>
**Regulatory Reference:** FINRA Rule 3110 (Supervision), FINRA Rule 4511 (Books and Records), FINRA RN 24-09, SEC Rules 17a-3 / 17a-4 (Recordkeeping), SOX Sections 302 / 404 (Internal Controls), GLBA 501(b), OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12), NYDFS 23 NYCRR 500<br>
**Last UI Verified:** April 2026<br>
**Governance Levels:** Baseline / Recommended / Regulated<br>

---

!!! tip "Agent 365 + Entra Agent ID Architecture"
    Where licensing, region, and tenant rollout permit, Agent 365 lifecycle governance (GA May 1, 2026) and Microsoft Entra Agent ID lifecycle workflows reduce reliance on manual PowerShell-based orphan scans. **Microsoft Entra Agent ID reached general availability in April 2026** ([Entra Agent ID — What's new](https://learn.microsoft.com/en-us/entra/agent-id/whats-new-agent-id)); the Lifecycle Workflows agent-sponsor task type remains labelled **Preview** in Microsoft Learn as of the verification date, so verify per-tenant rollout status in the Entra portal before relying on it for evidence. Both surfaces require Microsoft Agent 365 or Microsoft 365 E7 ("Frontier Suite") licensing. Until tenant parity is confirmed, treat the automated path as a supplement to — not a replacement for — the multi-surface PowerShell and reconciliation workflows in this control. See Controls [2.25](../pillar-2-management/2.25-agent-365-admin-center-governance-console.md) and [2.26](../pillar-2-management/2.26-entra-agent-id-identity-governance.md) for current availability and prerequisites.

!!! note "Frontier program and Agent 365 coexistence"
    Microsoft's Frontier program (Microsoft 365 E7: The Frontier Suite, US$99/user/month) remains active after the general availability of Microsoft Agent 365. Frontier provides early access to scenarios like Project Opal that are gated behind the Frontier subscription, while Agent 365 covers the core agent governance and administration surface. The two coexist; this control's guidance applies under both programs. See the [Frontier Suite get-started guide](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/get-started-frontier) and the [Agent 365 admin overview](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-365-overview) for current scope.

!!! warning "Sovereign Cloud Availability — GCC, GCC High, DoD"
    As of the verification date in this document, **Microsoft has not announced parity availability of the Agent 365 Admin Center Ownerless Agents governance card or of Microsoft Entra Agent ID lifecycle workflows in GCC, GCC High, or DoD** (see the corresponding admonitions in Controls [2.25](../pillar-2-management/2.25-agent-365-admin-center-governance-console.md) and [2.26](../pillar-2-management/2.26-entra-agent-id-identity-governance.md)). FSI tenants operating in sovereign clouds **must not** treat the automated detection paths above as technically enforceable. Implement the following compensating control instead:

    - **Quarterly manual reconciliation** of the [Control 1.2](../pillar-1-security/1.2-agent-registry-and-integrated-apps-management.md) authoritative agent registry against (a) the HR leaver list for the prior 90 days, (b) Entra disabled-user list, and (c) Power Platform maker / environment-owner exports.
    - Produce a **signed reconciliation worksheet** (PDF, signed by AI Governance Lead and Compliance Officer) listing every agent whose owner, sponsor, maker, or environment owner appears on any leaver/disabled list, with disposition (reassigned / archived / deleted) and approval reference.
    - Retain the worksheet under the same 6-year WORM retention as commercial-cloud orphan registers (see Evidence and Retention below).
    - Re-verify the sovereign roadmap quarterly via the [Microsoft 365 Government roadmap](https://aka.ms/m365gov-roadmap).

## Objective

Identify and remediate AI agents that lack assigned owners, have been abandoned, or are no longer actively maintained. Orphaned agents represent security, compliance, and operational risks that must be addressed through automated detection and structured remediation workflows.

This control **supports compliance with** FINRA Rule 3110, FINRA Rule 4511, FINRA RN 24-09 / Rule 3110, SEC Rules 17a-3 / 17a-4, SOX Sections 302 / 404, GLBA 501(b), OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12), and NYDFS 23 NYCRR 500 by providing detection, remediation-workflow, and evidence-retention mechanisms for agent identities that have lost an accountable human owner. **It does not replace written supervisory procedures, registered-principal supervisory review, or the obligations of a designated supervisor under FINRA Rule 3110** where those obligations apply to AI-enabled business activity.

---

## Why This Matters for FSI

- **FINRA Rule 3110 (Supervision):** A documented orphan-detection and remediation workflow supports — but does **not replace** — registered-principal supervisory review of AI-enabled business activity under FINRA Rule 3110 and RN 24-09.
- **FINRA Rule 4511 / FINRA RN 24-09:** Unowned agents may generate records without proper supervision; orphan registers and remediation evidence are records of business that must be preserved.
- **SEC Rules 17a-3 / 17a-4:** Orphan registers, detection-run logs, remediation tickets, and reassignment approvals are records of business and must be preserved on a non-rewriteable, non-erasable medium for the applicable retention period (6 years for most books-and-records; 3 years easily accessible).
- **SOX Sections 302 / 404:** Orphan remediation evidence is part of the IT general-controls population that supports management's quarterly and annual internal-controls assertions.
- **GLBA 501(b):** Unmanaged agents accessing customer data violate safeguard requirements.
- **OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12):** Third-party risk extends to unmonitored agent deployments.
- **NYDFS 23 NYCRR 500:** Section 500.7 (access privileges) and 500.13 (asset management) require periodic review and termination of access for departed personnel; this control extends that obligation to non-human (agent) identities.
- **Security Risk:** Orphaned agents are prime targets for exploitation.

---

!!! info "No companion solution by design"
    Not all controls have a companion solution in [FSI-AgentGov-Solutions](https://github.com/judeper/FSI-AgentGov-Solutions); solution mapping is selective by design. This control is operated via native Microsoft admin surfaces and verified by the framework's assessment-engine collectors. See the [Solutions Index](../../reference/solutions-index.md#coverage-scope) for the catalog and coverage scope.


## Control Description

!!! note "Terminology: 'Ownerless' (Microsoft) vs 'Orphaned' (Framework)"
    Microsoft's surface terminology in the Agent 365 admin center and in Microsoft Entra Agent ID is **"ownerless agent"** — defined narrowly as an agent identity with no assigned owner principal. This framework uses the broader term **"orphaned agent"** to encompass five distinct loss-of-accountability conditions: (1) ownerless (no assigned owner), (2) departed-owner / departed-sponsor (owner or sponsor disabled or beyond `employeeLeaveDateTime`), (3) departed-maker (Power Platform maker disabled), (4) deleted-environment, and (5) inactivity beyond zone-specific thresholds. Every Microsoft "ownerless agent" is an orphaned agent in this framework; not every orphaned agent in this framework appears on the Microsoft "ownerless" surface. Detection logic must reconcile both. **Shadow agents** (unregistered agents lacking Entra Agent ID) remain a separate category covered later in this control.

This control establishes automated detection of orphaned agents through owner-status monitoring, inactivity tracking, and environment health checks. Remediation workflows **support** structured reassignment, archival, or deletion under documented approvals; remediation does not occur automatically without the approval gates required by the agent's zone.

| Capability | Description |
|------------|-------------|
| **Owner Monitoring** | Detect when agent owner departs or becomes inactive |
| **Activity Tracking** | Flag agents with zero activity for 90+ days |
| **Health Checks** | Identify agents with broken connectors or environments |
| **Remediation Workflow** | Structured process for reassign/archive/delete |
| **SLA Enforcement** | Time-bound remediation with escalation |

### Agent Ownership Reassignment

Microsoft Power Platform supports native agent ownership reassignment through the Power Platform Admin Center and the `Microsoft.PowerApps.Administration.PowerShell` module ([Microsoft Learn: Manage app owners](https://learn.microsoft.com/power-platform/admin/powerapps-powershell)). Verify GA status and cmdlet syntax against current Microsoft Learn before relying on the snippet below. The recommended remediation workflow is:

1. **Agent 365 inline Assign Owner** on the Ownerless Agents card (fastest, single-agent).
2. **Confirm or override the 2.26 sponsor manager-transfer default** (Entra Agent ID).
3. **PPAC / Microsoft Copilot Studio maker reassignment** for environment-scoped agents.
4. **Bulk Microsoft Graph / PowerShell** for multi-agent cleanup (always with dry-run + safety gates).

| Method | Description | Requirements |
|--------|-------------|--------------|
| **PPAC Portal** | UI-based reassignment in Agent Registry | Power Platform Admin role |
| **PowerShell** | Scripted bulk reassignment | `Microsoft.PowerApps.Administration.PowerShell` module |
| **Power Automate** | Automated reassignment workflows | Integration with HR departure triggers |

**New Owner Requirements:**

- Active Copilot Studio license (or equivalent)
- Member of the agent's environment
- Appropriate Maker/Admin role in environment

**PowerShell Reassignment:**

```powershell
# Reassign agent ownership
Set-AdminPowerAppOwner -AppName $agentId `
    -EnvironmentName $envName `
    -AppOwner $newOwnerPrincipalId
```

**PPAC Portal Path:**

1. Navigate to **admin.powerplatform.microsoft.com**
2. Select **Manage** > **Agents** (or **Resources** > **Power Apps**)
3. Locate orphaned agent
4. Select **...** > **Change owner**
5. Search and select new owner
6. Confirm reassignment

### Detection Signal Sources

| # | Orphan Category | Primary Detection Surface | Underlying Source | Linked Control | Risk | SLA (Z3 / Z2 / Z1) |
|---|---|---|---|---|---|---|
| 1 | Ownerless (no owner assigned at publish/activate) | Agent 365 Admin Center > Overview > **Ownerless Agents** governance card | Agent 365 unified registry | [2.25](../pillar-2-management/2.25-agent-365-admin-center-governance-console.md) | Critical | 7d / 14d / 30d |
| 2 | Sponsor-departed (Entra Agent ID) | Entra ID Governance > Lifecycle Workflows > **Agent sponsor tasks** trigger on HR connector `employeeLeaveDateTime` | Microsoft Entra Agent ID + HR connector | [2.26](../pillar-2-management/2.26-entra-agent-id-identity-governance.md) | Critical | Real-time / 24h / 10bd |
| 3 | Maker-departed (Power Platform) | Power Platform Admin Center > Resources > Power Apps > **Maker** = disabled user | Dataverse + Entra user state | [1.2](../pillar-1-security/1.2-agent-registry-and-integrated-apps-management.md) | Critical | 7d / 14d / 30d |
| 4 | Environment-owner departed (Copilot Studio) | Power Platform Admin Center > Environments > **Owner** = disabled user | Power Platform environment metadata | [1.2](../pillar-1-security/1.2-agent-registry-and-integrated-apps-management.md) | Critical | 3d / 7d / 14d |
| 5 | SharePoint agent author-disabled | SharePoint Admin Center > More features > Copilot agents > **Author** = disabled user | SharePoint embedded agent metadata | [1.2](../pillar-1-security/1.2-agent-registry-and-integrated-apps-management.md) | High | 7d / 14d / 30d |
| 6 | Environment deleted | Power Platform Admin Center > Recycle bin / audit log | Power Platform environment audit | [1.2](../pillar-1-security/1.2-agent-registry-and-integrated-apps-management.md) | Critical | 3d / 3d / 7d |
| 7 | Inactivity (no invocations) | Agent 365 Analytics + Power Platform analytics | Telemetry | [3.13](3.13-agent-365-admin-center-analytics.md) | Medium | 30d / 60d / 90d |
| 8 | License expired | M365 admin center license assignment | Entra licensing | [2.26](../pillar-2-management/2.26-entra-agent-id-identity-governance.md) | High | 7d / 14d / 30d |
| 9 | Connector / dependency broken | Power Platform connector health | Power Platform telemetry | [1.2](../pillar-1-security/1.2-agent-registry-and-integrated-apps-management.md) | Medium | 14d / 30d / 30d |
| 10 | Shadow agent (registry gap) | Defender for Cloud Apps + tenant scan reconciled against registry | Multi-source | [1.2](../pillar-1-security/1.2-agent-registry-and-integrated-apps-management.md) | Critical | 7d / 14d / 30d |

The Agent 365 Ownerless Agents card (signal #1) is the rapid-visibility entry point but covers **only category #1**. Categories #2-#10 must be detected through their respective surfaces and reconciled into a single orphan register that is the system of record for this control.

### Agent 365 Admin Center: Ownerless Agents Governance Card

!!! info "Availability"
    The Ownerless Agents governance card on the Agent 365 Overview page is available at GA (verify date on [Microsoft Agent 365 overview](https://learn.microsoft.com/microsoft-agent-365/overview)) with the Agent 365 add-on. Basic ownerless-agent filtering in the All Agents list is generally available without the add-on.

The Agent 365 **Overview** page in the M365 admin center includes an **Ownerless Agents** governance card that provides immediate visibility into the ownerless-agent population without requiring a manual query or PowerShell run. This card should be the first stop during routine orphan review cycles.

**Navigation Path:**

```text
M365 admin center
  > Agents
    > Overview
```

#### Card Contents and Controls

| Card Element | Description |
|---|---|
| Total ownerless agent count | Total number of agents in the tenant without an assigned owner |
| Week-over-week delta badge | Trend indicator showing whether the ownerless count has increased or decreased relative to the prior week |
| Assign Owner button | Direct navigation to the ownerless-agents filtered view where assignment actions can be taken |

The week-over-week delta badge provides early warning of governance drift. A sustained increase in a Zone 2 or Zone 3 environment is a control deficiency signal that should trigger an accelerated remediation cycle.

#### Integration with Existing Orphan Detection Workflows

This card provides a rapid-visibility layer that supplements - and does not replace - the PowerShell and PPAC-based orphan-detection processes documented elsewhere in this control.

!!! note "Governance review sequence"
    During routine governance reviews, administrators should check the Ownerless Agents card **first** to assess the current state of the ownerless-agent population before proceeding to detailed PPAC or PowerShell-based investigation. The card provides the summary; the existing workflows provide the remediation mechanisms.

#### Zone-Specific Monitoring Cadence

| Zone | Ownerless Agents Card Review Frequency |
|---|---|
| Zone 1 | Monthly |
| Zone 2 | Weekly |
| Zone 3 | Daily |

SLAs for owner assignment or decommission are governed by the Detection Signal Sources table above (signal #1, column "SLA (Z3 / Z2 / Z1)"). Where an SLA conflict arises between sources for the same agent, **the tighter (shorter) SLA applies** and is documented on the remediation ticket.

#### Evidence and Documentation

Capture a screenshot or exported record of the Ownerless Agents card count and delta badge as part of each governance review cycle. Store those review records in the ITSM system or equivalent compliance evidence repository linked to the corresponding governance review ticket.

---

## Shadow Agent Detection

!!! note "Terminology Note"
    **Shadow agent** is now Microsoft's official terminology for unregistered agents lacking a Microsoft Entra Agent ID. The framework uses the same term consistently to describe discovered agents that exist in the tenant but remain outside the governed identity perimeter.

Shadow agents are AI agents that exist within the tenant but are not registered in the organization's agent inventory. Unlike orphaned agents (known agents that lose owners), shadow agents represent undiscovered or unmanaged deployments that bypass governance controls entirely.

### Why Shadow Agents Are Critical for FSI

- **Regulatory Gap** - Unregistered agents cannot be included in regulatory reporting or examination responses
- **Data Exposure** - Shadow agents may access customer data without proper DLP controls
- **Audit Failure** - Examiners expect complete agent inventories; shadow agents create material gaps
- **Security Risk** - Unmonitored agents are prime vectors for data exfiltration or abuse

### Discovery Methods

| Method | Coverage | Frequency | Tools |
|--------|----------|-----------|-------|
| **PowerShell Tenant Scan** | Copilot Studio, Power Platform | Weekly | PowerShell, Power Platform Admin Center |
| **Defender for Cloud Apps** | All cloud-connected agents | Continuous | Microsoft Defender XDR |
| **Entra App Registration Audit** | Agents with app registrations | Weekly | Entra ID, Microsoft Graph |
| **M365 Admin Center Review** | Integrated apps, Copilot agents | Weekly | M365 Admin Center |

### Shadow Agent Discovery Process

**Step 1: Enumerate All Agents in Tenant**

Use multiple discovery sources to build a comprehensive list:

```powershell
# Power Platform agents
Get-AdminPowerApp -EnvironmentName $env | Where-Object { $_.Properties.appType -eq "Agent" }

# Copilot Studio agents
# REVIEW: Verify Get-CsTeamsApp AppType property exists in current MicrosoftTeams module
Connect-MicrosoftTeams
Get-CsTeamsApp | Where-Object { $_.AppType -eq "Bot" }

# Entra Agent ID identities are exposed as service principals (Microsoft Entra
# Agent ID reached general availability in April 2026; verify per-tenant
# rollout status in the Entra portal). Standard Entra userType values remain
# 'Member' / 'Guest' — there is no 'AgenticUser' userType. Validate the exact
# tag/property string against current learn.microsoft.com/entra/agent-id
# documentation.
Get-MgServicePrincipal -All `
    | Where-Object { $_.Tags -contains 'Agent' -or $_.ServicePrincipalType -eq 'Agent' }
```

**Step 2: Compare Against Agent Registry**

Cross-reference discovered agents against the inventory from Control 3.1:

- Match by Agent ID, App ID, or unique identifier
- Flag any agents not found in the registry as "Shadow Agent"
- Document discovery source and discovery date

**Step 3: Risk Assessment**

For each shadow agent, assess:

| Factor | Questions |
|--------|-----------|
| **Data Access** | What data sources can this agent access? |
| **Owner Identification** | Can we identify who created this agent? |
| **Business Purpose** | Is there a legitimate business need? |
| **Compliance Impact** | Does this affect regulated data or processes? |

**Step 4: Remediation Decision**

| Decision | Criteria | Action |
|----------|----------|--------|
| **Register** | Legitimate business need, identifiable owner | Add to registry with proper metadata |
| **Transfer** | Valid agent, wrong owner/zone | Reassign and register |
| **Decommission** | No business need or owner | Disable and schedule deletion |
| **Escalate** | Accessing sensitive data, unknown origin | Security team review |

### Zone-Specific Shadow Agent Scanning

| Zone | Scan Scope | Frequency | Response |
|------|------------|-----------|----------|
| **Zone 1** | Personal workspace apps | Monthly | Register or decommission |
| **Zone 2** | Team environments, shared agents | Weekly | Register with owner assignment |
| **Zone 3** | All production environments | Daily | Immediate suspension pending review |

### Integration with Agent Inventory (Control 3.1)

Shadow agent detection feeds directly into the agent inventory:

1. **Discovery Feed** - Automated discovery results populate a "Pending Review" queue in the inventory
2. **Reconciliation Report** - Weekly report showing registry vs. tenant discrepancies
3. **Registration Workflow** - Streamlined process to register legitimate shadow agents
4. **Audit Evidence** - Detection logs demonstrate proactive governance for examiners

### Defender for Cloud Apps Integration

Microsoft Defender for Cloud Apps provides continuous shadow agent monitoring:

1. Navigate to **Microsoft Defender XDR** > **Cloud Apps** > **Cloud App Catalog**
2. Filter for AI/ML applications and agents
3. Review **Discovered Apps** for unmanaged agent activity
4. Configure alerts for new agent discoveries
5. Export findings for integration with agent registry

---

## Key Configuration Points

- Define orphan criteria: owner departed, inactive 90+ days, broken connectors, deleted environment
- Create SharePoint orphan tracking list with status, assigned reviewer, and action fields
- Configure Power Automate flow for weekly automated detection against Entra ID
- Establish remediation options: Reassign (transfer to new owner), Archive (disable), Delete (permanent removal)
- Define approval requirements by zone and action type
- Set SLAs for review and remediation with automatic escalation

---

## Zone-Specific Requirements

| Zone | Requirement | Rationale |
|------|-------------|-----------|
| **Zone 1** (Personal) | Monthly detection; team lead approval for deletion | Low risk, simple remediation |
| **Zone 2** (Team) | Weekly detection; manager approval for archive/delete | Team data exposure risk |
| **Zone 3** (Enterprise) | Immediate detection; director + compliance approval; auto-suspend if unresolved | Customer-facing risk, regulatory exposure |

---

## Roles & Responsibilities

| Role | Responsibility |
|------|----------------|
| AI Administrator | Operates the Agent 365 admin center Ownerless Agents governance card per zone cadence; executes inline Assign Owner remediation; signs weekly card snapshot evidence. |
| Power Platform Admin | Executes detection runs and remediation across Power Platform surfaces (maker-departed, environment-owner departed, environment deleted); performs `Set-AdminPowerAppOwner` reassignments under documented approval. |
| Entra Agent ID Admin | Acts on Entra Agent ID sponsor-departed lifecycle-workflow tasks; executes sponsor reassignment or agent suspension per Control 2.26 SLAs. |
| Entra Identity Governance Admin | Configures and maintains the lifecycle workflows that emit sponsor-departure signals; configures HR connector mapping for `employeeLeaveDateTime`. |
| Entra Global Reader | Read-only inventory and reconciliation queries against Entra users / service principals / agent identities (least-privilege evidence pull). |
| AI Governance Lead | Owns the orphan register; approves Zone 3 remediation actions (archive / delete); signs quarterly attestation; chairs governance review sessions. |
| Purview Compliance Admin | Configures Purview retention labels enforcing 6-year WORM retention on orphan register, snapshots, and approval evidence. |
| HR / People Operations | Maintains the HR connector feed (joiner / mover / leaver, including `employeeLeaveDateTime`) that drives sponsor-departure detection. |
| Agent Sponsor / Agent Owner | Identified replacement owner for reassignment; certifies continued business need at remediation. |

---

## Related Controls

| Control | Relationship |
|---------|--------------|
| [1.2 - Agent Registry and Integrated Apps Management](../pillar-1-security/1.2-agent-registry-and-integrated-apps-management.md) | **Authoritative registry — reconciliation source.** Detection signals #3-#6 and #9-#10 are reconciled against the 1.2 registry; the 1.2 ownerless-app remediation process escalates unresolved exceptions into this control. Controls 1.2 / 2.25 / 2.26 are preventive layers; 3.6 is the reactive catch-and-remediate layer. |
| [3.1 - Agent Inventory](3.1-agent-inventory-and-metadata-management.md) | Source of owner and status data |
| [2.3 - Change Management](../pillar-2-management/2.3-change-management-and-release-planning.md) | Retirement workflow for orphans |
| [2.8 - Access Control](../pillar-2-management/2.8-access-control-and-segregation-of-duties.md) | Owner determines access rights |
| [3.5 - Cost Tracking](3.5-cost-allocation-and-budget-tracking.md) | Orphans contribute to wasted spend |
| [2.25 - Agent 365 Governance Console](../pillar-2-management/2.25-agent-365-admin-center-governance-console.md) | Operational interface for the Ownerless Agents governance card and related remediation actions |
| [2.26 - Entra Agent ID Identity Governance](../pillar-2-management/2.26-entra-agent-id-identity-governance.md) | Sponsorship and lifecycle governance reduce the ownerless-agent population upstream |

---

## Implementation Playbooks

!!! info "Step-by-Step Implementation"

    This control has detailed playbooks for implementation, automation, testing, and troubleshooting:

    - [Portal Walkthrough](../../playbooks/control-implementations/3.6/portal-walkthrough.md) — Step-by-step portal configuration
    - [PowerShell Setup](../../playbooks/control-implementations/3.6/powershell-setup.md) — Automation scripts
    - [Verification & Testing](../../playbooks/control-implementations/3.6/verification-testing.md) — Test cases and evidence collection
    - [Troubleshooting](../../playbooks/control-implementations/3.6/troubleshooting.md) — Common issues and resolutions

---

## Evidence and Retention

All artifacts produced by this control are **records of business** under FINRA Rule 4511 and SEC Rule 17a-4. Apply the following retention model:

| Artifact | Format | Retention | Storage Requirement |
|---|---|---|---|
| Orphan register (current state) | Structured (SharePoint list / Dataverse table) with append-only history | 6 years from agent decommission | Versioning enabled; deletion locked via Purview retention label |
| Weekly Ownerless Agents card snapshot | PNG screenshot + CSV export of underlying list | 6 years | WORM-equivalent (Purview retention label, immutable) |
| Detection-run logs (PowerShell, Power Automate) | JSON / signed log bundle | 6 years | SIEM cold storage with integrity hash |
| Remediation tickets (reassign / archive / delete) | ITSM record with approver, justification, timestamp | 6 years post-closure | ITSM with legal-hold capability |
| Sponsor/owner reassignment approval | Signed approval (digital signature or e-sign) | 6 years | Records management library, label-locked |
| Quarterly governance attestation | PDF signed by AI Governance Lead and Compliance Officer | 6 years | WORM-equivalent |
| Sovereign-cloud reconciliation worksheet | PDF, dual-signed | 6 years | WORM-equivalent |

The 6-year horizon supports compliance with FINRA Rule 4511 and SEC Rule 17a-4(b)(4); the WORM (non-rewriteable / non-erasable) requirement supports compliance with SEC Rule 17a-4(f). For Purview retention label configuration, see Control 3.2.

---

## Preventive Coverage (Pre-Orphan)

Detection and remediation are reactive. The orphan population is most effectively reduced upstream:

| Preventive Control | Mechanism | Linked Control |
|---|---|---|
| Owner required at publish | Agent 365 admin-gated publish/activate workflow rejects agents with no assigned owner | [2.25](../pillar-2-management/2.25-agent-365-admin-center-governance-console.md) |
| Sponsor required at agent identity creation | Entra Agent ID requires named sponsor; access-package assignment cannot complete without one | [2.26](../pillar-2-management/2.26-entra-agent-id-identity-governance.md) |
| Sponsor manager-transfer default | Entra built-in: when sponsor leaves, sponsorship transfers to the manager unless explicitly overridden | [2.26](../pillar-2-management/2.26-entra-agent-id-identity-governance.md) |
| Governed environment provisioning | Approval-gated environment creation with documented owner | [Environment Lifecycle Management playbook](../../playbooks/advanced-implementations/environment-lifecycle-management/index.md) |
| Maker license enforcement | License-based entitlement controls who can create agents in the first place | [1.2](../pillar-1-security/1.2-agent-registry-and-integrated-apps-management.md) |

A mature program reports both **post-orphan remediation throughput** *and* **pre-orphan prevention rate** (orphans avoided ÷ total agents created) in the quarterly attestation.

---

## Verification Criteria

Confirm control effectiveness by producing the following objective evidence; the AI Governance Lead samples and signs each on the documented cadence and retains for 6 years per the Evidence and Retention table.

1. **Detection-run completeness** — Signed PowerShell / Power Automate run-log bundles for every weekly cycle in the prior quarter (sample: 100% for Z3, ≥4 weeks for Z2/Z1). Each bundle includes start/end timestamp, signal sources queried, and counts per category.
2. **Card-vs-detection parity** — Side-by-side export showing the Agent 365 Ownerless Agents card count matches the orphan register's category-1 count for the same date (sample: 4 cycles per quarter; tolerance: zero variance unsubstantiated by a logged event between snapshots).
3. **SLA adherence** — Orphan-register report showing, per category and per zone, the percentage of items remediated within the SLA in the Detection Signal Sources table. Examiners will expect ≥95% for Z3.
4. **Reassignment integrity** — For a sample of 10 reassignments per quarter, evidence that the new owner satisfies the prerequisites (active license, environment membership, maker/admin role) and that permissions/metadata transferred (before/after export).
5. **Archive/delete approval** — For every Z3 archive or delete in the period: documented dual approval (AI Governance Lead + Compliance Officer for delete) with timestamp; ITSM ticket reference; retention-label state at deletion.
6. **Sovereign-cloud compensating control** (where applicable) — Quarterly dual-signed reconciliation worksheet (see Sovereign Cloud admonition).
7. **Retention enforcement** — Purview retention-label policy report showing the orphan register, weekly snapshots, and approval artifacts are bound to a ≥6-year retain-and-delete or retain-only label, with deletion locked.
8. **Preventive metric** — Quarterly attestation includes the pre-orphan prevention rate (orphans-avoided ÷ agents-created) and a year-over-year trend.

---

## Additional Resources

- [Manage Agents in Integrated Apps](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-copilot-agents-integrated-apps?view=o365-worldwide)
- [Power Platform Admin Center Resources](https://learn.microsoft.com/en-us/power-platform/admin/admin-documentation)
- [Entra ID User Management](https://learn.microsoft.com/en-us/entra/identity/users/)
- [Power Automate Scheduled Flows](https://learn.microsoft.com/en-us/power-automate/run-scheduled-tasks)
- [Microsoft Defender for Cloud Apps - Discover and Manage Shadow IT](https://learn.microsoft.com/en-us/defender-cloud-apps/tutorial-shadow-it)
- [Microsoft Learn: Agent 365 Identity (Preview)](https://learn.microsoft.com/en-us/microsoft-agent-365/developer/identity)
- [Microsoft Learn: Agent 365 Observability (Preview)](https://learn.microsoft.com/en-us/microsoft-agent-365/developer/observability)

### Agent ID Lifecycle Governance

> **Note:** **Microsoft Entra Agent ID reached general availability in April 2026** ([Entra Agent ID — What's new](https://learn.microsoft.com/en-us/entra/agent-id/whats-new-agent-id)). The Lifecycle Workflows agent-sponsor task type referenced below remains labelled **Preview** in Microsoft Learn at the verification date; verify per-tenant rollout status before relying on it as supervisory evidence.

Microsoft Entra Agent ID provides lifecycle governance capabilities that enhance orphan detection:

- **Sponsorship Model** - Agents require human sponsors; orphan detected when sponsor departs
- **Lifecycle Events** - Automatic notifications when agent identities require attention

- [Microsoft Learn: Governing Agent Identities](https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview) - Agent lifecycle governance including orphan detection

### Governed Environment Provisioning

For preventing orphaned environments through controlled provisioning with required approvals:

- [Environment Lifecycle Management](../../playbooks/advanced-implementations/environment-lifecycle-management/index.md) - Unapproved/rejected requests don't create orphaned environments; all environments have documented owners

---

*Updated: May 2026 | Version: v1.6.2 | UI Verification Status: Current*
