Dynamics 365 Agentic AI Governance: A Full Policy Framework

Agentic AI is no longer a future capability inside Microsoft Dynamics 365 — it is live, it is being deployed, and in many organisations it is already making decisions on behalf of human workers. The Onboarding Agent, Sales Agent, and a growing catalogue of Copilot-powered automations in Copilot Studio are not simple chatbots. They retrieve data, trigger workflows, write records, and communicate with customers. That shift from assisted intelligence to autonomous action changes everything from a governance perspective.

Most guidance available today stops at strategy: "assess your AI readiness," "align to responsible AI principles," "review your data posture." Useful framing, but not enough to get internal sign-off from a risk committee or a board. What IT leaders and CTOs actually need is a mechanics-level policy framework — one that differentiates by agent type, maps controls to risk, and produces artefacts that satisfy legal, compliance, and executive scrutiny.

This post builds exactly that. It is structured around Dynamics 365 agentic AI governance as a discipline, not a checkbox — covering risk tiers, security controls, policy templates, and a board-ready risk register you can adapt today.

Why Agentic AI Demands a Different Governance Model

Traditional AI governance frameworks were designed for models that predict or recommend. Agentic AI does neither exclusively — it acts. An agent in Dynamics 365 can update a customer record in Dataverse, send a follow-up email through Power Automate, escalate a support ticket, or trigger a business process flow without a human reviewing each step.

This creates three categories of risk that your existing data governance policies almost certainly do not address:

• Scope creep risk: An agent configured for one process may access data or trigger actions outside its intended boundary.
• Hallucination risk: Copilot-generated summaries or agent-authored communications may contain factually incorrect content that reaches customers or enters audit trails.
• Accountability gap: When an agent takes an action, who is responsible — the agent builder, the platform owner, the business unit, or the vendor?

The governance framework below addresses all three through a tiered, controls-mapped approach.

The Three Tiers of Agentic AI Risk in Dynamics 365

Not all agents carry the same risk profile. Treating a Copilot summary the same as an autonomous Sales Agent that sends proposals to prospects is a category error. Your governance model must start by classifying agents into one of three tiers.

Tier 1 — Autonomous Action Agents (High Risk)

These agents take real-world actions with limited or no human review at the point of execution. In Dynamics 365, examples include:

• Sales Agent — qualifies leads, drafts outreach, updates opportunity stages
• Onboarding Agent — provisions accounts, assigns resources, sends welcome communications
• Custom Power Automate + Copilot Studio agents — business-specific workflows that write to Dataverse, trigger downstream systems, or interact with customers

Tier 1 agents require the most rigorous governance controls. Every autonomous action must be within a documented, approved scope. Human-in-the-loop (HITL) escalation must be defined for exceptions, and all actions must be logged to an immutable audit trail.

Tier 2 — Assisted Agents (Medium Risk)

These agents surface information or generate content that a human reviews before acting. Examples include:

• Copilot summaries in Dynamics 365 Sales, Service, and Field Service
• Email draft suggestions generated by Copilot in Customer Insights or Sales
• Meeting transcription and action item extraction via Copilot for Sales

Tier 2 agents carry medium risk because a human must approve output before it is acted upon. However, hallucination risk is significant — a confident, fluent, but incorrect summary can still influence decisions and enter the documentary record if copied without verification.

Tier 3 — Monitoring Agents (Lower Risk)

These agents observe, analyse, and alert without taking direct action or surfacing customer-facing content. Examples include:

• Anomaly detection agents that flag unusual patterns in Dataverse data
• Pipeline health monitors in Dynamics 365 Sales that surface risk signals to managers
• Compliance monitoring agents that scan records for policy violations and notify administrators

Tier 3 requires baseline controls — appropriate data access scoping, audit logging of alerts generated, and clear ownership — but does not require the same HITL or scope containment rigor as Tier 1.

Security and Compliance Controls Mapped by Tier

Once you have classified your agents, you can apply proportionate controls. The table below maps key governance mechanisms to each tier.

Data Loss Prevention (DLP) Policies

DLP policies in Power Platform govern which connectors an agent can use. For Tier 1 agents, apply restrictive DLP profiles that explicitly allowlist connectors — no general-purpose HTTP or third-party connectors unless individually approved and documented. For Tier 2, standard enterprise DLP profiles apply, blocking connectors to unapproved external services. Tier 3 monitoring agents should be restricted to read-only connector profiles where possible.

Document every connector allowlist exception in your agent scope register (see policy template below). DLP exceptions are a common audit finding — having them pre-documented demonstrates control, not exposure.

Dataverse Row-Level Security

Agentic AI inherits the security role of the service account or connection it runs under. This is a critical point that many deployments get wrong. If your Copilot Studio agent runs under a service account with system administrator privileges, it can read and write any record in your environment.

For all tiers, agents must run under dedicated service accounts with the minimum Dataverse security role required for their documented scope. For Tier 1, apply column-level security to restrict access to sensitive fields (e.g., financial data, personal data fields) even within accessible tables. For Tier 2 and 3, table-level and business unit scoping is generally sufficient.

// Example: Checking agent service account role in Power Platform Admin Center
// Navigate to: Environment > Settings > Users + Permissions > Application Users
// Verify each agent application user has ONLY the custom security roles listed
// in its Agent Scope Document — not System Administrator or System Customizer

// Recommended minimum role components for a Tier 1 Sales Agent:
// - Read: Lead, Contact, Account, Opportunity
// - Write: Opportunity (stage field only)
// - Append/Append To: Activity (for logging agent actions)
// - No delete privileges on any table

Audit Logging

