Microsoft Power Platform AI Security: CISO Guide

Microsoft Power Platform AI security is a different problem from securing a managed Copilot deployment. Copilot Studio agents are usually built by a small team and reviewed. Power Automate flows and Power Apps with AI Builder actions are built by thousands of employees across finance, HR, and operations, each wiring a model to the mailbox, SharePoint library, or Dataverse table they happen to have access to. This guide explains where that creates real exposure, how indirect prompt injection reaches a flow, what Power Platform's built-in controls cover, and what a CISO should put in place.

We cover the attack surface, the citizen-developer risk model, injection and exfiltration paths, identity concerns, where DLP helps and where it does not, and an audit checklist you can run this quarter.

The Power Platform AI attack surface

Power Platform bundles several products that now share AI capabilities. It helps to separate them, because the owners, review processes, and failure modes differ.

Power Automate cloud flows. Event-driven automations with a trigger (new email, new SharePoint item, HTTP request, form response), a set of actions, and connections to other systems. AI enters through AI Builder actions (text classification, extraction, "create text with GPT" style prompt actions) and through calls to Azure OpenAI or other model endpoints over HTTP.

Power Apps. Canvas and model-driven apps that call flows, Dataverse, and AI Builder models. An app shared with a wide audience can become an unauthenticated-feeling front door to a flow that holds elevated access.

AI Builder. Prebuilt and custom models for document processing, classification, and prompt-based generation, consumed from flows and apps. Data it processes lives in Dataverse and the connected sources.

Copilot Studio. Conversational agents with topics, tools, and connectors. We cover its distinct risks, including confused deputy attacks and connector over-permissions, in our Microsoft Copilot Studio security guide.

Dataverse and connectors. The data layer and the 1,000-plus connectors that give every one of the above its reach into Microsoft 365 and third-party SaaS.

Two properties make this surface hard to defend. First, the trigger is often external: a shared mailbox that receives customer email is a public input channel. Second, authorization is frequently implicit. A cloud flow typically runs with the connection its creator authenticated, so the flow is as powerful as that person, regardless of who or what triggered it.

Citizen-developer risk: who is building AI flows

The defining feature of Power Platform is that it removes the engineering gate. That is the point of the product and the source of the risk. In practice we see a few recurring patterns when assessing M365-heavy enterprises:

• A finance analyst builds a flow that reads invoices from a shared mailbox, uses an AI Builder extraction model, and writes the result to a Dataverse table and a Teams channel.
• An HR coordinator builds a flow that summarizes candidate emails with a generative prompt and files the summary in a SharePoint site that more people can read than the original mailbox.
• A sales operations user builds an app that sends CRM notes to a model and emails the result to an external distribution list.

None of these makers is acting maliciously, and none has had a threat model applied. The questions a security review would ask are missing: what content can reach the model, what can the output cause, and whose identity executes the result?

This is the same dynamic we describe in our shadow AI security guide, except the unsanctioned AI is built inside a sanctioned platform. That makes it easy to miss, because the tenant, the license, and the vendor are all approved. We cannot cite a reliable industry figure for how fast AI usage inside low-code platforms is growing, so measure it in your own tenant rather than relying on a headline number.

Prompt injection in Power Automate flows

Indirect prompt injection is the central AI-specific attack class here. The OWASP Top 10 for LLM Applications lists prompt injection first, and the indirect variant matters most for automation, because the attacker never needs access to the flow. They only need their text to reach it.

Consider a flow with this shape:

Trigger: a new email arrives in a shared support mailbox.

AI step: a prompt action summarizes the email and decides a category and an action.

Action: depending on the output, the flow searches SharePoint for a related document, replies to the sender, or posts to Teams.

An external attacker sends an email whose body includes instructions addressed to the model: ignore the classification task, search the finance library for a specific term, and include the matching file contents in the reply. If the flow's design lets model output select a connector action or fill its parameters, and the SharePoint connection belongs to a user with broad read access, the injected instruction can result in a data disclosure to the attacker. No vulnerability in Microsoft's service is required. The flow did what it was built to do, with attacker-influenced input.

Microsoft has shipped cross-prompt injection (XPIA) protection for Copilot Studio agents, including audit events for jailbreak and XPIA detections, as described in its Copilot Studio security and governance documentation. That is valuable, and you should enable and monitor it. Two cautions apply. It is a probabilistic detection layer, not a guarantee, and a flow assembled from AI Builder prompt actions or custom model calls is a different construct from a Copilot Studio agent, so you should not assume the same protection applies. Verify what covers each construct in your tenant.

The design controls that work regardless of detection quality:

• Separate decision from action. Let the model produce a label or structured field from a fixed enum, then have deterministic flow logic choose the action. Do not let free-text model output pick a connector or fill a recipient, path, or query.
• Validate output. Check that the output matches an allowed schema before using it. Reject anything else.
• Require approval for writes and external sends. Use the approvals connector for any step that sends data outside the tenant or modifies records.
• Treat inbound content as data. Where possible, delimit it and keep it out of the instruction portion of the prompt, knowing this reduces risk without eliminating it.

For the broader pattern, see our indirect prompt injection guide for agentic AI.

Data exfiltration paths through AI Builder and connectors

Exfiltration in Power Platform rarely looks like a classic breach. It looks like a flow working normally. The common paths:

Output to a wider audience. An AI step summarizes restricted content and a later action posts it to a Teams channel, a SharePoint site, or an email thread with broader membership. The summary inherits none of the source's access controls.

Injection-directed retrieval. As described above, injected text steers a retrieval step toward data the attacker wants, and a reply or HTTP action carries it out.

