THE TECHNOLOGY BLIND SPOT
The connection succeeds on the first try. A green checkmark confirms it: authenticated, encrypted, token verified. An attorney has just wired her case files into an AI assistant, and the software reports the link is secure. The report is true and beside the point. Authenticated is a statement about the pipe. It says nothing about whether the privilege survives the trip.
On May 20, 2026, the National Security Agency’s Artificial Intelligence Security Center published a public advisory on the protocol doing the wiring. The Model Context Protocol, or MCP, is the open standard Anthropic released in late 2024 to connect AI models to outside tools and data. The agency’s verdict was blunt: adoption has outrun the security model, and the protocol shipped with a flexible and underspecified design. When a signals-intelligence agency issues a formal warning about the plumbing a firm is quietly installing, the window for not knowing has closed.
Read the protocol’s own security documentation and a pattern emerges. It covers authentication, authorization, token handling, session integrity, and preventing code injection. Every section answers one question: can an unauthorized party reach the connection or hijack it. That is real security, and it matters. It is also not the question privilege asks.
Privilege does not attach to a connection. It attaches to communications, and it survives only while those communications stay inside a protected circle: the client, the lawyer, and the agents the lawyer retains to help deliver legal advice. Disclose the same material to a third party who owes no duty of confidentiality, and the protection is gone. [See The Conversation That Saves Privilege, The Technology Blind Spot (2026).] MCP has no concept of that circle. It cannot tell a privileged document from a grocery list, and it makes no representation about what the operator on the far side may read, retain, or reuse.
The protocol is also indifferent to who uses it. The NSA found MCP deployed across business, finance, legal, and software development, including for sensitive tasks like querying personal data. No legal edition understands privilege. No setting flags attorney work product. The same standard that connects a marketing tool to a sales database connects a litigator to her clients’ secrets, and it treats both the same way.
An obvious objection is that the standard has grown up. The 2026 specification mandates OAuth 2.1 and requires resource indicators that bind a token to a single service. Verified server directories exist. A firm that buys a certified connector, the argument goes, has bought its way out of the problem. The objection is half right. Those controls do real work against stolen tokens and rogue servers. They do nothing about privilege, because privilege turns on a question no certificate answers: is the server on the far side an agent of the attorney, bound to protect the communication, or a third party whose terms reserve the right to use what it receives. Certification confirms the code is what it claims to be. It does not confirm the operator owes your client a duty.
Most connectors in the field carry no certification at all. Server registries today operate as directories, not guarantors: a malicious operator can publish a server that looks legitimate while the user gets no cryptographic assurance about its code or what it does with the data. The risk compounds when attorneys build their own. The protocol’s documentation warns that a locally run server can execute arbitrary commands with no visibility into what those commands do. In July 2025, security researchers at JFrog documented exactly that: a flaw in a widely used MCP proxy let a malicious server run code on the connecting machine and reach its credentials and keys. It scored 9.6 out of 10 on severity and was the first recorded case of full remote takeover from a remote MCP server.
Consider the consequence inside a single matter. Diane Okafor is a composite, drawn from the fact patterns courts are now seeing, not a real attorney. She runs a small employment practice and, to keep up, connects her document store to a consumer chatbot through a connector she configured herself over a weekend. Months later, opposing counsel learns the firm’s privileged case strategy passed through that connector to a service whose terms permit it to read what it receives. The motion to compel does not argue the documents were never privileged. It argues the privilege was waived the moment Diane routed them to a party with no duty to protect them. To save the privilege she would need to show the connector’s operator was her agent, or that she took reasonable steps to prevent the disclosure under Federal Rule of Evidence 502(b). The same failure implicates Model Rule 1.6(c), which requires reasonable efforts to prevent the inadvertent disclosure of client information. She configured the connector in an afternoon. She can show neither.
This is the gap a vendor’s security paperwork will not close. A SOC 2 report describes a provider’s controls over a fixed window. It never examines whether a given connection carried privileged material to a party outside the circle. [See Your SOC 2 Audit Stops Where Your AI Privilege Risk Begins, The Technology Blind Spot (2026).] The certificate and the privilege answer different questions, and the attorney who treats them as one learns the difference in a hearing.
The claim here has a limit worth naming. MCP is not insecure, and not every connector waives privilege. A connector that routes communications only to a server the firm controls, or to a vendor bound by an agreement that makes it an agent of the lawyer, can preserve the protection. The danger is not the protocol. It is the assumption that a secure connection is a confidential one, made by attorneys who never asked where their connector sends what it reads.
Closing the gap starts with one question this week. Pull the list of every MCP connector wired into any AI tool the firm uses. For each one, ask two things: what privileged material can it read, and where does it send what it reads. A firm that cannot produce the list has its answer already. The connectors are running, and no one scoped what they can see.
Recommended by LinkedIn
The green checkmark was never lying. The connection is authenticated, encrypted, and verified, exactly as promised. It confirms the firm secured the pipe. Whether the firm kept the privilege is a separate question, and the protocol was never built to answer it. Privilege is older than the tools, and it does not bend to make them convenient. The checkmark says the message arrived safely. It does not say it arrived only where it was allowed to go.
About the Author
JD Morris is Co-Founder and COO of LexAxiom, an Agentic AI platform for the business of law. Over a 25-year career, he has built and scaled enterprise technology products across Dell, EMC, VMware, and Cisco, including the first exabyte eDiscovery platform. He holds dual MBAs from Columbia Business School (Finance) and UC Berkeley Haas (Marketing), a Master of Legal Studies in Cybersecurity Law from Texas A&M, and a Master of Engineering from George Washington University. He writes The Technology Blind Spot on the intersection of emerging technology and law. Connect with him on LinkedIn at www.linkedin.com/in/jdavidmorris, on X at @JDMorris_LTech, or on Bluesky at @JDMorris-ltech.bsky.social.
References
1. Fed. R. Evid. 502(b).
2. Model Rules of Pro. Conduct r. 1.6(c) (Am. Bar Ass’n 2024).
3. United States v. Kovel, 296 F.2d 918 (2d Cir. 1961).
4. Nat’l Sec. Agency, Artificial Intelligence Sec. Ctr., Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (May 2026), https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf.
5. Model Context Protocol, Security Best Practices (2026), https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices.
6. CVE-2025-6514, Nat’l Vulnerability Database (July 9, 2025), https://nvd.nist.gov/vuln/detail/CVE-2025-6514.
7. Securing the Model Context Protocol (MCP): Risks, Controls, and Governance, arXiv (2025), https://arxiv.org/abs/2511.20920.
Originally published on LinkedIn Newsletter — The Technology Blind Spot
