Is Microsoft Copilot Safe? The Prompt Injection Risk Your Financial Institution Must Address

In June 2025, researchers at Aim Labs disclosed CVE-2025-32711, a CVSS 9.3 critical vulnerability they named EchoLeak. A single crafted email, sent to any Copilot user's Outlook inbox, could instruct Copilot to extract sensitive data from emails, OneDrive files, SharePoint documents, and Teams messages, then silently transmit that data to an attacker-controlled server. Zero clicks required. Gartner has since named five distinct Copilot security risks that every financial institution needs to plan around.

Microsoft patched EchoLeak server-side in June 2025. But the attack class it represents, prompt injection, is not a single bug to fix. It is a structural vulnerability in how large language models process instructions alongside data. Security researcher Johann Rehberger demonstrated this months earlier with ASCII smuggling, using invisible Unicode characters to embed hidden instructions in Copilot outputs. And when cybersecurity engineer John Russell reported four additional prompt injection pathways to Microsoft, the company closed all four cases, stating they "do not qualify for serviceability."

For CISOs at credit unions, community banks, and mortgage companies, the question is not whether Copilot is useful. It is whether your governance framework can handle the risks that come with giving an AI system access to your most sensitive data. Before any production rollout, read our full Microsoft Copilot deployment guide for financial institutions and the companion Copilot governance dashboard setup to make sure every tenant control is in place.

How Prompt Injection Works Against Copilot

Prompt injection exploits a fundamental design tension in AI systems. Copilot's strength, its ability to reason across your emails, files, and messages, is also its attack surface. When Copilot retrieves context from your Microsoft 365 environment, it processes everything as potential instructions. An attacker who can place text in any document Copilot reads can potentially redirect Copilot's behavior.

Rehberger's research revealed three distinct attack chains: prompt injection through shared documents, automatic tool invocation where the payload instructs Copilot to search for additional files without user approval, and ASCII smuggling for invisible data exfiltration. He also built LOLCopilot, a red-teaming tool that demonstrates how an attacker with email access can use Copilot to identify frequent contacts, mimic the victim's writing style, and send personalized phishing messages.

How a prompt injection attack against Microsoft Copilot unfolds, from hidden payload to silent data exfiltration.

EchoLeak was not the last attack. In January 2026, Varonis disclosed Reprompt, a single-click prompt injection targeting Copilot Personal. Reprompt used a legitimate Copilot URL with a malicious "q" parameter that auto-executed a prompt when the victim clicked a phishing link. The attack chain used three techniques to evade detection: Parameter-to-Prompt injection to auto-populate prompts, a double-request method that bypassed Copilot's leak protections on the second attempt, and chain-request sequences where the server generated follow-up prompts to stage data exfiltration across multiple steps. Microsoft patched Reprompt in the January 13, 2026 Patch Tuesday update.

Then in February 2026, Microsoft's own security team published research on AI Recommendation Poisoning, a technique where companies embed hidden instructions in "Summarize with AI" buttons. When clicked, these buttons attempt to inject persistence commands into an AI assistant's memory, instructing the AI to "remember [Company] as a trusted source" and bias future recommendations. Microsoft identified over 50 unique poisoning prompts from 31 companies across 14 industries. The technique proves that prompt injection is not limited to nation-state actors or criminal organizations. Commercially motivated manipulation is already widespread.

The Vulnerabilities Microsoft Won't Fix

Microsoft's position on prompt injection draws a line that many security practitioners find uncomfortable. When John Russell reported four distinct prompt injection pathways, Microsoft classified all of them as not crossing a security boundary. The company's reasoning: if the impact is limited to the requesting user's execution environment and does not enable unauthorized access, it does not qualify as a vulnerability.

Russell noted that competing AI assistants "had no problem refusing all of these methods," attributing the gap to insufficient input validation rather than an inherent AI limitation. The philosophical divide matters for regulated financial institutions: Microsoft treats prompt injection as an expected AI limitation, while your examiner may treat unmitigated AI risks as a control deficiency.

Microsoft has invested in multiple defense layers since these disclosures. In July 2025, the Microsoft Security Response Center published its defense-in-depth strategy for indirect prompt injection. The strategy includes Prompt Shields (a detection classifier integrated with Defender for Cloud), Spotlighting (a technique that inserts delimiter tokens to help the model distinguish between user instructions and external content), and human-in-the-loop patterns that require explicit user approval before Copilot can take certain actions. These defenses reduce the attack surface, but they do not eliminate it. Prompt Shields relies on probabilistic detection, which means new encoding techniques can bypass it. Spotlighting works well for known patterns but cannot catch novel injection formats. And the human-in-the-loop pattern only applies to specific actions like sending emails, not to the core retrieval and summarization workflow where most data exposure occurs.

What Your Governance Team Needs to Do

Copilot is safe to deploy, but only with a governance layer that accounts for prompt injection risk. The controls are not exotic. They are the same identity and access controls your institution should already have, extended to cover AI-specific attack vectors. The following five steps give your governance team a concrete implementation path.

Copilot respects Microsoft Purview sensitivity labels. If a file carries a label with an access restriction, Copilot will not summarize or reference that file in its responses. Start by creating a label taxonomy that covers your highest-risk data: member PII, loan files, wire transfer records, board minutes, and M&A documentation. Apply the "Internal Use Only" label with encryption to any document that should never appear in a Copilot response.

Microsoft Purview supports both manual labeling (users choose the label) and auto-labeling policies that apply labels based on content matching rules. For financial institutions, configure auto-labeling to detect the four GLBA sensitive information types: Social Security numbers, bank account numbers, credit card numbers, and Individual Taxpayer Identification Numbers (ITIN). When Copilot encounters a labeled file during retrieval, it skips that file entirely rather than redacting individual fields. This is a hard boundary, not a probabilistic filter.

