The Morgan Stanley Leak Wasn't a Hack. That's the Problem.

An information-handling incident at Morgan Stanley, reported this week, illustrates a persistent weakness in enterprise security: an authorized employee sending sensitive information through an authorized application to the wrong audience.

There was no malware involved, no compromised credential and apparently no external attacker.

According to a September 23 Bloomberg report, a Morgan Stanley banker mistakenly emailed an internal document containing details of more than 100 investment-banking deals the firm was pitching or monitoring, primarily in Asia. The list included prospective IPOs in China, South Korea and India, information about private equity and pension-fund involvement, and projects that had been put on hold. The internal version was reportedly sent to some clients when the banker had intended to send a client-facing version. He subsequently attempted to retract the message.¹

A blurred copy later appeared on Instagram, according to Bloomberg. Morgan Stanley said it had taken steps to address the inadvertent disclosure and was engaging with relevant parties.¹

The episode is a useful example of why organizations need to think about data protection differently. Authentication and access control answer the question of whether someone is entitled to see information. They do not necessarily control what an authorized person can do with it once it is open on a screen.

Access Control Is Not Data Control

The Morgan Stanley employee apparently had legitimate access to the deal information. The email system was legitimate. Sending information to clients was presumably part of the job. The failure occurred because the wrong version of a legitimate document was attached to an otherwise ordinary business communication.

The same issue occurs in other regulated environments. A defense contractor may correctly restrict CUI to authorized employees but still need to address whether those employees can download the information, attach it to ordinary email, copy it to removable media or upload it through a browser. A healthcare organization can properly provision access to PHI while leaving open several routes through which an authorized user can inadvertently disclose it.

In my CMMC work, this is one of the things I test early: not simply who can access the CUI, but what an authorized user can do with it after access is granted. A security boundary that controls entry but not egress is incomplete.

What DLP Could Do in This Scenario

For Microsoft 365 environments, the relevant controls are primarily Microsoft Purview Information Protection, Purview DLP and Endpoint DLP. The starting point is classification.

A document containing an investment bank's active deal pipeline should not be treated the same way as a generic market update. An organization might classify the former as Highly Confidential - M&A, or an equivalent internal category, and associate that classification with specific handling requirements.

Microsoft Purview DLP can use sensitivity labels as policy conditions across Exchange email and attachments, SharePoint, OneDrive and managed devices, although Microsoft documents limits on label detection in SharePoint and OneDrive.²

A rule could detect a highly confidential attachment addressed to an external recipient and block the message, require justification or restrict delivery to specifically approved domains. But the Morgan Stanley incident shows why a simple 'block external email' policy is not enough. The recipients were reportedly legitimate clients; the problem was that they received the internal version rather than the client-approved version.

The better control therefore needs to distinguish between material approved for external distribution and internal information that should never leave the organization. That is a classification problem as much as an email-security problem.

Recall Is Not a Security Control

The reported attempt to retract the Morgan Stanley message is also worth examining. Microsoft's cloud-based Message Recall only operates within the sender's organization. Microsoft states that messages cannot be recalled across organizations or over the internet.³

Once an ordinary email containing an unprotected attachment has reached an external client's mail system, standard Outlook recall is therefore not a reliable recovery mechanism. Asking the recipient to delete the document is incident response, not information protection.

Microsoft provides a different capability for some highly sensitive external communications through Purview Advanced Message Encryption. When external recipients receive protected content through the encrypted-message portal, administrators or senders can revoke access under defined conditions.⁴

There are important limitations. Revocation is not universal and depends on the recipient receiving a link-based, branded encrypted message rather than a native inline experience. Organizations that need reliable post-send revocation have to design and configure the portal-based experience accordingly.⁴

Classification, Encryption and DLP Need to Work Together

DLP should not be treated as a single mail-flow rule. For high-value information, several controls can operate together: a sensitivity label identifies the document as restricted; encryption limits who can open it; Exchange DLP evaluates whether the recipient and destination are appropriate; and Endpoint DLP addresses alternate routes such as removable media, browser uploads, printing and clipboard operations.

Automated classification is also important because users cannot be expected to label every document correctly. Microsoft Purview supports multiple detection approaches, including sensitive information types, Exact Data Match, document fingerprinting and trainable classifiers.⁵

The classification model should reflect the information the organization actually handles. For a financial institution, that may include transaction pipelines, customer data, research, board material and nonpublic financial information. For a defense contractor it may be CUI, technical drawings and export-controlled data. For healthcare organizations it may be PHI and clinical information.

The Endpoint Is Part of the Boundary

Email is only one egress path. An authorized user with access to a sensitive document may also be able to upload it to personal cloud storage, copy it to USB, print it, transfer it to another application or paste portions into a website.

Microsoft Endpoint DLP can audit, block or allow-with-override activities including copying protected information to removable media or network shares, printing, copying to the clipboard, using restricted applications and uploading sensitive files to restricted cloud-service domains.⁶

This has become more important as enterprise computing has moved toward SaaS and browser-based applications. The old concept of protecting information primarily by keeping it 'inside the network' has limited value when legitimate users spend much of their day moving among Microsoft 365, SaaS platforms, browsers and external collaboration environments. The more useful security question is whether the data is moving into an approved context.

AI Makes the Same Problem More Visible

Generative AI has added another egress path, but it has not fundamentally changed the problem. An employee can take a financial forecast, engineering specification, contract provision, customer record or block of source code and paste it into an AI service in seconds. To the employee, the activity may look like editing or research. To the security program, it may represent a transfer of restricted information to an unauthorized service.

Microsoft's Endpoint DLP capabilities include controls for browser uploads and pasting sensitive text into supported browsers, allowing organizations to apply the same information-protection concepts to web and AI services.⁶

This is why AI governance increasingly intersects with DLP. Organizations should determine which AI services employees are permitted to use, but application policy alone is insufficient. They also need controls around what information those users are permitted to submit.

DLP Is Mostly a Policy-Engineering Exercise

The technology is not the hardest part. A DLP program requires an organization to identify its important information, understand how that information legitimately moves through the business, and define the conditions under which movement should be permitted, challenged or blocked.

Overly broad rules generate false positives and eventually get disabled. Weak rules create the appearance of control without materially changing risk. The useful middle ground requires security teams to understand actual business workflows.

The Morgan Stanley incident is a good example. 'Block confidential documents from being emailed externally' sounds reasonable until the business requirement is to routinely communicate with outside clients. The better policy asks more precise questions: Is this the internal or client-approved version? What classification does the document carry? Is this recipient approved for that classification? Is the file encrypted? Should the user be able to override the warning? Should the security team be alerted?

A Simple Test

There is a straightforward way to evaluate an organization's current posture. Take one of its genuinely sensitive documents - CUI, PHI, an acquisition plan, a customer database, a board package or proprietary technical material - and determine what happens when an authorized employee attempts to move it somewhere it should not go.

• Can it be emailed to an unauthorized external party?
• Can it be uploaded to personal cloud storage?
• Can it be copied to removable media?
• Can its contents be pasted into an unapproved AI application?
• If it leaves the environment, can access to it still be controlled?

The answer should not depend entirely on the employee noticing the mistake before clicking Send.

The Morgan Stanley event was not a sophisticated cyberattack. That is precisely why it is worth paying attention to. The user was authorized, the application was legitimate and the business activity itself was routine. The problem was that sensitive data crossed a boundary it should not have crossed.

Organizations spend heavily to keep attackers from reaching sensitive information. They should devote comparable attention to what happens after a legitimate user already has it.