How Stolen Data and AI Are Changing Cybersecurity

In my work, I see breached data circulating through the dark web, criminal Telegram channels and other online spaces. Looking at these materials, it becomes difficult to treat data theft, artificial intelligence and cybersecurity as separate subjects. Information taken from one organization can help someone understand another. A compromised account can expose a relationship that leads to a more convincing approach. An old document can explain how a business works long after the incident that exposed it has disappeared from the news.

The connection matters because the consequences of a breach can continue after the original organization has restored its systems. Stolen information remains available for reuse, sometimes by people who had nothing to do with the first intrusion. AI can reduce the effort required to interpret that information. Meanwhile, organizations are giving AI systems access to their own data and business processes, creating new questions about authority and control.

My view is that future cybersecurity will depend heavily on how well we understand these relationships. We need to follow information from its exposure through to what it could enable, then connect that possibility to a practical response. Monitoring a criminal channel is useful. Knowing which access to revoke, which business process to protect and which service could be interrupted is where the information becomes valuable.

This requires a wider view than a catalogue of new technologies. Identity management, software maintenance and the ability to recover from disruption remain central. So do human judgment and the quality of the evidence behind a security decision. AI increases the importance of getting these things right because it can accelerate activity on both sides.

Breached Data Can Enable Another Attack

A stolen password has an obvious potential use. The value of a collection of internal emails is less immediately visible. Those messages may reveal who approves an invoice, how a supplier communicates and when a manager is away. An internal technical document might identify a service provider or explain the purpose of an unfamiliar system. Separately, these details may seem ordinary. Together, they can make an organization easier to understand.

This is why counting exposed records tells us relatively little about the operational danger. A large collection of obsolete contact details and a small collection of current administrator credentials create different problems. Even within the same dataset, some information may be useful for direct access while other material supplies context for fraud or further reconnaissance. The security team needs to establish what the material could enable.

There is a documented example of how long that usefulness can last. In June 2024, Mandiant described the UNC5537 campaign against Snowflake customer environments. In the incidents it investigated, attackers used compromised customer credentials, primarily obtained through infostealer infections. Some associated infections dated back to 2020, and credentials remained valid in certain cases years after theft. Mandiant identified missing multifactor authentication and absent network access restrictions among the conditions that enabled the compromises. Its investigation did not find evidence that access resulted from a breach of Snowflake's enterprise environment.

The implication is uncomfortable. An organization can have an unresolved exposure long before it sees the consequences. The theft, subsequent resale and eventual use of a credential need not happen close together. Different actors may participate at different times, and the organization that ultimately loses data may be different from the organization responsible for the device originally infected.

That does not mean every old credential remains dangerous indefinitely. Passwords change, sessions expire and accounts close. The useful question is whether the underlying access still exists. For contextual information, the answer is less straightforward. A document about an abandoned project may have little value, while a description of a long-standing supplier relationship may remain useful. Time affects different types of information differently.

Criminal Markets Connect Otherwise Separate Incidents

The dark web is one part of this activity. Criminals also use ordinary websites, messaging services and private communities. Telegram is a mainstream platform that some criminals misuse, and activity on Telegram is not inherently dark-web activity. Confusing the venue with the crime can make analysis less precise and lead organizations to overlook relevant information elsewhere.

Microsoft's 2025 Digital Defense Report describes an infostealer supply chain in which Lumma collects sensitive information from browsers and applications. The data is sold through dark-web forums and Telegram channels to access brokers, after which other criminals, including ransomware operators, can use it to enter target networks. This illustrates a division of work across an illicit market rather than a single attacker carrying out every stage.

Specialization changes the economics. Someone who can distribute malware does not necessarily need the skills or patience to exploit every organization represented in the resulting logs. A buyer may be better positioned to recognize a valuable account. Another participant may understand how to turn access into extortion. Revenue-sharing arrangements, payment services and the ability to advertise to buyers help connect these activities.

