AI Against You: The Faster Adversary

For an attacker using social engineering, a reason to be believed can matter more than a clever exploit.

For years, social engineering has depended on research: finding names, roles, relationships, current projects, and the language an organization uses. Much of that information is public, scattered across company pages, conference agendas, job postings, social media, and press releases. An attacker could assemble it by hand. The work was possible, but slow—and the more targets involved, the more generic the resulting messages tended to become.

A language model can help turn scattered clues into plausible prose. It can summarize a company’s public footprint, extract people and roles, and draft messages that refer to a real project or imitate the tone of an ordinary business exchange. It can produce versions for different recipients, adjust formality, or translate a message into another language. The capability-based assessment is straightforward: this could lower the effort needed to prepare tailored content. How often criminals use it at scale, and whether it materially improves campaign outcomes, are separate empirical questions that require threat research rather than inference from the capability alone.

There is evidence of use, not just possibility. In January 2025, Google Threat Intelligence Group reported government-backed actors using Gemini for research, scripting assistance, and content creation. Its analysis described productivity support rather than novel capabilities in the activity it examined ^[1]. That is a dated observation of one provider’s visibility, not a ceiling on what later models or other actors can do.

Consider Northstar, the company we have been following. It has announced a new regional distribution center for medical supplies. Its website names the operations executive leading the project; a professional profile lists a procurement manager; job advertisements reveal which logistics software the company is hiring people to support. These details are not secrets. Their value comes from being assembled.

In an illustrative scenario, an attacker could ask a model to summarize the public material and suggest plausible pretexts. One draft might appear to come from a supplier asking the procurement manager to review a revised delivery schedule. Another might be addressed to an operations employee and refer to the new center’s opening timeline. The wording could be polished, shortened, translated, and varied. The point is not that this workflow is established as routine criminal practice; it shows how a model could make specific message variants easier to prepare.

The meaningful shift is not that AI makes deception new, but that it may reduce the effort required to make deception specific. It can also help a person who writes poorly, works in a second language, or lacks familiarity with a target’s industry produce more fluent content. Variations matter because repeated identical messages are easier to recognize and filter. A model can help change the surface while preserving the same underlying request.

A convincing email is not an operation. The attacker still needs a route to the recipient, a useful target, and a next step that produces value—such as a reply, a credential entry, an attachment opened, or a payment redirected. Public information may be stale or misleading. A plausible story can fail against a second channel of verification. The message still has to reach its recipient and prompt an action.

Nor does fluency prove that a message was generated by AI. A polished note may be human-written; a clumsy one may be machine-assisted. For defenders, the durable question is not “Does this sound like a model?” It is “Does this request fit the relationship, process, and level of authority it claims?” A familiar supplier asking for an unusual change to payment details deserves scrutiny whether the message is elegant or riddled with errors.

This is why awareness training alone is an incomplete answer. Employees can be taught to notice urgency and unusual requests, but organizations should also make consequential actions harder to complete through a single persuasive message. Independent confirmation of payment changes, clear reporting paths, and well-designed approval processes reduce the leverage of a tailored pretext. The point is not to make every employee a forensic linguist. It is to avoid making trust in a well-written email the control on which the business depends.

For Northstar’s security leaders, the practical question is therefore not whether an attacker can write a convincing message. That was possible before. It is whether the organization’s public information, business workflows, and verification habits give a tailored message a direct path to a consequential action.

A persuasive message can open a door. A software weakness can leave one unlocked. AI may help an attacker investigate that weakness, but finding it is only one stage of a much larger task.

For Northstar, imagine an internet-facing service that handles supplier records. Its code is old, its documentation incomplete, and its developers are busy. A model might help an analyst trace how a request moves through the code, spot an unsafe assumption, or compare the software’s behavior with known vulnerability patterns. This is a plausible capability-based use, not evidence that attackers routinely discover production vulnerabilities this way.

Three different achievements

The phrase AI found a vulnerability can conceal three distinct tasks.

First comes finding a weakness: identifying a flaw in code, configuration, or system behavior. A model can summarize a large codebase, suggest suspicious paths, explain a static-analysis alert, or generate tests that probe a developer’s assumptions. A suspected flaw still needs validation: code that looks dangerous in isolation may be protected by checks elsewhere; an apparent flaw may be unreachable, or depend on conditions that do not exist in the deployed system.

