Skip to content

Control 1.2: Agent Registry and Integrated Apps Management

Control ID: 1.2
Pillar: Security
Regulatory Reference: FINRA Rule 4511, FINRA RN 24-09 + Rule 3110, SEC Rule 17a-4(b)(4) / 17a-4(g), SOX Sections 302 / 404, GLBA 501(b), NYDFS 23 NYCRR 500.07 / 500.16 / 500.17, OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12), Fed SR 26-2 (formerly SR 11-7), NIST AI RMF 1.0 GOVERN 1.4 / 1.6, FTC Safeguards Rule 16 CFR §314.4(c)
Last UI Verified: May 2026
Governance Levels: Baseline / Recommended / Regulated

Agent 365 Architecture Update

Documentation verified 2026-10-16; UI execution remains unverified since the historical date above. Current Microsoft guidance locates the registry at Agents > All Agents > Registry. The registry guide still labels the package API integration preview; the package reference documents a v1.0 route with Agent 365 licensing. Check each capability separately rather than labeling all Agent 365 administration preview. Reconcile directory, catalog, and environment evidence with Control 3.1.

Objective

Establish a governed registration and ownership model for AI agents, integrated apps, service principals, managed identities, and related non-human identities so the organization can trace who approved them, what permissions they hold, where they are published, and how they are supervised throughout their lifecycle.

Why This Matters for FSI

Regulation How this control supports it
FINRA Rule 4511 + SEC Rule 17a-4(b)(4) / 17a-4(g) A governed agent/app registry supports compliance with books-and-records obligations by preserving approval, ownership, consent,...
FINRA RN 24-09 / Rule 3110 As firms modernize workplace tooling and retain AI-generated business records, they should be able to identify the registered app...
SOX Sections 302 / 404 Finance-touching agents should have named ownership, controlled permissions, and documented approval evidence to support...
GLBA 501(b) + FTC Safeguards Rule 16 CFR §314.4(c) App inventory, least-privilege consent, and sponsor accountability help protect customer information and support periodic risk...
NYDFS 23 NYCRR 500.07 / 500.16 / 500.17 Controlled registration aids privilege management, incident investigation, and breach-response readiness for AI-connected...
OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12) + Fed SR 26-2 (formerly SR 11-7) + NIST AI RMF GOVERN 1.4 / 1.6 Higher-risk AI capabilities should be cataloged, attributable, reviewable, and subject to ongoing governance.
Regulatory mapping — click to expand
  • FINRA Rule 4511 + SEC Rule 17a-4(b)(4) / 17a-4(g): A governed agent/app registry supports compliance with books-and-records obligations by preserving approval, ownership, consent, and lifecycle evidence for AI-enabled business activity.
  • FINRA RN 24-09 / Rule 3110: As firms modernize workplace tooling and retain AI-generated business records, they should be able to identify the registered app or agent, its sponsor, and its approval trail.
  • SOX Sections 302 / 404: Finance-touching agents should have named ownership, controlled permissions, and documented approval evidence to support access-control attestations.
  • GLBA 501(b) + FTC Safeguards Rule 16 CFR §314.4(c): App inventory, least-privilege consent, and sponsor accountability help protect customer information and support periodic risk assessment.
  • NYDFS 23 NYCRR 500.07 / 500.16 / 500.17: Controlled registration aids privilege management, incident investigation, and breach-response readiness for AI-connected applications.
  • OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12) + Fed SR 26-2 (formerly SR 11-7) + NIST AI RMF GOVERN 1.4 / 1.6: Higher-risk AI capabilities should be cataloged, attributable, reviewable, and subject to ongoing governance.

Automation Available

Companion solutions in FSI-AgentGov-Solutions:

  • Agent 365 Lifecycle Governance — sponsor assignment, access reviews, inactivity handling, deactivation, and deletion holds for registered agents
  • Agent Intake — Preview. Pre-build intake workflow that captures the business case, classifies risk, and routes sponsor approval ahead of registration
  • Agent Registry Automation — automated discovery, registration, approval, and lifecycle governance of AI agents across Power Platform
  • Model Risk Management Automation — model inventory submission, risk scoring, and independent validation workflows for registered agents