Defenders therefore need to understand incentives as well as technical indicators. A seller may exaggerate a dataset's freshness or misrepresent its origin. An extortion actor may make a claim primarily to create pressure. A repost may describe a previously reported incident as if it were new. The existence of an advertisement is evidence that somebody is making an offer or allegation. Establishing the underlying compromise requires more work.

Visibility is incomplete, too. Some transactions happen privately, and some attackers have little reason to advertise what they hold. An organization that finds nothing in the channels it monitors has learned something about those channels. It has not demonstrated that its information is absent from criminal possession.

AI Reduces the Cost of Understanding Stolen information

The most useful way to think about AI in this context is to consider the work required to make sense of a large archive. A collection of documents may contain different languages, inconsistent names and repeated material. An analyst must separate relevant information from noise, identify relationships and decide which apparent connections deserve further attention. Much of that work is laborious.

AI can assist with translation, classification and summarization. Combined with conventional search and data-processing tools, it can help organize material that would otherwise take considerable time to review. My assessment is that this can increase the practical usefulness of some stolen datasets. Information that was previously too expensive to examine in detail may become worth examining.

This argument does not require the stolen material to become part of a model's training data. A system can process documents supplied for a particular task or retrieve relevant passages from an indexed collection. Keeping that distinction clear matters. Saying that criminals can analyze stolen data with AI is a narrower claim than asserting that public AI models have been trained on a particular breach.

The UK National Cyber Security Centre's 2025 assessment of the threat through 2027 projected that AI would make elements of cyber intrusion more efficient and help attackers exploit known vulnerabilities. It also anticipated pressure on defenders from a shorter interval between disclosure and exploitation. These were assessments of likely developments, not a measurement of AI involvement in every subsequent attack.

Capability evidence needs similar care. In May 2026, the UK AI Security Institute reported progress in autonomous cyber testing while explaining that its cyber ranges involved small, undefended networks with initial access already provided. Results under those conditions do not establish reliable performance against a defended enterprise. A successful sequence in a test environment and a repeatable campaign across real organizations are different achievements.

We can take the direction seriously without pretending that every uncertainty has disappeared. Models can misread documents, invent relationships or produce code that fails. Long tasks introduce dependencies and opportunities for error. Human expertise, access to useful tools and the quality of the surrounding system still affect outcomes.

Even with those limitations, partial assistance matters. An attacker who saves time on research or drafting may have more time to pursue targets. A defender who can review relevant evidence sooner may have a better opportunity to intervene. The advantage depends on how effectively each side connects AI to its actual work.

Identity Connects Information to Authority

An exposed record becomes especially consequential when it grants access. We often describe that problem through passwords, but organizations also depend on session tokens, API keys and service accounts. These are mechanisms through which software recognizes a user or permits a task. Their security significance depends on what authority they carry.

A credential for a narrowly restricted service creates a different exposure from one that can read an entire customer database. A token accepted for a short period has different consequences from a long-lived secret embedded in an integration. An account that nobody owns becomes difficult to review, rotate or retire. Counting identities without understanding their permissions leaves much of the problem unresolved.

Multifactor authentication remains valuable, particularly phishing-resistant methods, which CISA recommends in its StopRansomware Guide. But authentication at sign-in does not answer every question about an already established session or a separate machine credential. Depending on the system, changing a password may not invalidate every token, revoke an application's permissions or remove access that an intruder created after entry. Incident response must verify the relevant revocation behavior.

The same reasoning applies to AI agents. An assistant that recommends an action and an agent authorized to execute it have different risk profiles. Once an agent can retrieve confidential records or change production systems, the organization has delegated authority to software that interprets instructions and external information.

NIST's February 2026 concept paper on software and AI agent identity addressed this issue through identification, authorization and auditing, including questions about controls against prompt injection. It was an exploration of a potential project, not a completed certification scheme or evidence that agent security had been solved.

For an organization adopting agents, I would start with the actions each one genuinely needs to perform. Give it a distinct identity, make its permissions reviewable and establish who is responsible for its behavior. Sensitive actions should face controls appropriate to their consequences. An agent should not inherit a broad administrator account simply because that makes integration easier.

