Skip to content

Control 4.14: Copilot Studio Agent Lifecycle Governance

Control ID: 4.14 Pillar: Operations & Monitoring Regulatory Reference: FFIEC IT Handbook (Operations Booklet), FINRA Rule 3110 (supervisory systems and WSPs), OCC Bulletin 2023-17 (Third-Party Relationships: Risk Management), Sarbanes-Oxley §§302/404 (where applicable to ICFR), 12 CFR part 30, appendix D (OCC Heightened Standards) Last Verified: 2026-06-05 Governance Levels: Baseline / Recommended / Regulated

Objective

Establish end-to-end lifecycle governance for Copilot Studio agents — custom agents authored in Microsoft Copilot Studio — across approved development, test, and production environments and five operational stages: authoring, testing, publishing, versioning, and deprecation. This control defines the governance touchpoints, approval gates, solution-based transport pattern, deployment evidence artifacts, and deprecation procedures that wrap the day-to-day work of building and operating Copilot Studio agents in a financial services environment.

This control is the lifecycle wrapper that ties together adjacent controls:

  • Control 1.10 establishes the initial authoring approval gate (vendor risk, business case, data scope) that occurs before an agent enters this lifecycle.
  • Control 1.16 governs Copilot tuning (model fine-tuning), which is a separate decision domain from agent lifecycle and is referenced — not duplicated — here.
  • Control 4.13 governs extensibility components (connectors, plugins, Graph data sources) that may be embedded inside a Copilot Studio agent.
  • Control 4.14 (this control) wraps all of the above into the end-to-end agent lifecycle: authoring → testing → publishing → versioning → deprecation.

Why This Matters for FSI

Copilot Studio agents are configurable software components. Once published, they execute on behalf of users, can be invoked by other agents, and may persist for months or years. Without a defined lifecycle, organizations accumulate undocumented agent versions, lose track of who approved a publish, struggle to identify which agents are still in use, and cannot demonstrate to examiners how a given agent has changed over time.

This control helps cover:

  • FFIEC IT Handbook (Operations Booklet) expectations for change and configuration management of operational technology
  • FINRA Rule 3110 (supervisory systems and WSPs) for supervisory oversight of tools that touch member-firm business activities
  • OCC Bulletin 2023-17 lifecycle expectations for third-party and internally configured tools that depend on third-party platforms
  • Sarbanes-Oxley §§302/404 (where applicable to ICFR) evidence where Copilot Studio agents support financial reporting or related internal controls
  • 12 CFR part 30, appendix D (OCC Heightened Standards) governance maturity expectations for large banks operating material AI tooling lifecycles

Disclaimer

This control is provided for informational purposes only and does not constitute legal, regulatory, or compliance advice. See full disclaimer.

Control Description

Current Microsoft Copilot Studio ALM guidance treats an agent lifecycle as the path from initial idea and requirements through development, testing, deployment, ongoing maintenance, and decommissioning. For this control, those ALM concepts map to five governance stages. Implementation should use Power Platform solutions as the transport container for agent artifacts and customizations across environments, with environment variables and connection references handling environment-specific settings.

Five Lifecycle Stages

Stage Governance Touchpoint Primary Evidence Artifact
1. Authoring Author works inside an approved development environment after the Control 1.10 intake gate has cleared the use case, vendor scope, and data classification. Authoring should occur in the context of a tracked solution where feasible. Agent design record; development environment assignment; solution or component collection name; approved data sources
2. Testing The agent is promoted to a test environment through the agreed ALM path (Power Platform pipelines, GitHub Actions, Azure DevOps, or controlled solution import) before functional, prompt-injection, content safety, and connector-boundary testing. Solution import or pipeline run record; test plan, test results, sign-off from designated reviewer
3. Publishing A publishing approval workflow validates testing results, owner accountability, audience scope, and any embedded extensibility components governed under Control 4.13. Production deployment evidence should include the solution/pipeline record and any required post-deployment steps for items that are not solution-aware, such as sharing, channels, or manual authentication settings. Production deployment record; publishing approval record; published-agent register entry
4. Versioning Subsequent changes follow a documented versioning policy (recommended: semantic versioning) with solution or component collection versions and change-log entries tied to deployment stages and approvals. Version history; change log; per-version approval and deployment entries
5. Deprecation Agents reaching end of life follow a deprecation playbook with user notice, migration guidance, impact assessment, channel removal, and final evidence preservation. Deprecation notice; migration plan; final retirement record