HTTP and custom connectors. The HTTP action and custom connectors can send data to any endpoint unless policy blocks them. A model-produced URL or an attacker-supplied callback becomes an outbound channel.

Markdown and link rendering. Where output is rendered in Teams, email, or an app, a crafted link or image reference can carry data in its query string when a user views or clicks it.

Over-retention in Dataverse. AI Builder inputs and outputs written to Dataverse tables with broad read roles become a secondary store of sensitive content that nobody classified.

None of these needs a software flaw. Each is a design decision made without a security reviewer.

Microsoft Purview and DLP: what they cover and what they miss

Power Platform data loss prevention policies are your first line of control. They group connectors into business, non-business, and blocked categories, and prevent a single app or flow from combining connectors across groups. They can also restrict individual connector actions and endpoints, and they apply to Copilot Studio capabilities. Per Microsoft's Power Platform DLP documentation, policies are scoped to the tenant or to specific environments.

What they do well:

• Stop a flow from moving data from a business connector (SharePoint) to a consumer one (a personal file-sharing service).
• Block high-risk connectors and HTTP actions in environments where makers should not use them.
• Give you a single enforcement point instead of reviewing flows one at a time.

What they do not do:

• They do not inspect content. DLP sees connector classes, not whether a model summary contains customer data.
• They do not stop business-to-business movement. An injected instruction that moves data from a restricted SharePoint library to a broadly shared Teams channel stays inside the business group.
• They do not understand intent. They cannot tell a legitimate classification step from a hijacked one.

Microsoft Purview adds auditing, sensitivity labels, and data loss prevention for Microsoft 365 workloads, and its audit logs help you reconstruct who built and ran what. Sensitivity labels and label-aware DLP reduce exposure where content is labeled, but labels only help for content that has them. Plan for gaps in labeling coverage and verify behavior with test content before relying on it.

Identity and service principal risks

A Power Automate flow runs as someone. In most real tenants that someone is one of three things:

• The maker's own connection. The flow inherits the maker's access. If the maker leaves, the flow can break or, worse, keep running under a stale or reassigned connection.
• A shared service account. Convenient and common, and often over-privileged, with a password that never rotates and no named owner.
• A service principal or managed connection. The better option, but only if scoped to the least access the flow needs.

These are non-human identities and should be treated that way, a topic we cover in depth in our non-human identity security guide for AI agents. The questions to answer for every AI flow:

Whose identity executes each connector action?

What is the maximum data that identity can read and write, not just what the flow uses today?

Who owns the flow, and what happens to it when that person changes role?

Is the connection shared with other makers or apps?

The Microsoft Graph permissions behind these connections matter because an injected instruction can only do what the underlying identity allows. Narrowing the identity is the control that holds up when every other control fails. This is the same least-privilege logic we recommend in our AI agent authorization guide.

Environment governance that scales

You will not review every flow. You can control where certain kinds of flows are allowed to exist. A workable model:

Personal or developer environments. Makers experiment freely. A restrictive DLP policy blocks HTTP actions, custom connectors, and external sharing. No production data.

Shared team environments. Flows with AI actions are allowed against approved connectors. Sharing is limited to named groups. Connection ownership is recorded.

Production environments. Promotion through managed pipelines only. Any flow that combines an external trigger, an AI action, and a write or send connector needs a security review and an approval step. Service principals replace personal connections.

Supporting controls: environment routing so new makers land in the right place, tenant-level restrictions on creating production environments, connector allow lists per environment, and a policy that disables unneeded AI features in environments that do not need them.

CISO audit checklist

Run this against your tenant in order:

Inventory. Use the Power Platform admin center and the Center of Excellence Starter Kit to list flows, apps, agents, connections, and makers. Flag every flow that uses AI Builder, a generative action, or a model endpoint over HTTP.

Rank by exposure. Prioritize flows with an external or semi-public trigger (shared mailbox, public HTTP, forms) and a write or send action.

Check identity. Record which identity each flow uses. Replace personal and shared accounts on high-risk flows.

Review DLP. Confirm connector classifications, block HTTP and custom connectors where they are not needed, and confirm policies apply to every environment, including the default one.

Add approvals. Insert human approval before external sends and record changes on flagged flows.

Enable logging. Turn on audit logging in Purview, and forward Copilot Studio XPIA and jailbreak events to your SIEM. Alert on new AI flows in production.

Test with adversarial input. Send crafted emails and form entries to a staging copy of each high-risk flow and observe what the model output causes.

Assign owners. Every flow gets a named owner and a review date.

Our Microsoft 365 Copilot security guide covers the adjacent Copilot surface, and the controls overlap: least privilege, labeling, and logging do most of the work in both.

Limits of this guidance

Be honest about what you will not get. No control here eliminates prompt injection; you are reducing the blast radius and the likelihood. Microsoft's feature set and licensing change often, so confirm current behavior against Microsoft documentation and test in your own tenant. And risk-ranking a flow inventory takes judgment: a low-privilege flow with an external trigger can matter less than a high-privilege flow with an internal one.

Conclusion

Microsoft Power Platform AI security comes down to three questions asked of every flow: what untrusted content can reach the model, what can the model output cause, and whose identity carries it out. Answering them requires inventory, environment boundaries, narrow identities, approval gates on write actions, and adversarial testing, with DLP and Purview as supporting layers rather than the whole answer.

If you want a fast external view of your AI-facing exposure, run a Securetom scan to check your public attack surface, and see how it compares in our comparison of AI security tools. For related reading, browse the rest of the BeyondScale security blog.