Imagine a professional organization that uses Dynamics 365 to manage applications, casework, and correspondence. A case worker needs to see one record. A manager needs broader oversight. An integration needs a narrow set of updates. An AI agent might one day summarize a case or propose the next action.
The first question is familiar: Who has access? The more revealing questions are: Through which application? To which fields and records? Can the data be exported? What can an agent change? And can we prove what happened afterward?
IdentityDataApp or toolAction or exportEvidence
Paul Liew’s Microsoft Power Platform post, “Strengthen Data Protection in Dataverse”, is a useful prompt for asking those questions together. It highlights secured column masking, app access control, role-based system views, and filtered-view security for particular scenarios. Each addresses a different part of the problem. None substitutes for a complete assessment.
Four controls, four different questions
1. Column security and masking: What should this person see?
Identify sensitive columns first: government identifiers, financial details, and protected case information. Then examine which roles can read the underlying value, what a masked reader sees, and what happens through exports and integrations. Test with real role personas, including a user who should be denied access.
Masking reduces exposure when configured for the right columns and paths. The assessment still needs to verify downstream copies, integrations, and the users who are allowed to reveal an unmasked value.
2. App access control: Which clients can connect?
A user may have appropriate table permissions and still connect through a client the organization did not intend to allow. Inventory actual app IDs in audit mode, decide which are approved, and test enforcement only after legitimate dependencies are understood.
This control addresses an application entry point. Connector data policies, Dataverse authorization, and monitoring are still required for other data movement paths.
3. Role-based system views: Which lists appear in the interface?
Tailoring public views to security roles can improve relevance and reduce incidental exposure in the user experience. View visibility is not a data authorization boundary. A hidden view does not revoke table, row, or column access through another route. Treat the feature as interface governance and validate the underlying Dataverse privileges separately.
4. Filtered-view security: Which records match a permitted condition?
Microsoft’s post describes predicate-based row access for C2 system-user scenarios, including Power Pages. That is valuable where ownership-based access is a poor fit. It should not be assumed to replace business units, teams, and ownership across every Dynamics 365 workload. Check support and scope for the specific architecture before placing it in a remediation plan.
What changes when an agent joins the workflow?
An agent is another actor with a purpose, an identity, permissions, tools, and a lifecycle. If it can read a case file, summarize it, call an external service, and update a status, its effective reach depends on the whole chain—not just its prompt.
In a later post, Liew describes Microsoft Entra Agent ID and Dataverse agent users. The model gives an agent a distinct identity and a dedicated Dataverse security principal to which least-privilege roles can be assigned. As of September 2026, this is a public preview. Availability and production suitability must be verified against current Microsoft documentation for each deployment.
That suggests five assessment questions:
- Identity: Does the agent have a distinct, owned identity, or does it operate through a shared user or broad application account?
- Authorization: Which tables, rows, columns, and operations are strictly required for its task? Have allowed and denied actions been tested?
- Tools and destinations: What connectors, APIs, actions, and external endpoints can it invoke? Where can retrieved or generated data go?
- Human oversight: Which actions may execute autonomously, and which require review, approval, or a reversible workflow?
- Evidence: Can administrators attribute a material read or change to the agent, review the outcome, and retire its access when the use case ends?
Dataverse’s AI-assisted auditing enhancements strengthen attribution for certain agent-driven data changes. The assessment still has to inspect the actual audit configuration, event coverage, retention, access to logs, and gaps across tools outside Dataverse. “Auditing is enabled” is a starting statement, not evidence that every relevant action is captured.
A practical assessment output
For each important data journey—human casework, integration, and agent-assisted work—I would produce a concise evidence trail.
| Assessment question | Evidence to collect | Possible finding |
|---|---|---|
| Who can access the data? | Role assignments, team membership, table, row, and column tests | Broader access than the task requires |
| How can it leave? | Approved apps, exports, connectors, and destination inventory | Unreviewed client or outbound path |
| What can an agent do? | Agent identity, role, tool list, and allowed and denied test results | Shared identity or excessive write permission |
| Can we reconstruct an event? | Audit settings, sample events, retention, and review process | Changes cannot be reliably attributed |
The deliverable is more than a list of settings. It is a prioritized set of findings with business impact, reproducible evidence, a control owner, and a remediation sequence. Start with high-consequence access and data movement paths; verify the fix through a negative test; then record the operating process that will keep the control effective.
Turn project evidence into a repeatable offering
There is a larger consulting opportunity here. A strong engagement can become a reusable Dynamics 365 and Power Platform security assessment method when the team captures five assets consistently:
- a control catalogue that maps risks to Microsoft platform capabilities;
- an evidence request list and a repeatable test procedure;
- a finding model with severity, business impact, and affected data paths;
- a remediation roadmap with control owners and sequencing; and
- a retest method that proves both permitted and denied behavior.
An agent layer then extends the same method with agent identity, tool permissions, external destinations, human checkpoints, and lifecycle ownership. This makes AI security a measurable part of the platform assessment rather than a separate set of general principles.
The architectural takeaway
The most useful security assessment traces the path from identity → data access → application or tool → action or export → audit evidence. That same path can be reused when the next actor is an AI agent. It gives security teams a concrete basis for approving a bounded use case and gives architects a way to show exactly where an assumption fails.
The opportunity in the current Dataverse security roadmap is to translate new platform controls into repeatable assessment questions while being precise about what each control does, where it applies, and what remains to be tested.
Microsoft references
- Paul Liew, Strengthen Data Protection in Dataverse (August 2025).
- Paul Liew, Secured and Governed your AI Agents: Microsoft Entra Agent ID for Dataverse (August 2026; public preview).
- Paul Liew, Dataverse Auditing: Enhancing Trust and Transparency in the Age of AI (September 2025).
Independent architecture note. This article discusses a reusable assessment approach and does not describe a client engagement. Views are my own.