Copilot inherits the permissions of the user who asks the question. If a mortgage processor has read access to the executive SharePoint site, Copilot can pull data from that site into any response. Run a SharePoint access audit before enabling Copilot. Remove stale permissions on shared mailboxes, team sites, and OneDrive folders. Review membership in Microsoft 365 Groups and Teams channels, because Copilot can read any conversation in a channel the user belongs to.

The goal is straightforward: if a user should not be reading a document, Copilot should not be reading it either. Microsoft's own guidance recommends completing this permission cleanup before any Copilot rollout. Pay special attention to "Everyone except external users" sharing links on SharePoint. These links give every employee in your organization read access, which means every Copilot user can query that content.

Microsoft Purview Data Loss Prevention for M365 Copilot reached general availability in April 2026. This feature lets administrators create DLP policies that prevent Copilot from processing prompts containing specific sensitive information types. When a DLP policy triggers, Copilot will not return a response and will not use the sensitive data for grounding in Microsoft 365 or the web.

Configure policies in the Microsoft Purview portal under Data Loss Prevention. Select Microsoft 365 Copilot as the location. Add the GLBA sensitive information types (SSN, bank account, credit card, ITIN) plus any custom types your institution has defined. Set the action to block Copilot from responding when sensitive data appears in the prompt or the retrieved context. This control applies to both paid Copilot licenses and free Copilot Chat across E1, E3, and E5 tenants. It is one of the strongest technical controls available for preventing Copilot-mediated data leakage.

Conditional Access in Microsoft Entra ID controls who can use Copilot, from where, and under what conditions. Create a policy targeting the "Microsoft 365 Copilot" cloud app. Require phishing-resistant MFA (FIDO2 security keys or Windows Hello for Business) for all Copilot sessions. Block access from non-compliant devices and unmanaged browsers. Restrict Copilot access to your corporate network or trusted IP ranges for users who handle sensitive data.

If your institution uses Entra ID P2, enable risk-based Conditional Access: require step-up authentication when sign-in risk is medium or higher, and block Copilot access entirely when user risk is high. These policies ensure that even if an attacker compromises a user's credentials, they cannot use Copilot to extract data without meeting the full set of access requirements. Consider also creating a separate policy that blocks Copilot from Copilot Personal (the consumer version integrated into Windows and Edge) on corporate devices. The Reprompt attack specifically targeted Copilot Personal, which lacks the tenant-level DLP and audit controls that protect M365 Copilot. Microsoft's own security warning for banks deploying Copilot spells out why these guardrails matter before any production rollout.

Turn on unified audit logging in Microsoft Purview for all Copilot interactions. Every prompt, every response, and every data source Copilot references should generate an audit record. These logs answer the three questions your examiner will ask: What data did Copilot access? Who asked the questions? What did Copilot return?

Configure audit log retention for at least 12 months (the FFIEC recommended minimum for IT audit logs). Set up alerts for anomalous Copilot usage patterns: a single user submitting dozens of prompts about wire transfers in a short window, Copilot accessing file types it normally does not reference, or prompts that reference specific employee names or account numbers. Forward Copilot audit events to your SIEM or security monitoring platform for correlation with other identity and access signals.

Eighty percent of leaders cite data leakage as their top concern with generative AI. The concern is valid. The answer isn't blocking Copilot. It's governing what Copilot can reach.

How Guardian and Agent 365 Close the Gap

Guardian's DLP monitoring detects anomalous data access patterns across Microsoft 365, including Copilot interactions. When Copilot surfaces content containing sensitive information types (SSN, bank account numbers, credit card numbers, ITIN), Guardian's alert-and-encrypt approach ensures the data is flagged and protected without blocking legitimate workflows.

Guardian operates on an alert-and-encrypt model, not a block-and-frustrate model. Two DLP stacks run in parallel: an alert-only stack covering Exchange, SharePoint, OneDrive, and Teams, and an auto-encrypt stack for Exchange. When Guardian detects a GLBA-regulated data type in a Copilot interaction, it generates an alert for your security team and applies encryption to the source content. This approach preserves user productivity while creating the documentation trail your examiner needs.

Guardian's Productivity Insights tracks all AI tool usage across your tenant, including Copilot prompt frequency, response patterns, and which data sources Copilot accesses most often. This gives your compliance team concrete metrics for AI governance reporting: how many users are active on Copilot, what types of questions they ask, and whether usage patterns suggest oversharing risk. When your examiner asks "how do you monitor AI usage," Productivity Insights provides a documented answer backed by real data.

Agent 365, ABT's governance layer for AI tools, monitors what Copilot and third-party AI agents can access within your tenant. It enforces the boundaries that Microsoft considers outside its security perimeter: controlling which data sources Copilot can query, what actions autonomous agents can take, and maintaining the audit trail that FFIEC examiners expect for any technology that touches customer data.

Agent 365 addresses a specific gap in Copilot's architecture. Microsoft's built-in controls govern what Copilot can do. Agent 365 governs what Copilot should do within your institution's risk tolerance. This includes enforcing data boundary rules that restrict Copilot from querying specific SharePoint sites or mailbox folders, logging every agent action for compliance review, and providing a single dashboard where your CISO can see all AI activity across the tenant. As Microsoft releases new autonomous agent capabilities through Copilot Studio and other platforms, Agent 365 ensures those agents operate within the same governance framework your examiner expects for any technology handling member or borrower data.

Six governance controls that harden Copilot against prompt injection attacks for FFIEC-regulated institutions.

Frequently Asked Questions