How 4.14 Differs From Adjacent Controls

Concern Owning Control Why It Is Separate
Initial vendor / use-case approval before authoring begins 1.10 Vendor Risk Management Decision gate occurs before the agent exists; lifecycle starts after this gate clears
Copilot model tuning (fine-tuning) 1.16 Copilot Tuning Governance Tuning is model-layer governance, not agent lifecycle; tuned models may be referenced by an agent but are managed separately
Connector and plugin governance inside an agent 4.13 Extensibility Governance Extensibility is a per-component discipline that can apply across multiple agents; 4.14 references these components but does not re-govern them
End-to-end agent lifecycle (authoring → deprecation) 4.14 (this control) The lifecycle wrapper that sequences and evidences the stages above

Solution-Based ALM Transport Pattern

Power Platform solutions are the recommended transport container for promoting Copilot Studio agent artifacts across development, test, and production environments. This section provides specific guidance on solution-aware components, environment configuration, and deployment automation.

Solution-Aware vs. Non-Solution-Aware Items

Not all Copilot Studio configuration is carried within a solution. Understanding which items travel with the solution and which require post-deployment action is critical for repeatable deployments.

Category Solution-Aware (travels with export/import) Non-Solution-Aware (requires post-deployment action)
Agent definition Topics, trigger phrases, entities, variables, knowledge sources, system fallback —
Actions and connectors Power Automate cloud flows (when added to the solution), custom connectors Connection references must be updated per environment; some connectors require manual authentication configuration
Configuration Environment variable definitions Environment variable values must be set per environment; Azure Application Insights keys differ by environment
Channels — Deployed channels (Teams, web, custom), Direct Line/Web channel security settings, and sharing must be configured per environment
Authentication Authentication type selection Manual authentication settings (client IDs, token endpoints) must be configured per environment
Publishing — The agent must be republished in each target environment after solution import

Environment Variables and Connection References

Environment variables and connection references separate environment-specific settings from the agent definition, enabling the same solution package to deploy across environments without manual edits.

Environment variables: Define variables for settings that differ by environment (API endpoints, feature flags, Application Insights instrumentation keys, threshold values). Set variable values in the target environment before or during solution import.

Connection references: Define connection references for each connector the agent uses. During solution import, the importer maps each reference to an existing connection in the target environment. Document which connections and credentials are required in each environment so that deployment operators can prepare them before import.

Post-import checklist:

  1. Verify all environment variable values are set correctly in the target environment
  2. Verify all connection references are mapped to active, authenticated connections
  3. Set Azure Application Insights instrumentation key (not solution-aware)
  4. Configure manual authentication settings if applicable (client ID, token endpoint, scopes)
  5. Configure channel-specific settings (Teams manifest, web chat token endpoint, Direct Line secret)
  6. Configure sharing and audience scope for the target environment
  7. Publish the agent in the target environment
  8. Verify agent functionality through post-deployment testing

Deployment Automation Patterns

Automation Pattern Tool FSI Suitability Notes
Power Platform pipelines Built-in Power Platform feature High — portal-based, low code Supports solution export, import, and environment promotion with approval gates; audit trail built in
GitHub Actions for Power Platform GitHub Actions + Power Platform CLI High — fits developer-oriented teams Solution export/import via CLI; integrates with GitHub pull request reviews and branch protection rules
Azure DevOps pipelines Azure Pipelines + Power Platform Build Tools High — fits enterprises with existing Azure DevOps Solution pack/unpack, export, import; integrates with Azure DevOps work items and approval gates
Controlled manual import Purview portal + solution ZIP files Acceptable at Baseline Suitable for organizations with few agents; document the export/import steps and require operator sign-off

Regardless of the automation pattern chosen, each deployment should capture:

  • Source environment and solution version exported
  • Target environment and solution version imported
  • Deployment operator identity
  • Deployment result (success or failure with error details)
  • Post-deployment checklist completion status (all non-solution-aware items configured)
  • Approver identity (from the publishing approval workflow)

Git Source Control Integration