License Requirements (verify before implementation)

  • Microsoft 365 / Microsoft 365 Copilot / Agent 365 — entitlements vary by agent-management feature; Microsoft 365 Copilot is not a blanket prerequisite for every admin surface. The package-management API specifically requires Agent 365. See agent-management licensing.
  • Microsoft Entra ID P1 / P2 / ID Governance — distinguish user Conditional Access, PIM, access reviews, and Lifecycle Workflows; do not assume one SKU covers every governance feature.
  • Microsoft Entra Workload ID Premium — required to create/modify traditional workload-identity Conditional Access policies and access risky-service-principal APIs. P1/P2 alone is not sufficient. Existing workload policies can continue functioning without the license. Managed identities and third-party/multitenant SaaS apps are outside this CA policy scope.
  • Defender for Cloud Apps — recommended for discovery of shadow / unsanctioned app activity and investigation support.
  • Purview Compliance / Audit — recommended for evidence retention, examiner-ready exports, and investigation support.
  • Graph permissions matrix — document the approved delegated / application permissions required for /applications, /servicePrincipals, audit access, and automation scripts.
  • Power Platform admin tier / Copilot Studio administrative access — required for environment-scoped registration, sharing, and publish governance.

Control Description

This control governs the agent identity and registration plane for AI agents and integrated applications. It is the foundational sister to Control 3.1 - Agent Inventory and Metadata Management, which handles the reporting and system-of-record inventory layer.

A governed deployment should be traceable across one or more of the following registration surfaces:

  1. Microsoft Entra Agent ID
  2. Integrated Apps in the Microsoft 365 admin center
  3. Power Platform Copilot Studio agent registration
  4. Microsoft Graph /applications and /servicePrincipals
  5. Microsoft 365 Copilot declarative agent manifest registration
  6. MCP server registration via Entra App Registration
  7. Agent management in the Microsoft 365 admin center (capability-specific licensing and release status)

Registration is not complete until the organization can identify the app or agent, its Agent Sponsor, Agent Owner, Backup Owner, approved business purpose, zone, permission set, and review cadence. Where Entra Agent ID is not used or cannot be collected, document the applicable identity anchor and collection gap. The Entra Agent ID v1.0 list API uses /servicePrincipals/microsoft.graph.agentIdentity, not /agents.

Key Configuration Points

  • Restrict user consent and enable an admin consent workflow for higher-risk or externally sourced apps.
  • Require publisher verification or document a compensating review when the publisher cannot be verified.
  • Assign a named Agent Owner for every registration and a Backup Owner for all Zone 2 / Zone 3 agents.
  • Minimize Graph and connector permission scopes; maintain a documented Graph permissions matrix for every approved high-privilege scope.
  • Apply Conditional Access for workload identities / service principals where supported, especially for Zone 3 or finance-touching agents.
  • Review service principal sign-in risk, anomalous token use, and credential changes on a documented cadence.
  • Prefer certificate-based authentication or managed identities over client secrets; if secrets are used, enforce rotation and expiry monitoring.
  • Establish an app registration approval workflow before production publishing or tenant-wide deployment.
  • Run a recurring ownerless-app / stale-owner remediation process and escalate unresolved exceptions to Control 3.6.
  • Maintain an Integrated Apps allow/block list aligned to approved publishers, zones, and business use cases.

Registration Surface Minimum Metadata

The registration plane for this control spans multiple Microsoft surfaces. Capture at least the following evidence for each one in use:

Surface Evidence to capture Minimum governance expectation
Microsoft Entra Agent ID Agent identity object ID, blueprint reference, sponsor, owner, backup owner, lifecycle state Preserve source identities separately from blueprint/app IDs
Integrated Apps in the Microsoft 365 admin center App/agent name, publisher, deployment scope, approval state Review org-wide versus scoped deployment and maintain allow/block decisions
Power Platform Copilot Studio Environment, agent name, owner, connectors/actions, sharing model Tie publication to managed environments and DLP posture
Microsoft Graph /applications App ID, owners, requested permissions, credential type and expiry Treat as the authoritative programmatic source for app-registration evidence
Microsoft Graph /servicePrincipals Enterprise app object ID, consent state, sign-in activity, CA/workload identity policy Use for runtime identity, audit, and ownerless-app review
M365 Copilot declarative agent manifest Manifest package/version, permissions requested, reviewer Retain the manifest or package hash with the approval record
MCP server via Entra App Registration Endpoint, auth mode, approved tools, sponsor, network boundary Treat MCP-connected tools as external integration risk and apply least privilege
Microsoft 365 admin center Agent Registry Package ID, publisher/lifecycle state, deployment scope, source/export metadata Reconcile catalog entries with Entra and Dataverse; duplicate-looking lifecycle rows can be expected

Sponsorship Integration

Every Zone 2 and Zone 3 registration should include a named Agent Sponsor, an operational Agent Owner, and a Backup Owner. Use the supplemental playbook Sponsorship Lifecycle Workflows to operationalize sponsor attestation, sponsor departure handling, and reassignment.

Implementation boundary (documentation review 2026-10-18): the supplemental playbook defines custom quarterly approval, reassignment, evidence, and containment requirements; it is not a deployable Lifecycle Workflows package. Native human sponsor leaver tasks, custom inventory fields, and source-specific agent mutations must be verified separately. The read-only collector does not implement these workflows or the human signature chain.

Agent 365 Unified Registry

Capability-specific availability

Verify current licensing, API support status, and the actual tenant surface. A documented v1.0 route does not by itself settle preview terms, and a successful catalog read does not prove discovery of every underlying identity or environment record.

Use Agent 365 data to cross-check what is visible in Entra app objects, service principals, Integrated Apps, and Copilot Studio. If a required source is unavailable or exposes only partial metadata, record Unknown / ManualEvidenceRequired and attach reviewed replacement evidence; do not treat a failed query as an empty compliant inventory.

Agent Store Governance

The Microsoft 365 Agent Store provides a curated catalog of agents available to users within the organization. FSI organizations should implement governance controls over the Agent Store to help limit discoverability to approved agents and to document any pilot or preview exceptions.

Agent Store Configuration

Portal Path: Microsoft 365 admin center > Agents > All Agents > Registry for agent records and actions. Use the current agent settings guidance for tenant-wide controls. The following table defines organizational policy targets, not a promise that each row is a native portal toggle.

Setting Zone 1 Zone 2 Zone 3 Description
Store visibility Enabled Enabled Restricted Control whether users can browse the Agent Store
Third-party agents Allowed with consent IT approval required Blocked or pre-approved only Control access to non-Microsoft agents
Custom agent publishing Self-service Approval required AI Governance Committee approval Control who can publish to the store
Agent ratings/reviews Enabled Enabled Moderated Allow user feedback on agents

Curation Workflow

Organizations should establish an Agent Store curation process:

flowchart TD
    A[Agent Submission] --> B{Zone Classification}
    B -->|Zone 1| C[Self-Service Publishing]
    B -->|Zone 2| D[IT Security Review]
    B -->|Zone 3| E[Full Governance Review]

    D --> F{Approved?}
    E --> G[Security Assessment]
    G --> H[Compliance Review]
    H --> I[AI Governance Committee]
    I --> F

    F -->|Yes| J[Add to Curated Catalog]
    F -->|No| K[Return with Feedback]

    J --> L[Monitor Usage & Feedback]
    L --> M{Periodic Review}
    M -->|Issues| N[Remove from Store]
    M -->|OK| L

📥 Download diagram: PNG | SVG

Curation Criteria

