3.2 Security and Governance Considerations

Responsible AI answers “should this agent behave ethically?” Security and governance answer “who can build, what can connect, where does data live, and how do we prove control?” On AB-620, evaluate security and governance considerations means matching business risk to Power Platform and Copilot Studio controls—not inventing custom security products for every scenario.

The governance stack in plain language

Think in layers:

1. Tenant and admin policy — Power Platform admin center data policies, tenant settings, publishing limits for generative AI agents.
2. Environment boundary — which environment hosts the agent, which connectors are allowed there, who has maker rights.
3. Agent configuration — authentication mode, knowledge sources, tools, channels, Application Insights.
4. Runtime protection — platform threat detection, optional external security providers, protection status on published agents.
5. Monitor and respond — Purview audit logs, Sentinel integrations, conversation transcripts, maker security warnings.

Exam questions often mix layers. For example, “prevent unauthenticated public chatbots” is primarily a DLP / data policy on the connector Chat without Microsoft Entra ID authentication in Copilot Studio, not a topic-level message rewrite.

Data loss prevention (DLP) / data policies

Data policies in the Power Platform admin center govern how agents connect and interact with data and services. Administrators classify connectors into groups:

Critical rules for planning:

• Connectors in different groups cannot freely share data with each other under a policy that enforces separation—design agent tools so required connectors land in compatible groups.
• Many newer Copilot Studio connectors default into Non-business if not explicitly classified; organizations that auto-block Non-business will break makers until admins reclassify needed connectors.
• DLP enforcement for Copilot Studio is active; per-agent exemptions that once existed are not a reliable planning assumption—design as if policy always applies.
• Enforcement is effectively real time: makers and users see errors when a policy is violated.

Common Copilot Studio DLP use cases

Endpoint filtering is the nuanced alternative to all-or-nothing blocks: allow only https://contoso.sharepoint.com/* for SharePoint knowledge or only approved API hosts for HTTP nodes. On the exam, if the business needs a few trusted endpoints but not the open internet, prefer endpoint filtering over blocking the entire capability.

Scenario — Contoso finance agent. Finance wants an agent that reads from Dataverse and posts to an internal ERP API, but must never chat anonymously or call arbitrary HTTP hosts. Governance plan: environment with finance makers only; DLP blocks unauthenticated chat; HTTP connector limited via endpoint filtering to the ERP host; ERP and Dataverse connectors classified as Business; public website knowledge blocked.

Environments, environment groups, and routing

Environments isolate apps, flows, agents, and data. A mature plan separates at least:

• Development — experimentation, broad connectors maybe, synthetic data.
• Test / UAT — production-like DLP, integration testing, evaluation runs.
• Production — strict DLP, limited makers, change via ALM pipelines.

Environment groups (and related admin features such as rules and routing) help apply consistent governance to many environments—for example, all departmental sandbox environments inherit the same DLP baseline while production uses a tighter policy. Environment routing can send new makers into a safe default environment instead of an uncontrolled personal space, often paired with a maker welcome message that states privacy and compliance expectations.

Planning tip: do not build production customer agents in the default environment if your organization treats that environment as a playground. AB-620 scenarios that mention “makers accidentally published sensitive bots” usually want stronger environment strategy plus DLP, not only training.

Authentication and identity at the governance layer

New agents often default toward Authenticate with Microsoft (Microsoft Entra ID) so chat works in Microsoft 365 surfaces with organizational identity. Makers can choose No authentication or manual authentication patterns for broader channels. Governance should decide:

• When no authentication is ever acceptable (rarely for anything with internal knowledge or write actions).
• When manual Entra ID (including certificate-based configuration options) is required for custom websites.
• Whether tools run as the user (delegated permissions, least privilege, better audit trail) or as a fixed connection identity (simpler but higher blast radius).

Blocking unauthenticated chat via DLP is the admin backstop when makers would otherwise publish open agents.

Tenant isolation, data residency, and encryption

Tenant isolation means your agent’s Dataverse data, connections, and admin boundaries stay within your Microsoft tenant’s control plane. Cross-tenant sharing should be explicit and rare. For multi-agent designs that call external agents (for example via A2A patterns), assume you lose direct control of the other party’s security posture—plan contracts, scopes, and data minimization accordingly.

Geographic data residency and controls to restrict generative AI data movement outside allowed regions matter for regulated industries. If a scenario stresses EU or industry residency, prefer configurations that keep processing and storage in approved geographies and avoid unconstrained cross-geo generative features.

Customer-managed keys (CMK) allow organizations to encrypt Copilot Studio environment content with keys they control—relevant when exam scenarios emphasize encryption ownership, key rotation, or revoking access. Pair CMK conversations with operational readiness (Key Vault processes), not CMK alone as a substitute for DLP.

Admin controls, audit, and runtime protection

Additional controls you should be able to name:

Connector policies and least privilege

Treat every connector as a potential exfiltration path. Planning steps:

1. Inventory tools and knowledge connectors the agent truly needs.
2. Classify them under DLP; block the rest in that environment.
3. Prefer user-delegated auth for read of personal or departmental data.
4. Use custom connectors or API management fronts for internal APIs with their own authZ.
5. Review connector dependency insights before production so admins see data movement risk.

Governance anti-patterns

• One flat production environment for all makers with Non-business connectors allowed by default.
• Relying on “we told makers not to use no-auth” without blocking the connector in policy.
• Mixing Business ERP connectors and consumer social connectors in ways policy forbids, then granting exemptions casually.
• Publishing external channel agents with internal SharePoint knowledge and no auth.
• Ignoring that blocking a Power Platform connector can also break MCP tools that depend on it.

Exam-focused decision guide

Security and governance succeed when policy, environment design, and agent configuration tell the same story. For AB-620, describe layered controls: DLP for capability boundaries, environments for blast radius, authentication for identity, channels for exposure surface, residency and encryption for data protection, and audit for accountability.