Second comes turning the weakness into a working exploit. A vulnerability report is not an exploit. An exploit must cause the target to behave in a useful, repeatable way, often while navigating defenses, version differences, memory protections, authentication, and other practical constraints. Models may assist researchers in understanding existing exploits, adapting code, or reasoning through a proof of concept. Whether a proposed result works against the target version has to be tested.

Third comes compromising a real environment. Even a working exploit may be irrelevant to a particular organization. The affected component may not be exposed, may be patched, or may sit behind controls that prevent meaningful access. An attacker still needs a route to the target, the right conditions, and a way to turn initial access into an objective—such as reaching sensitive data or disrupting operations.

These stages are related, but they are not interchangeable. A lab result at the first or second stage does not establish routine success at the third.

Where AI can make a difference

An established use of these tools is assistance with bounded tasks: navigating unfamiliar code, explaining a suspicious function, generating test cases, or sifting through technical material. Such help could lower the effort needed to investigate a lead, particularly for someone who already has enough expertise to frame and check the work. Access to an explanation is not the same as the judgment needed to distinguish a real vulnerability from a false alarm.

Research demonstrations deserve attention, but careful interpretation. In controlled environments, models have been tested on vulnerability discovery, code repair, and cyber-range tasks. Those results show contributions to particular workflows under defined conditions. They do not establish how often an attacker can find exploitable flaws in diverse production systems, overcome real-world defenses, or do so more cheaply than existing methods. Benchmarks measure what they were designed to measure; attackers encounter messier systems and defenders who change them.

There is also a plausible operational pressure to watch: if AI-assisted analysis produces more leads, security teams may face more reports and noisy findings to triage. That does not establish that automated discovery is common or that a shorter patch window is already a measured consequence. It does make the ability to assess applicability and prioritize credible findings worth examining.

For Northstar, the important questions are practical: Which services are reachable? Which components are present? How quickly can the company identify affected assets, assess whether a flaw is applicable, and apply a fix or mitigation? If a credible exploit appears, who can authorize an emergency change, and how will the team verify that it worked?

AI does not erase the value of secure development, asset visibility, patch management, or layered controls. The strategic question is not whether AI can discover a flaw in a demonstration. It is whether Northstar can move from a credible signal to a verified risk decision and effective action before an adversary turns the same weakness into access.

The race from signal to action is not won by a model alone. It is won by a workflow.

Imagine a criminal group learns that a software flaw may affect Northstar. A person decides the target is worth pursuing. Ordinary scripts or scanning tools identify internet-facing systems. A model helps summarize public documentation, sort results, or draft messages tailored to employees who appear relevant. The operator reviews what matters, chooses a next step, and uses existing infrastructure—accounts, servers, stolen credentials, or rented services—to carry it out.

In this illustrative workflow, models contribute language, classification, or suggestions; scripts handle predictable repetition; and a human supplies goals, judgment, and decisions where uncertainty or risk is high. The combination could accelerate reconnaissance, content preparation, triage, or adaptation without making the campaign autonomous. These are possible roles in a workflow, not a claim about how prevalent any particular criminal practice is.

Human-directed assistance is not the whole picture. In November 2025, Anthropic reported a campaign detected that September in which operators selected targets and used Claude Code to perform substantial reconnaissance, exploitation, and data-handling work. It reported a small number of successful compromises, alongside model errors such as fabricated credentials ^[2]. This is a provider’s incident account, not an independent measurement of how autonomous attacks generally are. It nevertheless makes “AI only drafts material” an inadequate planning assumption.

In September 2026, Google reported a Q2 case in which an actor compromised a cloud resource and then planned, built, and executed an agent-enabled credential-harvesting campaign in under six hours ^[3]. That reported interval is not a measured acceleration against an otherwise identical human campaign, and it is not a universal response deadline. It does justify testing whether cloud monitoring and credential revocation can interrupt a rapidly developing operation.

These accounts show why autonomy must be examined step by step. People can choose objectives and supply access while agents execute consequential sequences between checkpoints. Human involvement and substantial machine autonomy can coexist.

The assembly line, not the robot villain

