Law Firms Should Control What AI Shares in Threat Data

AI is moving into cyber-threat sharing faster than the law is adapting, while the statutory scrub protects personal privacy, not client confidences. Firms should define and constrain what their threat-sharing pipelines can transmit.

Consider the Jones Day breach: a phishing attack gave an unauthorized third party access to data files for 10 clients.¹ The FBI warns that criminal groups target law firms for the sensitive information they hold and asks victims to share attack information so others can defend against the same threat.²

Those artifacts do not remain with the victim. They move into vendor feeds and sharing communities, which is the point of threat intelligence, and some reach those systems without a person ever touching them. EDR and other endpoint platforms can automatically send artifacts to vendors for analysis.

The Cybersecurity Information Sharing Act of 2015 requires entities to strip certain personal information from threat data before sharing and already permits an automated capability to do it.³ A reauthorization attached to the House defense bill in July would write artificial intelligence into the statute explicitly and run the framework to 2035.^4,5 It is not law yet: the Senate version has no matching provision, and the current authorities expire Sept. 30.⁶ But the pipeline is automating whether or not the statute names it. The expiration and its consequences for threat intelligence sharing have been examined closely, particularly after the law's brief lapse in late 2025.⁷ Less examined is what happens to the content of a submission once AI assembles it.

What a Submission Can Still Disclose

The duty reaches personal information identifying a specific individual. Firms hold vast amounts of confidential information that identifies no one: matter names, litigation strategy, unannounced transactions. ABA Model Rule 1.6 covers all of it,⁸ and the ABA has said that duty follows lawyers into their use of AI.⁹ CISA provides liability protection for qualifying information sharing conducted in accordance with the statute. That raises a harder question for firms: whether compliance with the statute's narrower sanitization rule could preserve that protection even when information protected by a separate confidentiality duty travels with the indicator.¹⁰

Consider BRICKSTORM, which Mandiant found targeting U.S. legal services. The actors cloned virtual machines running domain controllers and identity providers.¹¹ Cloned VM names are legitimate indicators a firm hunting that activity could share, and at a law firm those machines are often named for the matter they serve. A name like ProjectFalcon-APA-DC01 holds no personal information, so the sanitization duty does not reach it. Yet it discloses that a transaction exists, how it is structured, and what the firm calls it.

The Human Control Was Never in the Law

Why has this not already gone wrong? Two reasons, and neither is the statute.

Traditional automated extraction was largely built around typed fields (addresses, hashes, domains) rather than generating the prose describing what happened. The narrative still had to come from an analyst. Sharing platforms also retain a human publication gate. In MISP, an open-source threat-intelligence sharing platform, an event is not distributed simply because it exists; a user must publish it. But that gate applies to the event as a whole, not to each field within it. The person clicking publish is usually the same person who wrote the narrative and therefore supplies the last layer of contextual judgment.

So the control is the analyst's own eye. Writing the incident description, they see ProjectFalcon-APA-DC01 and drop it, not because a rule requires it, but because they recognize what it is. Nothing in the law tells them to.

AI removes both protections at once. A model can write the prose, which is the only reason extraction stayed clear of the narrative field. And once it does, the publish click approves text nobody composed. The scrub will not catch it, because a VM name is not personal information. The submission can be fully compliant and the client exposed anyway.

That is the governance problem when AI takes over a step a person used to perform: the written rule survives, but the unwritten judgment may not.

Define What May Leave

The instinct is to put a person back in the loop. At scale the reviewer becomes the last signature on an automated process rather than an independent control.¹² The better strategy is not catching what should not leave. It is defining what may.

Firms do not need to invent a format. STIX and MISP already handle the atomic indicators: a hash field takes a hexadecimal string, and no VM name travels through it. The exposure sits in the layer those standards deliberately left open, the free-text descriptions and comment fields that exist because analysts need to explain what happened.

So the work is not defining a schema. It is governing what may enter the fields the schema leaves open. Where a value can be constrained, constrain it: controlled vocabularies for severity and actor category rather than prose. Where it cannot, validate against authoritative internal records. Firms already keep client and matter databases for conflicts purposes, and checking outbound values against that system of record beats a static list of sensitive terms. A deny-list catches what someone thought to prohibit; an allow-list defines what is permitted.

That leaves the narrative fields, and no allow-list can police a paragraph. It does not need to: narrative submissions are few enough that a person can read them before they leave, and where volume outgrows that, automated inspection can flag the obvious cases first. Then sample: a fixed number of records each month, read the way a competitor would.

All of it depends on logging. Rule 1.6(c) requires reasonable efforts to prevent inadvertent disclosure, judged on what a firm can show, and a firm cannot sample what was never recorded or tell a client what left. There may be no public cases of matter names escaping through threat sharing. That is not evidence that the risk is absent; without logs, organizations cannot know how often it happens.

Oversight, Not Engineering

Every firm here is likely both contributor and recipient. One that under-scrubs is not only exposing its own client; it is putting that material into the corpus every other member ingests. Congress could require what makes an AI-mediated process auditable: an accountable owner, records of what was transmitted and withheld, performance measurement, escalation rules. The bill's limiting phrase, AI "strictly deployed for cybersecurity purposes," appears three times and is never defined.

Much of this pipeline sits with security vendors and sharing communities, not inside the firm's own infrastructure. For firms, the problem is therefore less about building the technology than governing what they have authorized it to do. Firms need not wait:

• Ask security vendors and threat-intelligence providers, in writing, what their tooling transmits; whether a model assembles it; and whether prompt-injection attacks were considered.
• Work with security and threat-intelligence vendors to limit what can be inserted in free-text descriptions.
• Ask for a sample of what the firm has already shared and read it the way a competitor would.
• Require a log of what was transmitted and what was withheld.

In security, the goal is not to watch AI decide. It is to be able to reconstruct what it did and how.

Kyle Salous is a Chief Information Security Officer and founder of OC2 Cyber.