Audit logging must be enabled at the Dataverse environment level for all environments running Tier 1 agents. Configure logging to capture create, update, delete, and access operations for all tables the agent touches. Retain logs for a minimum period defined in your data retention policy (typically 90 days minimum, 12 months for regulated industries).

For Tier 1 agents, supplement Dataverse audit logs with a dedicated agent action log — a custom Dataverse table that records every significant decision the agent made, the data it accessed, the action it took, and the timestamp. This is your primary evidence artefact if an agent action is challenged.

Human-in-the-Loop Escalation Paths

Every Tier 1 agent deployment must document its HITL escalation path before go-live. This means defining:

• Trigger conditions — what scenarios cause the agent to pause and request human review (e.g., deal value above threshold, new contact in a restricted country, data conflict detected)
• Escalation owner — the named role or team responsible for reviewing and approving the escalated action
• Response SLA — how long the agent waits before timing out, and what it does if no response is received
• Override audit — logging of every HITL decision, including who approved or rejected, and when

In Copilot Studio, HITL can be implemented using adaptive card approvals routed through Microsoft Teams or Power Automate approval flows. This is not optional for Tier 1 — it is a governance requirement.

AI Acceptable Use Policy: What to Include

Your organisation's existing acceptable use policy almost certainly does not cover agentic AI. You need a dedicated AI Acceptable Use Policy (AI AUP) or a formal addendum. At minimum, it must address the following sections:

1. Scope and Agent Classification

Define which systems, platforms, and agent types are covered. Reference the three tiers above and state that all agents deployed on Dynamics 365 and Power Platform must be classified and registered before deployment.

2. Agent Scope Document Requirement

Mandate that every agent has a documented scope covering: business purpose, data it accesses, actions it can take, actions it cannot take, the service account it runs under, the DLP profile applied, and the named business owner. No agent goes to production without a completed and approved scope document.

3. Hallucination Incident Procedure

Define a hallucination incident as any situation where an AI-generated output is identified as materially incorrect, and the output was acted upon or shared externally. The procedure must cover: incident logging (use your existing IT incident management tool), root cause classification (prompt design, model limitation, data quality), remediation steps (correct the record, notify affected parties if required), and policy review trigger (three incidents from the same agent within 90 days triggers a formal agent review).

4. Prohibited Uses

Explicitly state what agents may not do, even if technically possible: make final credit or hiring decisions without human review, access personal data outside their documented scope, communicate to customers in the name of a specific named employee, or operate in regulated workflows (e.g., financial advice, clinical triage) without additional compliance clearance.

5. Review and Renewal

All agent approvals expire after 12 months and require revalidation. Material changes to agent scope, data access, or connected systems require a new approval cycle regardless of the renewal date.

Board-Ready Risk Register Template

Getting executive sign-off on agentic AI deployments requires translating technical risk into business language. The following risk register structure is designed for CTO or CIO presentation to a board or risk committee. Each row in the register covers one deployed or planned agent.

• Agent Name and Tier: e.g., "Sales Outreach Agent — Tier 1"
• Business Capability Enabled: Plain-language description of what the agent does for the business
• Data Accessed: Tables, fields, and sensitivity classification
• Actions Authorised: Specific write/trigger actions permitted
• Inherent Risk Rating: High / Medium / Low before controls
• Controls Applied: DLP profile, security role, audit logging, HITL triggers
• Residual Risk Rating: Risk after controls
• Risk Owner: Named business executive accountable for this agent
• Last Review Date: When controls were last validated
• Next Review Date: Aligned to 12-month renewal cycle
• Open Issues: Any known gaps, pending approvals, or incidents

Present this register alongside your AI AUP and agent scope documents. Boards respond well to structured risk visibility — this format demonstrates that your organisation is governing AI with the same rigour applied to other enterprise technology risk.

Getting Started: A Practical Sequencing Guide

If you are building this governance framework from scratch, sequence your effort as follows:

• Week 1–2: Inventory all existing Copilot and agent deployments across your D365 environments. Classify each into Tier 1, 2, or 3.
• Week 3–4: Audit service account permissions for all Tier 1 agents. Remediate any over-privileged accounts immediately.
• Week 5–6: Draft your AI AUP using the structure above. Circulate for legal and HR review.
• Week 7–8: Complete agent scope documents for all Tier 1 agents. Validate HITL escalation paths are functional.
• Week 9–10: Populate the risk register. Schedule board or risk committee presentation.
• Ongoing: Monthly review of agent action logs, quarterly DLP policy review, annual agent revalidation cycle.

Conclusion: Governance Is What Makes Agentic AI Sustainable

Agentic AI in Dynamics 365 offers genuine competitive capability — faster sales cycles, more consistent customer onboarding, and operational leverage that was not possible two years ago. But capability without governance is liability. The organisations that will derive lasting value from these tools are not the ones who deploy fastest — they are the ones who deploy with a framework that can withstand scrutiny from auditors, regulators, and their own boards.

The framework outlined here — three risk tiers, proportionate controls, a structured AI AUP, and a board-ready risk register — gives your IT and executive teams the language and the artefacts to govern agentic AI as a serious enterprise discipline. It is not a blocker to innovation. It is the foundation that makes innovation defensible.

At CRMONCE, we work with organisations across India and globally to design and implement governance frameworks for Microsoft Dynamics 365 and Power Platform deployments. If you are planning an agentic AI rollout and need support building the policy infrastructure around it, get in touch with our team.

This post draws on Microsoft's published guidance for Copilot Studio governance, Power Platform DLP documentation, and Dataverse security model documentation. For the latest Microsoft guidance, refer to Microsoft Learn: Power Platform Governance Considerations.