Many attack tasks are repetitive but not identical. An operator may need to review a hundred exposed services, identify which are likely to run a vulnerable component, and decide which deserve attention. Automation can gather and normalize the information. A model may help interpret messy descriptions or turn technical findings into a useful summary. A human can then verify the strongest leads and direct further effort.

The same pattern applies to social engineering. Generative tools can help produce message variations, adjust tone, or translate and rewrite content. Preparing the material is only one part of an attempt: it does not itself select a suitable target, provide mailbox access, bypass multifactor authentication, or persuade someone to take a consequential action.

This human-directed workflow is one operating pattern; the reported agentic campaigns above illustrate another. A person might use a model to reduce drafting time, a script to process results, and familiar tools to send messages or test systems. The potential gain lies in removing friction from parts of the work, not necessarily in removing people from it.

Where the handoffs are

To assess a particular workflow, look at its handoffs. What does the machine gather? What does it infer? What can it change or execute? Where must a person review the result? Those questions reveal where time might be saved and where a workflow can fail. Name the work before judging the AI: a model summarizing documentation, a script sorting scan results, and an operator selecting targets are different contributions, even when they belong to one campaign.

Models can misread a technical result or produce unsuitable guidance. Scripts can repeat a mistaken assumption at scale. Humans can overlook a warning when presented with a flood of summaries. And any plan still depends on the ordinary machinery of an intrusion: working access, network reachability, compatible software, credentials, persistence, and a route to the intended objective.

A task that works in a controlled demonstration may not work reliably across a live enterprise. Real environments contain inconsistent inventories, defensive controls, rate limits, changing configurations, and unexpected errors. A campaign may need an operator to inspect results, change tactics, or abandon a line of effort. The more consequential the action, the more important that judgment becomes.

For Northstar, this means preparing for the possibility that an adversary can produce and sort work more quickly, not assuming that every alert signals an independent digital army. A campaign could move from reconnaissance to a tailored attempt sooner if several small delays are compressed. The defensive question is: “Which parts of the attacker’s workflow might have become cheaper or faster, and what response time would that leave us?”

Plan for the possibility of compressed intervals between steps. Preserve the fundamentals that make those steps harder: accurate asset knowledge, strong identity controls, resilient monitoring, and practiced response. The operational focus is the workflow’s inputs, handoffs, and path to access—not the label “AI-powered.”

If someone says AI has made cyberattacks dramatically more effective, the first question is not whether the claim sounds plausible. It is: What, precisely, was observed? A model producing a convincing phishing email in a demonstration is not the same as an organization suffering a successful intrusion. A faster task in a laboratory is not proof that an entire attack has become faster in the wild.

That distinction is not academic housekeeping. Security leaders make investment and risk decisions under pressure. Hype can send resources toward imagined capabilities; dismissal can leave real changes unexamined. The useful position is neither “AI changes everything” nor “nothing has changed.” It is disciplined comparison.

Ask three questions of every claim

First, what was observed? Was the evidence a controlled experiment, a public demonstration, a vendor-reported result, a threat-intelligence investigation, or a confirmed incident? These forms of evidence answer different questions. A demonstration can establish that a technique is possible under specified conditions. It cannot, by itself, establish how often attackers use it or how reliably it works against real organizations. An incident report can document observed activity, but may not reveal whether AI materially changed the outcome.

Second, under what conditions? Which model, tools, data, permissions, and human supervision were involved? Was the task carefully framed by researchers, or did an operator have to discover the method independently? Did the model have access to current information, or was a human supplying the important context? A result achieved with extensive setup may still matter—but it is different from a capability that works cheaply and repeatedly with little expertise.

Third, what changed compared with existing methods? Attackers already use scripts, search engines, stolen credentials, translation software, and criminal services. If AI helps write a lure, did it make the lure more persuasive, make its production cheaper, or simply provide a new way to do something an operator could already do? The comparison is not “AI versus no technology.” It is AI versus the attacker’s next-best available method.

This last question is often the most consequential. A tool does not need to invent a new class of attack to alter its economics. If it reduces the time or skill required for a familiar task, it may let an attacker attempt that task more often, target a wider range of organizations, or spend human attention elsewhere. The change may be incremental at the level of one email and significant across thousands of attempts. Name the work before judging the AI, then ask what measurable change the evidence supports: cost, speed, scale, reach, or quality. A faster task is not, by itself, a better attack or a worse security outcome.