Criterion Zone 2 Threshold Zone 3 Threshold
Security scan Automated scan pass Automated + manual review
Data classification Internal or below Compliance-approved data sources only
Connector review Standard connectors Premium connectors require justification
Sponsor assignment Required Required + backup sponsor
Business justification Brief description Full business case with ROI
Testing evidence Functional testing Functional + UAT + security testing

Agent Store Visibility Controls

Control which agents appear in the store for different user groups:

Use documented registry/package availability and deployment actions for the intended audience, with separate change approval. The former Get-M365AgentStoreSettings / Set-M365AgentStoreVisibility names were illustrative pseudocode, not verified Microsoft cmdlets. The read-only collection in the PowerShell playbook does not configure store visibility or approvals.

Curated Catalog Categories

Organize approved agents into discoverable categories:

Category Description Governance Level
IT-Approved Agents reviewed and approved by IT security Zone 2+
Compliance-Verified Agents validated for regulatory requirements Zone 3
Department-Specific Agents curated for specific business units Zone 2+
Pilot/Preview Agents in evaluation phase with limited distribution Restricted
Deprecated Agents scheduled for retirement (visible but discouraged) All zones

Store Monitoring

Monitor Agent Store activity for governance insights:

Metric Alert Threshold Action
Unapproved agent requests >5/week Review demand; consider fast-track approval
Third-party agent installs Any (Zone 3) Immediate review
Low-rated agents <3 stars average Review for quality issues
Unused curated agents No usage in 90 days Consider removal
Shadow agent submissions Agents bypassing curation Enforce publishing controls

Agent 365 Registry: Agent Type Categories and Enhanced Visibility

The Agent 365 registry formalizes Microsoft's official taxonomy for agent types visible in the M365 admin center. The following categories are the authoritative classification scheme for the current Agent 365 experience and supersede any earlier informal categorization used in this framework.

Official Microsoft Agent Type Categories

Agent Type Description Registration Mechanism Governance Zone
Microsoft agents Built and maintained by Microsoft, such as Researcher, Analyst, and People agent Automatically registered with no admin action required Not individually governable through standard agent controls
External partner-built agents Agents built by trusted non-Microsoft developers and ISVs Appear in Integrated Apps and require admin approval to deploy Zone 2 minimum
Shared by creator Agents created and shared by individual users or developers inside the organization Self-service creation; appear in the registry upon sharing Zone 1 / Zone 2
Published by org Custom agents approved and published by the organization for broader organizational use Requires admin approval workflow Zone 2 / Zone 3

Researcher and Analyst governance exception

Microsoft 365 Copilot's Researcher and Analyst first-party agents are classified as Microsoft agents in the registry. They are first-party Microsoft experiences that inherit Microsoft 365 security, privacy, and compliance controls. They coexist with agents and abide by agent governance capabilities, but they do not fall under the standard agent-related settings used for custom or partner agents. Governance of these agents is handled through the Copilot control system. Document this exception in the agent inventory for examiner awareness. See Control 2.24 for the feature-governance exception and Control 2.25 for Researcher with Computer Use administration.

Shadow Agents: Updated Terminology

Terminology update - Microsoft now uses 'shadow agent' officially

The term shadow agent is now Microsoft's official terminology for unregistered agents that lack a Microsoft Entra Agent ID. Earlier versions of this framework described shadow agent as a framework-specific term; that note should be retired anywhere it still appears.

Shadow agents are agents discovered in the tenant inventory outside normal governed registration. Because they may lack a registered Entra identity, shadow agents can bypass identity-based governance controls including Conditional Access policies, Identity Protection monitoring, and lifecycle management workflows.

Shadow agents are surfaced in the Agent 365 registry with a distinct visual indicator. Administrators can take the following actions directly from the registry:

  • Quarantine: Block the shadow agent from accessing tenant identities and resources until it is reviewed and either registered or decommissioned
  • Investigate: Drill into discovered capabilities, data connections, and originating user
  • Register: Initiate an Entra Agent ID provisioning request to bring the agent into the governed identity framework

Agent Metadata: Data & Tools Tab