For organizations that use source control for Copilot Studio agents (via solution unpack or Copilot Studio's native source control integration):

  • Unpack/pack workflow: Export the solution as a ZIP, unpack to folder structure using the Power Platform CLI (pac solution unpack), commit to a Git repository, and use pac solution pack to rebuild the ZIP for import. This enables diff-based code review of agent changes.
  • Copilot Studio source control (preview): Copilot Studio supports native Git integration for agent components. When available, this provides a more granular view of topic, entity, and flow changes than solution-level unpack/pack.
  • Branch strategy: Use a branch-per-release or branch-per-environment strategy (for example, main for production, develop for the test environment) and require pull request reviews before merging agent changes.
  • Merge considerations: Copilot Studio components are serialized as XML or JSON within solutions. Merge conflicts may require resolution using Power Platform tooling rather than text-based merge. Document the merge procedure and train deployment operators.

Required Inventory Fields per Copilot Studio Agent

Field Purpose
Agent name and unique identifier Unambiguous reference across environments
Owner of record Accountable individual for lifecycle decisions
Author(s) Individuals who configured the agent
Lifecycle stage Authoring, Testing, Published, Versioning, Deprecated
Current version Tied to versioning policy
Source solution or component collection Transport container used for ALM promotion across environments
Environment path Development, test, and production environments used for the agent
Deployment automation reference Pipeline, GitHub Actions, Azure DevOps, or manual import record for the current production version
Approved data sources Including any extensibility components governed under Control 4.13
Audience scope Users or groups who can invoke the agent
Last publish date and approver Evidence of the publishing approval workflow
Last review date Periodic lifecycle attestation
Deprecation status and target retirement date (if applicable) Triggers migration and notice activities

Copilot Surface Coverage

Surface Lifecycle Governance Priority Notes
Microsoft Copilot Studio (authoring portal) Critical Primary authoring, testing, and publishing surface
Microsoft 365 Copilot Chat Critical Common runtime invocation surface for published Copilot Studio agents
Teams High Frequent embedding surface for Copilot Studio agents
Power Platform Inventory High Cross-environment lifecycle visibility for agents and dependencies
Microsoft 365 Admin Center (Agent 365 Registry) High Tenant-wide agent registry and ownership visibility
Microsoft Purview Audit Medium Source of evidence for publish, version, and retirement events

Governance Levels

Baseline

  • Maintain a current Copilot Studio agent inventory that lists every agent in the tenant, its owner, current lifecycle stage, current version, source solution, and environment path.
  • Maintain a published-agent register that records each agent currently published to a non-author audience, including the publish date, approver, and deployment reference.
  • Maintain a documented deprecation playbook that defines how a Copilot Studio agent is taken out of service, including who is notified, what is preserved, and how the agent is removed from the registry.
  • Confirm that authoring activity occurs only in environments approved through Control 1.10.
  • Confirm that any extensibility components used by an agent are governed under Control 4.13.
  • Review the agent inventory at least quarterly and remove or block agents lacking a clear owner.
  • Implement a testing approval gate before publishing with a documented test plan covering functional behavior, prompt-injection resistance, content safety, and connector-boundary checks.
  • Adopt a semantic versioning policy (for example, MAJOR.MINOR.PATCH) and tie each version increment to a change-log entry and approver.
  • Define a deprecation notice cadence (for example, advance notice 30 days before removal for material agents, with reminders at 14 and 7 days) and apply it consistently.
  • Operate a publishing approval workflow that requires testing evidence, owner sign-off, and an audience-scope decision before an agent moves from Testing to Published.
  • Reassess all published agents at least semi-annually against current data classification, audience scope, and embedded extensibility components.
  • Use Power Platform solutions as the default transport container for Copilot Studio agent artifacts, with environment variables and connection references for environment-specific settings.
  • Adopt deployment automation (Power Platform pipelines, GitHub Actions for Power Platform, or Azure DevOps) for test and production promotions and retain deployment run evidence.
  • Integrate Copilot Studio agent lifecycle changes into the firm's formal change management process under Control 4.12.
  • Treat AI model selection and version transitions as change-management events: record the primary AI model configured for each agent in the agent inventory; retest the agent under the defined testing workflow when the model changes and document the change in the version change log. Before enabling a model designated as cross-geo (including currently generally available Anthropic Claude and GPT-5 family models) in a production agent, complete a data-residency review under Control 2.7. Organizations should verify current model availability, release status, and data-processing geography at Select an agent model before enabling non-default models in production.

Regulated

  • Require independent reviewer sign-off (a reviewer who is not the author) on every production publish and every MAJOR version change.
  • Retain full version history for each agent in accordance with the firm's records retention policy, including configuration snapshots, test evidence, and approver identities, recommended to align with the FFIEC Operations Booklet expectations for change records.
  • Perform a deprecation impact assessment for every published agent being retired, with documented user migration guidance, identification of dependent agents or workflows, and an effective-date plan.
  • Conduct a quarterly lifecycle attestation in which agent owners confirm current state, audience scope, embedded components, and continued business justification.
  • Maintain examination-ready evidence packages tying each agent to the SOX §§302/404 (where applicable to ICFR) and 12 CFR part 30, appendix D (OCC Heightened Standards) governance expectations the agent supports.
  • Require production release evidence for material agents, including managed-solution import or pipeline run records and documentation of Copilot Studio post-deployment settings that are not solution-aware.
  • Monitor for unauthorized publishing attempts and ownerless agents through the M365 Admin Center Agent Registry and Power Platform Inventory; investigate exceptions weekly.

Setup & Configuration

Step 1: Establish the Copilot Studio Agent Inventory

  1. Identify all Copilot Studio environments authorized for agent authoring under Control 1.10.
  2. Export the current list of agents from each environment via Power Platform Inventory and the M365 Admin Center Agent Registry.
  3. Reconcile the two views and record each agent in a single governance inventory using the required fields listed above.

Step 2: Define the Five-Stage Lifecycle Workflow

  1. Document the entry criteria, evidence artifacts, and exit conditions for each of the five stages (authoring, testing, publishing, versioning, deprecation).
  2. Identify the approver role for each stage transition (for example, owner of record for authoring → testing; independent reviewer for publishing under the Regulated tier).
  3. Publish the lifecycle workflow to the agent author community and reference it from the firm's change management process.

Step 3: Establish the Environment and Solution Promotion Path

  1. Configure at least three environments for material agents: development, test, and production. Production should use a production-type Power Platform environment; development and test should use sandbox-type environments.
  2. Create a solution for each agent or release package, using a custom publisher and prefix. Use component collections when reusable topics, actions, knowledge, or entities need a separate release cadence.
  3. Define environment variables and connection references for settings, secrets, and credentials that differ by environment.
  4. Identify Copilot Studio items that require post-deployment action because they are not solution-aware, such as Azure Application Insights settings, manual authentication settings, Direct Line/Web channel security settings, deployed channels, and sharing.

Step 4: Select the ALM Automation Pattern

  1. Choose Power Platform pipelines, GitHub Actions for Power Platform, Azure DevOps, or a controlled manual solution import process based on the firm's maker, admin, and pro-development operating model.
  2. Require each promotion to capture the source environment, target environment, solution version, approver, deployment result, and post-deployment checklist status.
  3. Store deployment run links or solution import logs alongside the published-agent register and the formal change record under Control 4.12.

Step 5: Implement the Testing Approval Gate

  1. Promote the agent from development into a non-production test environment using the approved solution or pipeline path; avoid direct customization in test except for environment-specific configuration.
  2. Define the test plan template covering functional, prompt-injection, content safety, and connector-boundary tests.
  3. Require the test plan, signed test results, and test-environment deployment evidence as preconditions for the publishing approval workflow.

Step 6: Implement the Publishing Approval Workflow

  1. Configure an approval workflow (for example, in Power Automate, ServiceNow, or the firm's existing change tooling) that captures owner identity, audience scope, embedded extensibility components, testing evidence, and deployment reference.
  2. Under the Regulated tier, require an independent reviewer sign-off step before the workflow can complete.
  3. On approval, deploy the approved solution to production, complete required post-deployment settings, and record the publishing event in the published-agent register with date, approver, version, and deployment reference.

Step 7: Adopt and Enforce the Versioning Policy

  1. Adopt a semantic versioning convention (recommended: MAJOR.MINOR.PATCH) for each solution or component collection that transports agent artifacts.
  2. Require a change-log entry for every version increment, including the deployment stage and approval path used.
  3. Tie MAJOR version changes back through the publishing approval workflow; allow MINOR and PATCH changes through a lighter-weight authorized-change procedure as defined in change management.

Step 8: Operate the Deprecation Playbook

  1. Identify candidate agents for deprecation through quarterly inventory review (low usage, ownerless, superseded by another agent, or no longer aligned with the original business case).
  2. Issue deprecation notices per the defined cadence.
  3. Under the Regulated tier, complete the deprecation impact assessment, including dependent agents, workflows, and user migration guidance.
  4. Retire the agent on the effective date, remove deployed channels or sharing as appropriate, and preserve the final version snapshot, audit logs, deployment records, and retirement record per the firm's records retention policy.

Financial Sector Considerations

Material AI tooling under 12 CFR part 30, appendix D (OCC Heightened Standards): Large banks subject to the Heightened Standards should treat Copilot Studio agents that touch customer-facing, lending, advisory, or financial-reporting workflows as material AI tooling. Lifecycle governance for these agents should reflect the same maturity expectations applied to other material technology assets — independent review, documented change records, and periodic attestation.

Supervisory systems under FINRA Rule 3110 (supervisory systems and WSPs): Member firms should incorporate Copilot Studio agent publishing and versioning events into their written supervisory procedures where the agent supports a member-firm business activity. Supervisory oversight aids in confirming that the supervisory framework reflects the actual configuration of the agents in production.

Third-party dependency under OCC Bulletin 2023-17: Copilot Studio is a Microsoft-hosted platform; agents authored on it inherit a third-party dependency. Lifecycle records (publishing, versioning, deprecation) should be retained in the firm's own systems, not solely within the Copilot Studio platform, to support continued availability of evidence independent of the third party.

SOX §§302/404 (where applicable to ICFR): Where a Copilot Studio agent supports activities that affect internal controls over financial reporting, version history and approval records support the evidence trail expected for ICFR-relevant tooling. Organizations should verify with their SOX program owners which agents are in scope.

Records retention: Version snapshots, test evidence, publishing approvals, and deprecation records are recommended to be retained per the firm's broader records retention schedule. Organizations should verify retention periods with their records management function.

Avoid duplicating extensibility governance: When an agent embeds a connector or plugin, the connector or plugin is governed under Control 4.13. Lifecycle records under 4.14 should reference — not duplicate — the 4.13 component records to aid in single-source-of-truth integrity.

AI Model Version Governance: Copilot Studio allows authors to select the primary AI model for each agent at authoring time. The platform default model is periodically updated as new generally available models replace retired predecessors — for example, GPT-4o is retired in commercial cloud regions and GPT-4.1 is the current commercial default; agents depending on the default model may inherit new behavior without an explicit authoring change. Organizations should verify current model availability and release status at Select an agent model before publishing or reprovisioning agents. Model selection decisions and version transitions should be treated as change-management events subject to the testing and publishing approval workflow described in this control: document the model chosen for each agent, retest when the model changes, and record the transition in the change log. Generally available Anthropic Claude and GPT-5 family models are available as non-default options; many non-default models are designated as cross-geo, meaning data processed by these models may be routed outside the organization's provisioned geography. Before enabling a cross-geo model in a production agent, complete a data-residency review under Control 2.7; regulated-tier institutions should obtain documented risk acceptance. During lifecycle attestations, review the agent inventory for agents still configured with retired models.

Verification Criteria

# Lifecycle Stage Verification Step Expected Result
1 Inventory Review the consolidated Copilot Studio agent inventory Every agent has owner, lifecycle stage, version, source solution, environment path, deployment reference, and audience recorded
2 Authoring Confirm authoring environment provenance All authoring activity occurs in environments approved under Control 1.10, with tracked solution context where feasible
3 Testing Sample recently tested agents for promotion and testing evidence Test-environment deployment evidence, a documented test plan, and signed test results exist for each sampled agent
4 Publishing Sample the published-agent register Every entry includes publish date, approver, audience scope, version, and production deployment reference
5 Publishing (Regulated) Confirm independent reviewer sign-off Publishes and MAJOR version changes have a reviewer distinct from the author
6 Versioning Inspect solution versions and change logs Each version increment has a change-log entry consistent with the firm's semantic versioning policy and deployment path
7 Versioning Verify retention of version history Configuration snapshots, solution export/import or pipeline records, and approval records are retained per the records retention policy
8 Deprecation Confirm deprecation notice cadence Notices were issued in line with the documented cadence for retired agents
9 Deprecation (Regulated) Inspect deprecation impact assessments Each retired agent has a documented impact assessment and migration plan
10 Lifecycle attestation (Regulated) Confirm quarterly owner attestations All published agents have an attestation in the most recent quarter
11 Cross-control alignment Verify references to embedded components Agents that use connectors or plugins reference the corresponding Control 4.13 records
12 Anomaly review Review ownerless or unauthorized publish attempts Exceptions are investigated and documented per the defined cadence

Additional Resources