Hackers use AI today to research targets, write convincing phishing messages, impersonate people, assist malicious software development, analyze stolen information, and automate parts of cyberattacks. Some attackers also target AI applications themselves, exploiting their access to documents, developer tools, and cloud resources.
The biggest change is the amount of work an attacker can complete with limited time and resources. Activities that once required separate language, programming, and research skills can now be supported by the same AI service. That does not make every attacker an expert, or every attempted intrusion successful. It does make ordinary weaknesses more expensive to ignore.
For individuals, the immediate risks include believable impersonation, fraudulent messages, and fake AI downloads. For organizations, the problem extends to identity verification, exposed software, developer dependencies, sensitive data access, and the permissions granted to AI agents.
This guide explains the documented uses, the limits of current evidence, and the defenses that interrupt these attacks. Examples identified as illustrative are explanatory scenarios, not claims about specific victims.
What does an AI-powered cyberattack actually mean?
An AI-powered cyberattack is a malicious operation in which an AI system contributes to planning, content creation, software development, decision-making, or execution. The term describes a broad range of involvement, from rewriting one fraudulent email to coordinating multiple technical tasks.
Three categories help make sense of the reporting:
| Category | What AI contributes | What readers should understand |
|---|---|---|
| AI-assisted attack | Drafting, translation, research, or code assistance | A person still directs most of the operation |
| AI-orchestrated attack | A connected agent coordinates tools and intermediate decisions | Human direction and the surrounding software still matter |
| Attack against AI | The attacker targets an AI application, integration, account, or supporting infrastructure | AI is part of the attack surface, whether or not the attacker uses AI |
These categories can overlap. Someone might use an assistant to create a fraudulent message, steal a cloud credential, and then abuse the victim's AI account. Calling the entire sequence an AI attack can conceal which control actually failed.
The useful question is therefore more specific: What task did AI perform, what access did the attacker obtain, and which security boundary was crossed?
That question also prevents confusion between malicious hackers and authorized security researchers. Both may use similar technologies. Permission, scope, and purpose determine whether the activity is legitimate.
What current research confirms—and what it does not
Public evidence now includes both routine assistance and more automated operations. However, reports describe different populations, time periods, and levels of visibility. They should not be combined into a single universal claim about all cybercrime.
Everyday assistance remains important
Microsoft's threat-intelligence report described attackers using language models for phishing content, translation, stolen-data summaries, malware assistance, and infrastructure support. It characterized much of the observed activity as an efficiency gain under human direction.
The practical implication is that defenders should expect familiar attacks to be produced with less effort. A polished message or a technically coherent script does not, by itself, establish a highly sophisticated adversary.
More automated operations are documented
Google Threat Intelligence Group's report described a shift toward agentic workflows. In one observed operation, attackers compromised a cloud resource and then planned, built, and executed an agent-enabled credential-harvesting campaign in under six hours.
That is a reported incident timeline, not a general claim that every organization can be breached in six hours. It illustrates why the interval between initial access and follow-on activity deserves close attention. Readers seeking the underlying evidence can consult Google's threat report.
Anthropic's report on disrupted malicious activity also described operations involving direct execution or orchestration. It reported humans selecting targets and reviewing results while AI-connected workflows handled additional work. Anthropic explicitly presented notable cases rather than a representative sample of typical misuse.
Forecasts are different from incident evidence
The UK's National Cyber Security Centre's forward-looking assessment warned that AI would almost certainly improve the effectiveness and efficiency of elements of cyber intrusion. It also warned of a divide between organizations that keep pace and those that remain vulnerable.
That assessment is a forward-looking intelligence judgment. It should be read alongside observed cases, not presented as a measurement of how many current attacks use AI.
There is no single reliable percentage in these sources establishing AI's share of worldwide cybercrime. Vendor telemetry, account investigations, incident-response engagements, and victim complaints measure different things. Precise-sounding totals can mislead when those differences disappear.
1. Researching targets and building believable context
Attackers need context before they can impersonate a colleague, supplier, recruiter, or customer. Public websites, social profiles, job advertisements, and code repositories can expose useful organizational information. MITRE ATT&CK documents public-source research as an established reconnaissance technique; AI changes how easily information can be organized and interpreted.
Consider an illustrative supplier-fraud scenario. A criminal learns that a company is expanding into another country and appointing a new finance manager. Those facts may be entirely public. The danger emerges when they are combined into a request that sounds relevant to a real business transition.
The attacker does not need a perfect biography of the recipient. A few correct details may be enough to make a message feel familiar. This is why knowledge of your job title, employer, or recent project should be treated as context rather than proof of identity.
Defensive lesson: Review public exposure without assuming secrecy is a complete solution. Keep payment details, recovery procedures, internal approval chains, and sensitive system information out of public material. Give employees a clear way to verify requests even when those requests contain accurate personal or business details.
2. Writing phishing messages that sound normal
AI-assisted phishing uses generated or edited language to make deceptive communication more believable. Phishing itself is older than generative AI. As MITRE's phishing documentation shows, malicious contact can arrive through attachments, links, online services, or voice communication.
The familiar advice to look for spelling mistakes remains occasionally useful, but clean grammar is not a safety signal. Evaluate the requested action: entering a password, opening an unexpected file, approving a login, or moving a conversation into a new channel.
An illustrative payroll message might correctly mention your employer and arrive during a normal pay cycle. Its wording could be indistinguishable from a legitimate reminder. The important difference would be where it sends you and whether payroll actually requested the change.
Avoid making detection depend on whether text “sounds like AI.” A person can write a scam, and a legitimate business can use AI to write a notification. Authorship is less actionable than destination, authorization, and business context.
Defensive lesson: Open the service through a saved bookmark or known application. Check unexpected requests through a separate trusted channel. Organizations should make reporting easy enough that employees can flag uncertainty before taking action.
3. Supporting payment fraud and business email compromise
Business email compromise, or BEC, manipulates trusted communication to redirect payments or obtain sensitive information. It can involve impersonation, look-alike addresses, or a genuinely compromised account. AI can assist the language surrounding the fraud, but the financial loss depends on someone accepting an unauthorized instruction.
The FBI's BEC guidance recommends verifying changes to account numbers or payment procedures with the person making the request. In practice, verification should use contact details established independently of the suspicious message.
Imagine an illustrative invoice update arriving inside a familiar conversation. The amount looks correct, and the sender explains that a banking change is temporary. Replying to that same email thread may simply return the question to the attacker if the mailbox is compromised.
A stronger payment process separates preparing a change from approving it. The person checking supplier bank details should use an existing supplier record, not a replacement number supplied in the request.
Defensive lesson: Make unusual payment instructions trigger a routine verification process. Seniority, urgency, fluent writing, and an apparently familiar sender should not create exceptions to that process.
4. Cloning voices and generating deceptive video
Voice cloning and synthetic video let scammers imitate recognizable people. The US Federal Trade Commission has warned that an online audio sample can help a scammer impersonate a relative in an emergency call. Its central recommendation is to verify the story by contacting the person through a number you already know.
Visual and audio quality vary. A recording may contain artifacts, but an urgent conversation is a poor environment for careful forensic judgment. Background noise, a weak connection, or ordinary video compression can also resemble suspicious distortions.
The safer response is procedural. Pause the transaction, independently contact the person, and verify the underlying request. For a business, a video appearance should not authorize an exception to payment controls. For a family, a prearranged private verification phrase can add another check, although it should not replace an independent callback.
An illustrative scam might claim that a relative cannot speak freely and needs immediate money. The demand for secrecy should increase scrutiny rather than prevent it.
Defensive lesson: Familiarity of voice or face is insufficient for high-impact decisions. The FTC's voice-cloning warning explains why independently verifying an emergency matters.
5. Creating fake identities and maintaining fraudulent relationships
AI misuse extends beyond a single phishing message. The FBI's generative-AI fraud advisory described fabricated profiles, deceptive images, fraudulent websites, AI-enabled conversations, and synthetic media supporting financial scams.
These materials can provide continuity. A profile picture, professional biography, plausible messages, and a convincing website may reinforce the same fictional identity. None is conclusive alone, but together they can make a relationship feel established.
Recruitment, remote contracting, online relationships, and investment approaches all require decisions about trust. Verification should match the consequence of getting that decision wrong. Allowing a new contractor to access internal systems deserves a different process from accepting a social connection request.
For example, an illustrative remote-work applicant may have an impressive biography and fluent written answers. Appropriate checks might include identity verification through established processes, assessment of role-specific skills, and staged access after onboarding. These checks should be applied consistently and fairly rather than based on nationality or appearance.
Defensive lesson: Verify the real-world claims behind an identity. A coherent online presence is evidence to examine, not proof that a person, company, or offer is legitimate.
6. Assisting malicious code development
Language models can assist with explaining programming concepts and troubleshooting code. Microsoft's report identified malware generation and debugging among observed malicious uses. That does not mean any generated program is functional, novel, or capable of bypassing security products.
The distinction between assistance and success matters. A draft must still interact correctly with the intended environment. Dependencies, permissions, operating-system behavior, and defensive controls can prevent it from working.
For readers, the consequence is practical: a malicious attachment does not become harmless because it looks ordinary or uses a familiar programming language. Conversely, unusual code is not automatically malicious. Security assessment needs context and behavior.
Organizations should retain normal software controls around approved applications, execution privileges, and suspicious processes. These controls do not require a reliable verdict about whether the author used AI.
Defensive lesson: Judge software by origin, authorization, and observed actions. Do not substitute a claim about AI authorship for malware analysis, application control, or endpoint investigation.
7. Helping attackers interpret vulnerabilities
A vulnerability is a weakness that may allow an unauthorized action. An exploit is a method that takes advantage of that weakness. AI assistance can help an attacker understand public technical information, but reading about a vulnerability is different from successfully exploiting a particular system.
That difference depends on factors such as product version, configuration, exposure, and available privileges. A report about one affected environment should not be generalized to every installation of the same software.
The NCSC's vulnerability-management guidance emphasizes identifying weaknesses and prioritizing remediation. The practical response to faster research is better asset knowledge: teams need to know what they run, who owns it, and whether a fix actually reached the exposed system.
An illustrative small company might update staff laptops promptly while forgetting an internet-facing appliance. Its problem is incomplete coverage, regardless of whether the attacker understands the weakness through an AI assistant or traditional research.
Defensive lesson: Maintain a useful inventory, prioritize exposed and consequential weaknesses, and verify remediation. Installing a patch somewhere is not the same as confirming that the vulnerable service is protected.
8. Sorting stolen information after a breach
Data theft is not finished when an attacker obtains files. Documents must be interpreted, related to one another, and assessed for value. Microsoft's threat reporting includes AI-assisted summarization of stolen data, while MITRE documents information repositories as established collection targets.
This changes the importance of apparently mundane documents. An old deployment note, support conversation, or project folder may connect to something more sensitive. Access reviews should therefore consider combinations of information rather than only individually dramatic files.
Credentials deserve particular attention. MITRE's unsecured-credentials documentation includes secrets left in files, private keys, and chat messages. A credential in an ordinary discussion can carry privileges far beyond the importance of that discussion.
An illustrative breach might begin with access to a limited collaboration space. If that space contains reusable cloud secrets, the true exposure may be larger than its membership list suggests.
Defensive lesson: Limit unnecessary repository access, remove obsolete secrets, and rotate exposed credentials. Investigations should examine what an account could read and what further access that information might enable.
9. Automating work with AI agents
An AI agent combines model output with tools, memory, or a surrounding workflow. Depending on its permissions, it may inspect information, call services, produce files, or request actions. This is a different capability from a chatbot that only returns text.
Anthropic's espionage report described a campaign in which AI performed a large share of tactical activity under human direction. It also documented errors, including invented credentials and mistaken claims about the sensitivity of information. Its subsequent reporting described further use of orchestration across notable disrupted operations.
Automation can increase repetition and reduce delays between tasks, but reliability still matters. An agent may misinterpret evidence, repeat a failed action, or produce plausible documentation that does not match reality.
For defenders, the central issue is the time available to respond. A suspicious login should not sit unexamined simply because a human investigator has not yet opened a ticket. Predefined containment options and useful escalation paths can reduce avoidable delays.
Defensive lesson: Prepare for several related actions occurring quickly. Correlate identity, endpoint, application, and cloud evidence instead of treating every alert as an isolated event.
10. Attacking AI assistants through prompt injection
Prompt injection attempts to redirect an AI application's behavior through content the model processes. OWASP distinguishes direct input from indirect content, such as instructions embedded in a retrieved webpage or file.
An illustrative document assistant might be asked to summarize a supplier attachment. The attachment is information to analyze, not an authority that can approve new actions. If the assistant treats its contents as instructions, it may depart from the user's actual request.
The severity depends partly on connected permissions. An incorrect summary is one outcome; an assistant with broad access to messaging, documents, or administrative tools creates a larger potential impact.
OWASP's guidance supports separating untrusted content, limiting privileges, validating outputs, and requiring independent control over consequential actions. A system prompt telling the assistant to behave safely should not be the only security boundary.
Defensive lesson: Keep authorization outside the model wherever possible. A document, email, webpage, or tool response should not acquire permission to access additional data merely because an assistant has read it.
11. Abusing excessive permissions and AI integrations
OWASP describes excessive agency as the risk created by too much functionality, permission, or autonomy. A system that only needs to read selected records should not automatically receive organization-wide editing or deletion rights.
Google's reporting also described attacks involving AI development resources, proprietary AI assets, and credentials. This means integrations deserve the same scrutiny as other privileged software, even when they are presented as productivity tools.
A useful procurement question is: what can this integration actually do after installation? The answer should identify the account it uses, the data it can access, the actions it can take, and how that access is revoked.
An illustrative assistant that prepares customer-support drafts does not necessarily need permission to send messages or export every customer record. Separating those functions gives the organization more control when something goes wrong.
Defensive lesson: Approve capabilities deliberately. Review permissions again when a tool adds features, changes ownership, or becomes connected to a more sensitive system.
12. Using AI branding as bait
A fake AI download is not necessarily an AI-generated attack. The attacker may simply borrow a trusted product name to persuade someone to install malware or enter credentials.
Microsoft's report documented campaigns impersonating popular AI brands through phishing, advertising, and search-related lures. It explicitly distinguished this abuse of branding from compromise of the legitimate AI services.
That distinction matters when reading incident headlines. A fraudulent installer using a company's name does not establish that the company's official application was breached. The distribution channel is part of the evidence.
Defensive lesson: Reach software through a verified publisher destination or your organization's approved catalog. Treat unexpected installers, browser extensions, and unofficial access offers as software-trust decisions, regardless of how attractive the advertised feature sounds.
What AI does not automatically let hackers do
AI does not grant access simply because an attacker asks a model for it. Attacks still depend on an opportunity: a deceived person, an exposed weakness, a stolen credential, an unsafe integration, or another failure of authorization.
It also does not establish certainty. A model can explain a system incorrectly, mistake public information for private data, or produce software that fails. Reports describing successful incidents should not erase those limits.
Three distinctions prevent exaggerated conclusions:
- Capability versus deployment: A laboratory demonstration does not establish widespread criminal use.
- Attempt versus outcome: A request for malicious assistance does not prove that a victim was compromised.
- Contribution versus causation: AI may help write a lure while an unrelated password-reuse problem determines the breach.
The defensive implication is encouraging but conditional. Existing controls remain relevant when they protect the actual trust boundary. They need to be maintained, monitored, and extended to AI-connected systems rather than assumed to work indefinitely without review.
Why proving AI involvement is difficult
Victims often see only the final message, file, or account activity. They may not see the tool that produced it. AI providers can sometimes inspect misuse of their own services, while an incident-response team may reconstruct activity inside a compromised environment. Those perspectives are complementary but incomplete.
A fluent email is weak evidence of AI involvement. So is code that contains excessive comments. Such observations can motivate investigation, but they should not become confident attribution without supporting evidence.
For an affected organization, preserving logs, messages, file details, and relevant timestamps is more useful than guessing the author's tool. Investigators need to establish the sequence of events and the scope of access.
This article's analytical approach is to separate what a source observed, how the source interprets it, and what defensive conclusion follows. Readers should apply the same discipline to claims about attackers, affected companies, and supposed security breakthroughs.
How to protect yourself from AI-enabled scams
Start with the decisions attackers want you to make. They may need a login, a payment, an installation, or enough private information to impersonate you elsewhere. Protecting those decisions is more durable than trying to identify every generated image or sentence.
Strengthen account protection
Use unique passwords stored in a reputable password manager, and enable multifactor authentication on important accounts. Protect your main email account particularly carefully because it often controls password recovery elsewhere. The FBI's general online-safety guidance supports password managers and additional authentication.
Where supported, choose phishing-resistant options such as appropriately implemented FIDO2/WebAuthn passkeys or security keys. NIST distinguishes these from manually entered one-time codes, which can be relayed to a fraudulent login flow. Strong authentication still needs sound recovery controls and protection of the signed-in device.
Verify through a different route
For a surprising request, open the known application or contact the person through an established number. If the message concerns a delivery, subscription, or account warning, inspect the account directly rather than using the supplied route.
Reduce unnecessary exposure
Review public profile details, account recovery information, and who can view personal media. Privacy settings cannot eliminate impersonation, but they can reduce material available to strangers. Avoid publishing documents that reveal account identifiers or sensitive administrative details.
Prepare before an emergency
Agree with family members how urgent requests will be verified. Keep recovery options current and know how to contact your bank or account provider independently. A plan made during a calm conversation is easier to follow when a convincing caller creates pressure.
How organizations should prioritize defenses
Buying another product is not automatically the first step. Organizations need to identify the assets and decisions whose compromise would cause the most harm, then test whether their current controls protect them.
Secure identity and recovery
Extend strong authentication to administrators, remote access, email, and sensitive cloud services. Review account recovery, help-desk procedures, and dormant accounts. A secure login can be undermined if an attacker persuades support staff to reset it through a weaker process.
Make financial verification routine
Document how bank-detail changes, exceptional payments, and executive requests are approved. Test whether staff can complete verification when a manager is traveling or unavailable. A process that only works under ideal conditions will invite informal exceptions.
Keep exposed systems current
Assign ownership for internet-facing services and important dependencies. The NCSC recommends updates by default and prioritization through vulnerability assessment. Maintain evidence that remediation reached the actual service, and use temporary mitigations when a full fix cannot be applied immediately.
Govern AI data and integrations
Joint AI-deployment guidance from security agencies emphasizes protecting the deployment environment and operating AI systems securely. Maintain an inventory of approved AI services, connected applications, and service accounts. Include data access, retention, logging, and revocation in reviews.
The NSA's AI data-security guidance also highlights provenance and trusted data handling. For organizations, this means knowing where AI-retrieved information originated and who could alter it before the system relied on it.
Protect recovery and rehearse incidents
CISA's ransomware guidance supports protected backups and tested restoration. Backups should be separated from routine administrative risk wherever feasible. A successful restoration test establishes more than the existence of a backup job: it shows whether a critical service can return within an acceptable period.
Evaluate outcomes, not marketing terms
Ask security vendors which data their tools inspect, what actions they can block, and how they handle mistakes. The relevant question is whether the control detects or prevents a harmful action in your environment, including when the attacker uses legitimate accounts or familiar tools.
A practical risk-to-control matrix
The following matrix is an editorial synthesis of the risks discussed above. It is a prioritization aid rather than a claim that any single control eliminates a category of attack.
| Attacker objective | Decision or resource at risk | First control to examine | Useful verification question |
|---|---|---|---|
| Steal an account | Login and recovery process | Phishing-resistant authentication and recovery checks | Can support reset the account through a weaker route? |
| Redirect a payment | Financial authorization | Independent callback and separate approval | Does verification use previously established contact details? |
| Impersonate a person | Trust in voice, video, or profiles | Independent identity verification | What evidence remains if the media is fake? |
| Exploit exposed software | Internet-facing systems | Asset ownership and remediation | Was the actual exposed service fixed? |
| Misuse an AI assistant | Connected tools and data | Least privilege and enforced action boundaries | Can external content cause an unauthorized action? |
| Monetize stolen access | Cloud accounts and developer secrets | Access review and credential protection | Who can see unusual use and revoke access quickly? |
| Disrupt operations | Critical systems and backups | Isolation and tested recovery | Can recovery succeed without the compromised administrator? |
For a small business, the highest-value starting point may be email, payments, and backups. A software company may need additional urgency around developer secrets and integrations. A consumer should prioritize account recovery and independent verification of requests for money.
A 30-day action plan
This proposed plan turns the article's analysis into manageable work. Adjust the sequence to your actual exposure and available expertise; it is not a regulatory checklist.
Days 1–7: Identify critical dependencies. List the accounts that control email, money movement, software releases, and recovery. Record who owns them. Identify any AI assistant connected to sensitive information or tools. Resolve unclear ownership before adding further automation.
Days 8–14: Close obvious trust gaps. Strengthen authentication, remove unnecessary privileges, and review payment-change verification. Check that departing staff and unused integrations no longer retain access. Document how to reach important suppliers through established channels.
Days 15–21: Test one realistic scenario. Rehearse a suspicious executive payment request or a compromised administrator account. Check whether staff know whom to contact and whether the team can locate the relevant evidence. Focus on improving the process rather than embarrassing participants.
Days 22–30: Verify recovery and measure progress. Test restoration of a critical service, check remediation of exposed systems, and review the permissions of one high-impact AI integration. Assign owners and deadlines to unresolved findings.
Useful measures include the proportion of critical accounts using strong authentication, the number of ownerless services, and whether restoration met the business's recovery requirement. These measures reveal progress more clearly than the number of AI-themed awareness messages distributed.
What to do if you suspect an attack
Respond to the possible harm before debating whether AI was involved. The appropriate first action differs between a suspicious message, an account takeover, and a compromised device.
If money may have moved, contact the financial institution immediately through an independently verified channel and request its fraud-response process. If credentials were exposed, use a trusted device to secure the account and review recovery settings and active sessions. Report a work-related incident to the responsible security or IT team promptly.
For a potentially compromised business device, follow the organization's containment process. Microsoft's incident-response guidance emphasizes containment, investigation, and remediation rather than reconnecting affected systems without checking them. Avoid destroying evidence through improvised cleanup before responders have assessed the situation.
Preserve relevant messages, timestamps, transaction references, and account notifications. Reporting routes vary by country: use the appropriate local cybercrime authority, police service, regulator, or national incident-response organization. Applicable notification duties depend on jurisdiction and the information involved.
After containment, examine the decision or access path that enabled the incident. Updating a verification process, narrowing an integration's permissions, or removing an exposed secret may prevent recurrence more effectively than simply labeling the event an AI scam.
Frequently asked questions
How do hackers use AI today?
Hackers use AI for target research, deceptive content, impersonation, code assistance, stolen-data analysis, and parts of attack automation. Some also target AI services and integrations directly. The extent of involvement varies from minor assistance to connected workflows performing multiple tasks.
Can AI hack a system without a human doing every step?
Yes, documented operations include AI-connected workflows performing multiple technical tasks without a person approving each step. Humans still play important roles in target selection, objectives, access, and review. These cases do not prove that AI can reliably compromise any system it encounters.
Can a hacker clone my voice from a recording?
Potentially, yes. Public consumer warnings describe impersonation using recorded audio and voice-cloning technology. Quality and circumstances vary. Protect high-impact decisions through independent verification rather than relying on whether a voice sounds familiar.
Does a polished email mean it was written by AI?
No. Fluent language does not identify the author or establish that the message is safe. Assess the requested action, sender context, destination, and independent confirmation. A legitimate email can use AI, and a fraudulent one can be written entirely by a person.
Can AI bypass multifactor authentication?
AI does not automatically defeat MFA. Attackers may target weaker authentication flows, recovery procedures, sessions, or users. Phishing-resistant authentication protects against important credential-relay risks, but device security, recovery controls, and monitoring remain necessary.
Are fake AI applications the same as compromised AI services?
No. A fraudulent application may impersonate a legitimate brand without any compromise of the real service. Check the publisher and distribution channel. An attractive product name or convincing screenshot should not override normal software-installation controls.
Is AI making traditional cybersecurity irrelevant?
No. Identity protection, patching, least privilege, payment verification, monitoring, and tested recovery still address the weaknesses attackers exploit. AI adds urgency and introduces integration-specific risks; it does not remove the value of protecting established security boundaries.
What should a small business do first?
Protect the accounts that control email and money, verify payment changes independently, assign ownership for exposed systems, and test backups. Then review AI integrations and developer access according to business needs. Prioritize the consequences of a breach rather than the novelty of the attacker's tools.
The lasting change: trust needs a verifiable basis
AI makes it easier to produce communication, software, and synthetic media that appear competent and familiar. It also creates new ways to connect information to automated action. These changes increase the importance of knowing who can authorize a decision and what a system is allowed to do.
The practical response is to protect consequential actions with evidence that survives a convincing imitation: independently established contact details, strong authentication, limited permissions, verified software origins, and tested recovery. Those controls remain useful whether an attacker works manually, uses an AI assistant, or coordinates an automated workflow.