For custom agents, the following metadata is available in the admin center under Agents > All Agents > [Select Agent] > Data & tools:

Metadata Field Description Governance Use
Agent capabilities Declared functional capabilities of the agent Assess scope of agent permissions during review
Data sources OneDrive and SharePoint files or sites, plus Graph connectors accessed by the agent Data residency and sensitivity classification input
Custom actions External API connections and custom action definitions Third-party integration risk assessment

Note

The Data & tools tab is available for custom agents only. Microsoft first-party agents, including Researcher and Analyst, do not expose this metadata view in the admin center.

Agent Inventory Export for Compliance

The agent registry provides a direct export capability for compliance documentation and examination evidence.

Export Path:

M365 admin center
  > Agents
    > All Agents
      > Export

The export produces a structured file containing agent name, publisher, agent type, status, owner, and created date for all agents in the tenant inventory. This export is a primary examination evidence artifact for demonstrating agent inventory completeness. Capture and retain exports at minimum on the following cadence:

  • Monthly for Zone 1 agents
  • Weekly for Zone 2 agents
  • Daily for Zone 3 agents

Retain exports in the compliance document management system with appropriate version history.

Info

For analytics, trend reporting, and usage metrics built on registry data, see Control 3.13 - Agent 365 Admin Center Analytics and Reporting.

Zone-Specific Requirements

Zone cross-reference

Baseline = Zone 1 (Personal Productivity) · Recommended = Zone 2 (Team Collaboration) · Regulated = Zone 3 (Enterprise Managed). Zone requirements below correspond to the Governance Level in the control header.

Zone Requirement Rationale
Zone 1 (Personal) Capture, in the active registration plane, at minimum: agent/app name, creator or owner, registration surface used, business purpose, and last review date. External publisher use is recommended to be pre-approved or blocked by default. Lower-risk experimentation still needs attributable ownership and basic evidence.
Zone 2 (Team) Capture the Zone 1 set plus Agent Sponsor, Agent Owner, Backup Owner, environment/tenant, permission scopes, consent type, publisher-verification state, data classification, and approval ticket/reference for each registration plane in use. Review at least weekly. Shared agents increase blast radius and require repeatable approval evidence.
Zone 3 (Enterprise) Capture the full Zone 2 set plus appId / objectId / servicePrincipalId, auth mode (managed identity / certificate / secret), credential expiry, Conditional Access or compensating-control reference, sign-in audit evidence, DfCA discovery status, and sponsor attestation history. Review daily or via automation. Customer-, finance-, or regulator-facing agents require examiner-ready traceability and rapid investigation support.

Roles & Responsibilities