Possibility is not prevalence—but possibility still matters

Security reporting can blur important categories. Researchers may show that a model can identify a weakness in a particular environment. A threat-intelligence team may observe an adversary using a model to summarize stolen data or draft messages. A vendor may report that its system blocked a campaign. Each statement has a different evidentiary weight and a different scope.

A useful leader keeps those categories separate:

• Demonstrated: the capability worked in a defined test or controlled setting.
• Observed: investigators found it in real-world activity, with whatever limits the investigation had.
• Common: repeated, independently supported evidence suggests meaningful prevalence.
• Impactful: there is evidence that it changed outcomes—such as access gained, losses increased, or defense materially impaired.

These are not steps that every claim will climb. Some demonstrations never become practical. Some observed techniques remain rare. And a technique can be uncommon yet important if it enables a severe outcome. The point is not to demand perfect statistics before acting; it is to avoid quietly converting “possible” into “routine,” or “used” into “decisive.”

For example, suppose an attacker uses a language model to produce fluent, personalized messages in several languages. That is a credible way to reduce the labor of social engineering. But fluency alone does not establish that recipients will trust the message, that it will bypass controls, or that the campaign will outperform one built from stolen correspondence and careful human research. The security question is comparative: what does the model make cheaper, faster, or easier to repeat—and what still limits success?

The advantage may be economic before it is technical

The incident accounts above establish reported use in particular settings. They do not quantify the overall economic advantage. Four mechanisms help explain what leaders should measure next; none supplies a general estimate of cost reduction or prevalence.

Lower costs. If a task that once required a skilled person’s hour can be completed with less effort, the attacker’s minimum viable operation may change. The gain could be modest per task and substantial in aggregate. More targets might become worth pursuing; more failed attempts might be affordable.

Easier iteration. Attackers may be able to generate variants, test approaches, and refine a message or script more quickly. If so, iteration could matter because many attacks fail for ordinary reasons: a message looks wrong, a lure misses its audience, or a method does not work in a particular environment. Faster retries could increase the chance that one attempt fits.

Broader access to expertise. AI may help a less experienced operator understand unfamiliar terminology, adapt material, or navigate a complex workflow. That does not turn every novice into an expert. It could, however, narrow the distance between knowing what one wants to do and finding enough help to try. Expertise remains a constraint; it may become a less reliable filter.

Pressure on response time. Defenders have always had to detect and contain attacks. If AI-enabled preparation and iteration are faster in a given setting, they could compress the interval available to recognize a pattern and act. The relevant measure is not a dramatic claim about machine-speed attackers. It is whether an organization’s existing detection and response cycle leaves adversaries more opportunities before containment.

These pressures could reinforce one another. Lower costs might support more attempts; easier iteration could improve the odds of a workable attempt; broader access could expand the pool of people able to try; and shorter intervals could make delayed defense more costly. None requires an autonomous attacker. A human operator can remain firmly in control while delegating pieces of the work.

For the fictional CISO at Northstar, the practical exercise is to take a claim about an AI-enabled threat and write two versions of the risk statement. The first describes the capability: what the system did, in what setting, with what assistance. The second describes the organizational consequence: what becomes cheaper or faster, which controls may be strained, and how much response time remains. If the second statement cannot be supported, the claim may be interesting without yet being a reason to redirect the security program.

Uncertainty is not a reason to freeze. It is a reason to make decisions that remain useful across several plausible futures: maintain reliable asset and identity controls, monitor for behaviors rather than assuming a particular tool, and practice response at the tempo the organization can actually sustain. Ask for evidence; also ask what would change your mind. That keeps the conversation anchored as capabilities and attacker practices evolve.

The attacker’s advantage is therefore not one universal breakthrough. Reported operations already include substantial delegated execution; the unresolved questions concern its reliability, prevalence, and comparative cost. Familiar work may become cheaper and more repeatable while defenders still have to decide which signals matter and act in time. The Delegation-and-Consequence Lens makes that comparison concrete: identify the work delegated, test the measurable change against evidence, and distinguish a capability gain from an outcome that has actually changed. The next question is what happens when defenders use the same capacity to make their own information and decisions more useful.