Most IT teams that submit Copilot for compliance approval are solving a productivity problem. Most compliance teams that receive the request are staring at a regulatory problem they haven’t fully mapped yet. The two sides don’t always compare notes in time.
This isn’t an argument against using AI. It’s a walkthrough of what regulated institutions need to actually know about Microsoft 365 Copilot before the deployment form gets signed.
What Copilot accesses
Microsoft 365 Copilot is embedded in Word, Excel, Outlook, Teams, and SharePoint. When a user types a prompt, the system has read access to everything that user can reach inside Microsoft 365: email, files, calendars, meeting transcripts. Permissions flow from the user’s existing access rights, not from a separate AI-specific access control layer.
That’s where the compliance exposure starts. Access sprawl is a documented problem at most large organizations. Studies consistently show that a meaningful share of employees have overly broad file access: they could open those files, but shouldn’t. When Copilot inherits that permission model, every AI-assisted query runs against that existing access boundary, including the parts of it that were never intentional.
Microsoft’s Copilot Data Protection controls let administrators scope and restrict what the system can access. Those controls work when configured correctly. The risk comes from the gap between how Copilot gets deployed and how those controls actually get set up under real IT workload pressure with real timelines attached.
EchoLeak: what CVE-2025-32711 actually showed
In June 2025, researchers at Aim Security disclosed a zero-click prompt injection attack against Microsoft 365 Copilot, tracked as CVE-2025-32711 and named EchoLeak.
Here’s what it did. An attacker sent a single malicious email. The email contained hidden instructions for Copilot embedded in the message body. When a Copilot-enabled user received it, Copilot read the email as part of its normal operation. The hidden instructions then directed Copilot to retrieve and exfiltrate content from the user’s mailbox, SharePoint documents, OneDrive files, and Teams chat history. No user action required. The target didn’t click anything, open an attachment, or interact with the message in any meaningful way.
Microsoft patched EchoLeak server-side by May 2026. As of this writing there are no confirmed reports of exploitation in the wild.
The Aim Security researcher who found it was specific about what the patch didn’t change. The vulnerability class it represents, LLM scope violation via prompt injection, “likely affects other AI agent platforms” and reflects a systemic architectural risk rather than a one-time Microsoft bug.
The question for compliance teams isn’t whether EchoLeak is still exploitable. It’s what this class of attack means for your AI security documentation. When your AI assistant reads everything the user has access to and an attacker can send it instructions disguised as an email, the attack surface is structurally different from a search bar or a web portal. Patching one CVE doesn’t change that fundamental shape.
EchoLeak was a specific exploit. The broader category it belongs to, prompt injection against AI agents with broad data access permissions, is an active area of security research across all major AI platforms. The right documentation question for your information security team is what your AI security assessment needs to cover when an AI agent has read access to protected data, regardless of which vendor provides the agent.
FINRA’s technology-neutral framework, applied to Copilot
FINRA’s 2025 and 2026 Annual Regulatory Oversight Reports state the same thing: its rules “are intended to be technologically neutral” and “continue to apply when firms use GenAI or similar technologies, just as they apply when firms use any other technology or tool.”
That applies whether a firm builds its own AI or uses embedded features in third-party products. Copilot embedded in your firm’s Microsoft 365 environment is a third-party embedded feature. It’s covered.
What that means in practice: supervision obligations under Rule 3110, Regulation BI, recordkeeping, and communications requirements don’t have a carve-out for AI. FINRA Regulatory Notice 24-09 stated that AI “could implicate virtually every area of a member firm’s regulatory obligations.”
The specific employee behavior FINRA flags is one Copilot deployment creates by default. When analysts use Copilot to draft client communications or pull information from deal documents, sensitive firm and customer data enters the AI’s prompt and retrieval pipeline. That’s not a hypothetical misuse scenario. That’s the normal productivity use case the product is designed for.
FINRA also expects firms relying on AI supervisory tools to maintain written policies covering technology governance, data privacy, and model reliability. If your AI governance policy doesn’t document how Copilot is supervised, how its outputs are reviewed, and how you’re ensuring Reg BI-compliant communications when Copilot is involved in drafting them, that’s a gap. FINRA examiners are asking about it.
The GAO’s May 2025 report documented 17 OCC matters requiring attention related to AI use since fiscal year 2020, alongside 6 CFPB actions and 8 SEC AI enforcement actions. In April 2026, the OCC announced plans to issue a request for information on model risk management specifically addressing generative AI and agentic AI. The direction of travel is clear: enforcement on AI governance gaps is already happening, and the documentation standard is rising.
HIPAA and the limits of Microsoft’s BAA
Microsoft offers a Business Associate Agreement for Microsoft 365 services, Copilot included. A signed BAA means Microsoft accepts certain contractual obligations around protected health information. It doesn’t resolve what the HIPAA Security Rule actually requires from your organization.
The Security Rule requires covered entities and business associates to implement technical safeguards: access controls, audit controls, transmission security. When PHI can flow through a Copilot interaction because it’s sitting in an email or a SharePoint document the user can access, the questions are: who can retrieve that information through the AI, under what conditions, and what gets logged when they do?
Microsoft’s Copilot audit logs capture user queries and retrieved content through the Purview compliance portal. Whether those logs meet the specificity and retention requirements for your institution’s HIPAA posture is a determination your legal and compliance team has to make. It’s not a checkbox that comes with the BAA.
The December 2024 proposed HIPAA Security Rule update tightens access control and audit requirements. If it’s finalized as proposed, the evidentiary standard for “we had adequate controls around AI access to PHI” gets more demanding. Deploying Copilot at a health system before the compliance documentation is built is the problem. The BAA doesn’t substitute for that documentation.
ABA Formal Opinion 512 and what it means for Copilot at a law firm
ABA Formal Opinion 512, issued July 2024, is the ABA’s first formal ethics guidance on generative AI. It doesn’t create new rules. It applies five existing Model Rules to GenAI use in legal practice: competence (1.1), confidentiality (1.6), client communication (1.4), candor toward a tribunal (3.1, 3.3), and supervisory responsibility (5.1, 5.3).
On confidentiality: lawyers have an obligation to understand what happens to client information when it enters a GenAI tool, including what data the vendor retains and whether confidential client matter content is accessible to the AI system. In a firm using Microsoft 365, client matter documents stored in SharePoint or OneDrive may fall within Copilot’s access boundary. Understanding and documenting that is the lawyer’s ethical obligation under Opinion 512. It’s not something Microsoft can satisfy on the firm’s behalf.
On fees: when a firm bills clients for time using GenAI tools, the basis for that billing must be communicated before the engagement begins. This is existing Rule 1.5 applied to AI. Opinion 512 makes clear the obligation extends to how AI tool costs are handled and disclosed.
Opinion 512 doesn’t say don’t use AI. It says understand what you’re using and document the governance around it. For a firm deploying Copilot, that means written policies addressing how Copilot access to client files is governed, how engagement letters handle AI disclosure, and how the firm is confirming that confidential matter content isn’t inadvertently surfaced through AI queries across matters.
What a compliant architecture looks like
The compliance friction around Copilot in regulated industries isn’t a Microsoft-specific problem. It’s the natural result of deploying cloud AI with broad access permissions inside a regulatory environment that was built around the assumption that sensitive data stays inside your infrastructure.
On-premises private AI works from a different starting point. A private large language model deployed inside your network accesses what your infrastructure exposes to it, nothing more. There’s no internet path for a prompt injection attack to route exfiltrated data through. PHI doesn’t leave your environment, so there’s no BAA dependency and no vendor audit trail to evaluate for sufficiency. Supervision logs live in infrastructure you control and can produce for examiners directly.
The FINRA documentation requirements, HIPAA safeguard requirements, and ABA confidentiality obligations all become more straightforward to satisfy when the AI system sits inside your perimeter. The permission model is yours to define. The logs are yours to keep. The data doesn’t move.
This isn’t a claim that cloud AI is inappropriate for every regulated use case. Some use cases fit. The argument is that regulated institutions need to understand the compliance architecture they’re signing up for before they approve it, and on-premises AI carries a fundamentally different risk profile than cloud-deployed AI with broad access permissions.
Five questions to document before any AI approval
These apply to Copilot. They also apply to any AI tool a compliance team is reviewing for the first time.
What data does this system access, and under what permission model? Not what the sales materials describe. What the actual access controls permit at the moment of deployment, before any Copilot Data Protection configuration has been completed and before any access scoping has been applied.
What are the audit and logging capabilities, and do they meet our specific regulatory requirements? FINRA, HIPAA, and ABA Opinion 512 each have specific documentation expectations. Does the tool’s logging meet the specificity, retention period, and retrieval standards your examiners or auditors will ask about?
What’s the incident response plan if this AI system is involved in a data exposure? EchoLeak was patched. The next vulnerability won’t be known until after it’s found. What’s the playbook when the AI is the exposure vector, and who owns it?
Does your written AI governance policy document this tool specifically? FINRA expects written policies. HHS expects documented safeguards. The ABA expects lawyers to understand what their tools do with client data. A general AI use policy that doesn’t address Copilot specifically is probably not sufficient for your next exam cycle.
What are the vendor’s training data and model usage policies, and when did you last review them? Most enterprise Microsoft agreements default to favorable terms for the customer on data usage. Most, not all, and those defaults can shift at contract renewal. Verifying what applies to your specific agreement is a one-time task. Not checking is how gaps appear.
If all five have documented answers in your compliance file, you’re ahead of most institutions your examiners will visit this cycle. If they don’t, that’s the work to complete before the deployment form goes through.
See What Private AI Looks Like for Your Institution
Cognetryx deploys inside your environment. Your data stays inside your network. No BAA dependency. No cloud access boundary to manage. No path for a prompt injection attack to exfiltrate data through an AI agent.
Request a Demo →