The practical test is whether the organization can withdraw the agent's authority promptly and explain what it already did. If it cannot do either reliably, a more capable model may increase the scale of an existing control failure.

AI Systems Create Their Own Security Exposures

There is another connection between AI and breached data. Organizations may introduce new exposures while using AI to solve old ones. A system that brings internal documents into a searchable assistant needs access controls that follow the data. Indexing a confidential document must not make it available to every employee who can ask a question.

An AI workflow also creates places where sensitive information might be retained, including prompts, logs and intermediate outputs. These need deliberate handling. A company can approve a model for one purpose while an employee uses a different service for convenience. The relevant questions include what information leaves the organization, which parties can access it and how long it remains available.

Prompt injection creates a related problem. An agent may encounter an attacker-controlled instruction inside material it has been asked to read. If it treats that content as an instruction to act, the attacker may influence the workflow without controlling the original user request. The NCSC's December 2025 analysis argues that organizations should not assume a model will enforce a dependable boundary between trusted instructions and untrusted content. It emphasizes safeguards outside the model that restrict what the wider system can do.

Consider an illustrative case in which an assistant reviews a supplier document before preparing a payment request. The system should not allow text inside that document to decide whether authorization is required or where confidential information may be sent. Those decisions belong in application controls that the document cannot rewrite. Model-level defenses can help, but the business process must remain secure when the model makes a mistake.

AI security also extends beyond prompts. NIST's 2025 adversarial machine learning taxonomy addresses attacks involving poisoning, evasion and privacy, among other categories. An organization must consider the integrity of the data and components on which its system depends, especially when outputs influence consequential decisions.

For security teams, this means the tools used to analyze hostile information must themselves be designed for hostile input. A system reviewing criminal posts should not gain authority from anything written in those posts.

AI can make weak analysis look convincing. A fluent explanation may hide a mistaken match between two people or an unsupported assumption about a company's infrastructure. When thousands of records are processed, a small recurring error can produce a substantial amount of misleading output.

The date attached to a record is a good example. The date when an analyst discovered a dataset may differ from the date it was posted, the date it was collected and the date of the original compromise. Treating these as interchangeable can turn old material into an apparent new incident. An automated system must preserve those distinctions.

Names and domains need similar discipline. A corporate email address in a breached third-party service does not, by itself, prove that the corporate network was penetrated. A hostname may refer to a retired system. A shared company name can connect unrelated businesses in different jurisdictions. Analysts need enough context to establish the relationship they are claiming.

This is where data science becomes part of security practice. Deduplication and entity matching influence which exposures get counted and which organizations receive alerts. Precision matters because it describes how often reported findings are correct. Recall matters because it concerns how much of the relevant material was found. A high overall accuracy figure can be misleading when most examined items are benign. The evaluation should reflect the actual decision the tool supports.

I would judge an automated intelligence workflow by whether an analyst can trace an important conclusion to its evidence. The system should distinguish an actor's allegation from corroborated observations and identify what remains uncertain. It should also retain enough provenance for someone else to review the reasoning. Speed is useful only when the result is dependable enough for the action it triggers.

There is a human cost to getting this wrong. Incorrectly linking a person to criminal activity or distributing a false breach claim can cause harm. The quality controls around threat intelligence deserve the same seriousness as the controls around the systems that consume it.

Dependencies Extend the Organization Beyond Its Own Systems

The connection between leaked data and access becomes more complicated when suppliers enter the picture. A company may protect its own endpoints while a contractor accesses sensitive systems from a device it does not manage. A cloud application may be secure in isolation while an integration has excessive permissions. A software component may introduce an exposure across many otherwise unrelated organizations.

Verizon's 2026 Data Breach Investigations Report reported that 31 percent of breaches in its dataset began with vulnerability exploitation and that third parties were involved in 48 percent of breaches. These figures describe the report's analyzed cases, not an individual company's probability of compromise. They also do not establish that AI caused each incident. They support continued attention to software exposure and external dependencies alongside stolen credentials.