Role Responsibility
Entra Global Admin Used only for tenant-wide defaults, initial admin consent, or preview gates that lower-privilege roles cannot yet perform; time-box via Entra PIM and record justification.
Entra App Admin Manages app registrations, enterprise apps, service principal ownership, credentials, and permission review for agent-backed applications.
Entra Identity Governance Admin Configures access reviews, ownership attestation, lifecycle workflows, and ownerless-app remediation cadence.
Entra Agent ID Admin Manages Entra Agent ID registrations, sponsor assignment, and agent identity lifecycle where the feature is available.
AI Administrator Oversees Microsoft 365 Copilot / Agents / Integrated Apps governance surfaces and publication settings in the Microsoft 365 admin center.
Power Platform Admin Governs Copilot Studio environments, connector posture, agent sharing, and publish workflows.
Entra Security Admin Reviews risky or anomalous service principal sign-ins and supports Defender for Cloud Apps discovery and investigation workflows.
Purview Compliance Admin Supports evidence retention, audit readiness, and alignment with records-management requirements for regulated agents.
Agent Sponsor Approves business justification, attests continued need, and accepts accountability for the governed agent.
Agent Owner Maintains configuration, metadata accuracy, and evidence for the assigned registration.
Backup Owner Provides continuity when the primary owner is unavailable or departs.
Compliance Officer Reviews regulatory alignment, exception handling, and examination evidence.
Control Relationship
1.4 - Advanced Connector Policies (ACP) Connector governance constrains the external tools and actions available to registered agents and integrated apps.
1.7 - Comprehensive Audit Logging and Compliance Audit logs provide the evidence trail for app registration changes, consent, sign-ins, and owner updates.
1.10 - Communication Compliance Monitoring Shared and published agents may enter supervisory-review scope; the registry provides the accountable identity context.
1.19 - eDiscovery for Agent Interactions Registration metadata helps legal and compliance teams scope the correct app, owner, and content locations during investigations.
1.21 - Adversarial Input Logging Identity-aware registration improves attribution when prompts, tool calls, or attack attempts must be tied back to a specific governed agent.
1.23 - Step-Up Authentication for AI Agent Operations Sensitive admin actions on agents and app registrations should use stronger authentication and fresh session controls.
1.24 - Defender AI Security Posture Management (AI-SPM) Defender and DfCA discovery help identify shadow or risky agents that should be reconciled with the governed registry.
2.1 - Managed Environments Power Platform environment structure shapes where Copilot Studio registrations are allowed and how they are tiered.
2.5 - Testing, Validation, and Quality Assurance Agents and app integrations should be tested before publication or permission elevation.
3.1 - Agent Inventory and Metadata Management Sister control: 1.2 governs registration and identity; 3.1 governs the authoritative inventory and reporting layer.
3.6 - Orphaned Agent Detection and Remediation Detects ownerless or departed-owner agents/apps that should be remediated through this control's sponsorship workflow.
3.11 - Centralized Agent Inventory Enforcement Enforces registration as a prerequisite for broader production use and ongoing metadata completeness.

Implementation Playbooks

Step-by-Step Implementation

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

Verification Criteria

Confirm control effectiveness by verifying:

  1. Every Zone 2 and Zone 3 agent or integrated app has a documented AgentID or AppID/ObjectID, named Agent Owner, and Backup Owner.
  2. No production service principal, managed identity, or app-connected agent lacks a named Agent Sponsor and approval reference.
  3. High-privilege Graph, connector, or API permissions have a documented business justification and least-privilege review record.
  4. Admin consent settings are configured as intended, and risky or external app requests route through the documented approval workflow.
  5. Publisher verification is present for third-party apps where available, or a compensating exception record exists.
  6. Credentials are certificate-based or managed-identity-based where possible; any remaining client secrets have valid expiry dates and documented rotation evidence.
  7. Service principal sign-ins appear in Entra audit/sign-in logs and are reviewed on the required cadence for anomalous behavior.
  8. Conditional Access for workload identities or an equivalent compensating control is applied for supported Zone 3 / finance-touching agents.
  9. The Integrated Apps allow/block list matches the approved registry and no unresolved unapproved org-wide deployments remain.
  10. Defender for Cloud Apps or an equivalent discovery surface is reviewed for shadow / unsanctioned app activity, and unresolved findings are escalated.
  11. Sponsor attestation and ownerless-app remediation evidence is complete and reconciled with Control 3.1 and Control 3.6.
  12. Each required collection plane has a recorded outcome, expected scope, available time range, and positive-control evidence. Failed, unlicensed, unresolved, or incompletely paged collections are not control PASS results. CA verification uses SP object IDs, enabled policy state, exclusions and conditions, supported identity type, and evaluated sign-in evidence; zero observed sign-ins is not proof of 90-day dormancy.
  13. Evidence integrity checks verify both signed catalog authenticity and file contents after transfer. Hashing/signing alone does not configure immutable retention or implement the human attestation chain.

Additional Resources

May 2026 validation reminder

Microsoft continues to ship agent identity and admin-center changes quickly. Re-verify preview / GA status in your tenant before relying on a single portal as the only evidence source.

Updated: October 2026 | Version: v1.6.2 | UI Verification Status: Needs Review (documentation verified 2026-10-16; UI last verified May 2026)