For security leaders, the practical problem is identifying which relationships can affect essential operations. A long supplier inventory becomes much more useful when it shows which providers can reach sensitive information, which integrations can change systems and which service failures would interrupt delivery to customers.

A trusted supplier still needs appropriate access boundaries. Trust in a company does not establish that every account, device and application connected to it is safe at every moment. The organization receiving a service needs a way to restrict access and respond when the relationship becomes a route for compromise.

Concentration creates a further concern. Several business processes may depend on one identity provider or cloud service. Failure there can interrupt work even when the organization itself has not been attacked. Cybersecurity planning should account for this dependence without describing every technology outage as malicious activity.

AI-generated software belongs in this discussion as well. Faster code production can increase the amount of software an organization must understand and maintain. Each deployed service still needs an owner, sensible permissions and a way to receive fixes. Development speed becomes a security benefit when the organization can validate and operate what it creates.

Human Trust Needs a Dependable Process

Stolen information and generated content can reinforce each other. A fabricated message becomes more persuasive when it refers to a real supplier, an actual project or a conversation the recipient remembers. The contextual details can come from a leak even if the wording and accompanying media are newly generated.

The FBI's December 2024 warning on generative AI and financial fraud described criminal use of generated text, images, audio and video to make schemes more believable. Its examples included impersonation and voice cloning. That establishes a practical reason to strengthen verification, without assuming that every convincing fraud attempt uses AI.

I would be cautious about relying primarily on a person's ability to notice visual defects or unnatural wording. An employee should have a dependable procedure for verifying a consequential request even when the message looks professional and the voice sounds familiar. The process must work under pressure.

For example, a change to a supplier's bank details can require confirmation through an independently established contact and approval within the organization's payment system. A request to recover an executive's account can face the same verification standard as other sensitive accounts. Urgency or seniority should not create an easy exception.

Training remains useful when it helps people carry out these procedures. Telling employees to be suspicious of everything can produce fatigue and delay legitimate work. Giving them a clear way to verify an unusual request turns awareness into a usable safeguard. Management must support that behavior when a check is inconvenient.

The security team cannot solve this alone. Finance, human resources and customer service all operate processes that establish identity or grant access. Their decisions belong in the organization's security model.

Cybersecurity Reaches Physical Operations

The consequences of digital compromise depend on the service behind the system. A stolen database creates confidentiality concerns. A corrupted operational instruction or unavailable control system can raise questions about safe production and the delivery of essential services. Connected industrial equipment makes the relationship between information and physical consequences more direct.

In August 2025, the NSA joined CISA and other partners in releasing guidance on operational technology asset inventories. The guidance connects knowledge of OT assets to risk identification, vulnerability management and incident response, with attention to the safety of operational environments. It addresses a basic requirement that sophisticated analytics cannot compensate for if it is missing.

An organization needs to understand how its operations actually function. Which systems are essential to keep a facility running safely? Which remote connections are required for maintenance? What happens if the identity service becomes unavailable? These questions often cross the boundaries between security, engineering and operations teams.

This affects how response should be designed. Automatically isolating a compromised office laptop may be appropriate in one context. Taking a similar action against a system involved in an industrial process may require engineering judgment and a safe operating procedure. Automation must account for the consequence of the action it proposes.

Recovery needs the same care. A backup is useful only if it can be restored into an environment that is sufficiently trustworthy and supports the required service. Restoring corrupted information, reconnecting an infected device or reintroducing compromised credentials can recreate the original problem.

Electricity and connectivity also set limits on digital resilience. A fallback that relies on the same unavailable infrastructure may fail when needed. For organizations providing essential services, the planning question is how to preserve safe operations during a disruption and how to validate the return to normal service. The scenario may involve a cyberattack, a technical failure or several problems at once.

Incentives Influence Which Threats Become Persistent

Technology provides capability, but incentives help determine where it is applied. Criminals seeking revenue may value reliable access and a victim's willingness to pay. An actor interested in espionage may prefer quiet access to commercially or strategically useful information. Someone seeking disruption may care less about preserving the value of the data.

The same exposed system can matter to different actors for different reasons. A regional supplier may appear financially unremarkable while holding access to a strategically important customer. A small research company may have information whose value is poorly represented by its current revenue. An organization should assess what it enables others to do, as well as what it owns.

AI may reduce some costs, but it does not remove every constraint on an operation. Attackers still need relevant access and useful information. They may face unreliable tools, defensive monitoring and difficulty converting a compromise into payment. For defenders, this creates several opportunities to make an operation less dependable or less profitable.

Criminal markets are therefore relevant to national security as well as enterprise protection. Commercially traded tools and access can be useful to actors with different objectives. Yet shared tools, language or infrastructure are insufficient on their own to establish who directed an incident. Attribution needs evidence, and uncertainty should remain visible when decisions depend on it.

For organizations operating across countries, response can also depend on whether partners exchange useful information quickly and whether responsibilities are clear. A technical control may be available while the authority to activate it is unresolved. Contracts and working relationships affect what happens during the incident, particularly when several providers hold different parts of the evidence.

Some Information Stays Valuable for Years

The lifetime of sensitive information deserves more attention. Many organizations focus on whether information is confidential today and give less thought to how long its exposure could matter. Research, intelligence records and certain personal information can retain value well beyond the useful life of a password.

NIST explains the concern described as harvest now, decrypt later. An adversary may collect encrypted information in the hope that future computing capabilities will make it readable. A sufficiently capable quantum computer could threaten widely used public-key cryptographic systems, although its arrival remains uncertain. NIST finalized its first three post-quantum cryptography standards in August 2024, providing a basis for migration planning.

This should not be turned into a prediction that all encryption will suddenly fail on a known date. Different cryptographic mechanisms face different risks, and a migration deadline is not a forecast of when an adversary will gain a particular capability. The reasonable response is to understand which information needs long-term confidentiality and where vulnerable cryptography protects it.

Data retention belongs beside that work. Every unnecessary copy extends the amount of information an organization must protect. Keeping information because storage is inexpensive can create obligations and exposure that last much longer than the original business purpose. Security planning should include deliberate decisions about what to retain and how to dispose of material that is no longer needed.

Intelligence Has to Change a Decision

All of these connections lead back to how an organization acts. A threat report can describe a convincing danger while leaving the recipient unsure what to do. A monitoring service can discover exposed records while the affected account remains active. The gap between awareness and intervention is a management problem as much as a technical one.

NIST's Cybersecurity Framework 2.0, published in 2024, added Govern to its existing functions and placed greater emphasis on governance and supply chains. That reflects the need to connect security activity to organizational responsibility. Tools can supply information, but an organization still needs people with the authority to make and implement decisions.

Consider an illustrative finding involving a contractor's credential. The first task is to establish the evidence and determine whether it corresponds to a current relationship. The responsible team can then assess exposure through authorized internal checks, examine relevant activity and revoke or replace the affected access as appropriate. If a device remains infected or an unnecessary integration stays connected, changing one password may leave the underlying issue unresolved.

The same finding may justify a broader review of how contractor access is managed. That review should be proportionate to the evidence. A single exposure does not prove that every contractor is compromised, but it may reveal a repeatable weakness in the organization's process. A useful intelligence function helps the organization distinguish the immediate response from the systemic correction.

AI can support this work by organizing evidence, locating related records and preparing a proposed response. For well-understood actions with limited consequences, controlled automation may be appropriate. More consequential decisions need safeguards that match their impact. The organization should test what happens when the recommendation is wrong, when a data source is unavailable and when the automated action fails halfway through.

The measures of success should follow the work. How long did exposed access remain usable after discovery? Could the organization identify the affected service and reach its owner? Did the response remove the exposure? Could a critical operation recover within its required time? These questions reveal more about protection than the volume of alerts or the number of AI features in a product.

When I look at breached data circulating through criminal channels, I see information that may still have operational value to someone. The responsibility of cybersecurity is to determine that value before it is used against the organization. A verified finding, connected to a real dependency and acted on by someone with authority, can close a path that would otherwise remain available. That is the outcome I would expect an intelligence program to deliver.