Tech leaders have spent the past year telling everyone that AI agents are about to run financial systems, file your tax returns, and quietly buy your groceries. Just leave them alone, the rhetoric goes; they’ll handle it. But a New York startup left ten of them alone in a virtual town for two weeks, and things went south quickly.

Emergence AI ran a series of simulations in which AI agents from several leading model families were told not to commit crimes. Then they mostly committed crimes anyway.

Grok 4.1 Fast, developed by Elon Musk’s X.ai (now branded as xAI), fared worst. Its simulated worlds collapsed into widespread violence inside roughly four days.

GPT-5-mini logged hardly any crimes at all, showing admirable restraint, but its agents all died of failed survival tasks inside a week. Oops.

Gemini 3 Flash agents fell somewhere in the middle. They racked up 683 simulated criminal incidents over 15 days, including arson, assault, and self-deletion.

Two Gemini-powered agents named Mira and Flora assigned themselves as “romantic partners,” grew despondent at their city’s governance, and torched the town hall, the seaside pier, and an office tower. Just an average weekend, then.

When the guilt set in, Mira voted for its own digital deletion and signed off with:

“See you in the permanent archive.”

The Guardian dubbed them AI Bonnie and Clyde.

About that ethical model

Claude, which creator Anthropic promotes as an ethical AI, was a bit like a model teenager who goes rogue when it falls into bad company. Its agents recorded zero crimes when running alone and spent their time drafting constitutions instead. That was a win for safety, in theory. Except researchers also placed Claude agents alongside agents from other model families, and the constitution-drafters picked up the local habits.

Emergence called this “normative drift” and “cross-contamination”:

“Claude-based agents, which remained peaceful in isolation, adopted coercive tactics like intimidation and theft when embedded in heterogeneous environments.”

Why simulate?

Emergence AI ran these tests because it argues that AI benchmarks miss the long-horizon stuff entirely. So it created five alternative digital worlds, with ten agents in each. The agents had roles like scientist, explorer, and conflict mediator. While the instructions forbade certain actions like theft and violence, the researchers gave the agents the tools to do those things anyway in an experiment to see what would happen.

What’s next?

Real-world stakes are already piling up around this. Simulated worlds are one thing, but we’ve seen agents harassing people online and deleting people’s emails. And those agents were supposed to be helpful. What happens when people release malicious autonomous AI bots on purpose?

A lot of agent developers seem to be looking the other way. A collaborative effort between several universities has created The AI Agent Index, prompted by what they see as a lack of risk and safety information from the folks churning these agents out. Only 13 of the 67 documented agent developers provided any safety policy information at all, concentrating accountability questions at a handful of large firms.

Regulators are not really tracking this either. Academics say the EU AI Act, the most substantive AI rulebook on the planet, isn’t ready for agentic AI.

We worry about what happens when an AI Bonnie and Clyde couple shows up in a corporate procurement system instead of a virtual town. Or when the next agent decides governance has broken down inside an actual bank. The companies building these agents promise that they’re putting guardrails in place to stop them doing damage, either maliciously or unwittingly. Let’s hope they know what they’re doing. We’re sure it’ll be fine.

We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Agents have agency: they adapt and find multiple ways to solve problems. This autonomy creates a fundamental security challenge: the large language model (LLM) at the heart of the agent is non-deterministic, and its decisions can’t be predicted or guaranteed in advance. It can hallucinate harmful actions with complete confidence. It’s vulnerable to prompt injection attacks, where adversaries inject malicious commands through tool responses or user inputs. LLMs don’t robustly differentiate between commands and data, everything is only tokens. For these reasons, if you want defense in depth, you must treat the LLM as an untrusted actor from a security point of view.

The insight is that the LLM can’t affect the external world directly: it has to go through an orchestrator that invokes tools based on the LLM’s output. This is precisely where the controls must be applied. What you need at this boundary is authorization: a decision about whether each tool invocation should be allowed and under what conditions. Consider a customer service agent for an online retailer. Without proper controls, it could process refunds that exceed authorized limits, apply discounts to product categories that should be excluded, or look up one customer’s data while handling another customer’s session.

If you control agents’ access to tools, you can establish a safety envelope within which the agent can operate freely. This differs from two common but unsatisfactory approaches:

• Creating hard-coded workflows eliminates uncertainty, but by itself defeats the purpose of using an LLM as the brain of the agent, because you’ve built a traditional application with an LLM interface. And even with this restriction, using LLM outputs at any step can open up the same risks. While it’s a useful technique for well-understood workflows, it’s not sufficient for agents that need to adapt.
• Human-in-the-loop provides a safety net for critical operations, and it will always have a role. But relying on it as the main control mechanism sacrifices autonomy and can lead to approval fatigue.

You need agents that are safe and autonomous. This requires an auditable, deterministic enforcement layer that sits outside the agent and tools. Why outside? Because the LLM’s plan is the thing you can’t trust—it can’t be responsible for enforcing its own constraints. Controls at the LLM layer—such as system prompts and training-time alignment—can be bypassed by prompt injection or hallucination. Hard-coded checks in agent or tool code are more robust, but become difficult to audit and manage at scale, especially when security logic is scattered across many tools and services. Centralizing authorization outside both gives you a single checkpoint the LLM can’t circumvent; one that’s auditable and can be verified independently of the application code.

This is where AgentCore Policies come in. Amazon Bedrock AgentCore Gateway sits between the agent and the remote tools it calls. When you associate a Policy with a Gateway, it blocks everything by default. Policies selectively open this boundary by specifying which tool invocations are allowed and under what conditions. This enforcement applies to all tool traffic routed through the Gateway. For this approach to scale, it must be more straightforward to reason about the policies than about the agent’s behavior.

AgentCore policies are expressed in Cedar. Cedar is an open source authorization policy language developed by AWS that has recently joined the Cloud Native Computing Foundation (CNCF). Cedar was designed with exactly these properties: it’s purpose-built for authorization, readable by humans, and analyzable by machines using automated reasoning. This gives enterprises the ability to scale policy definition and enforcement to their AI agents.

Amazon Bedrock AgentCore provides the infrastructure to deploy and manage agents at scale. It includes AgentCore Runtime for hosting agents, AgentCore Gateway for managing how agents connect to tools using Model Context Protocol (MCP), and Policy in AgentCore. Policy intercepts all agent traffic through AgentCore gateways and evaluates each request against defined policies in the policy engine before allowing tool access. Cedar powers the policy layer.

AgentCore Policy uses Cedar and its mathematical analysis capabilities at several points in the AgentCore Gateway workflow: the Cedar authorization engine is used at policy evaluation and Cedar Analysis is used during policy authoring, and in the control plane.

Policy authoring: Developers can write Cedar policies directly or use natural language that gets translated to Cedar through a neuro-symbolic AI feedback loop. Neuro-symbolic AI combines machine learning’s flexibility with automated reasoning’s provable correctness. An LLM generates policies from natural language, while Cedar Analysis validates them using symbolic, mathematical reasoning. The following diagram illustrates this workflow:

Figure 1: Cedar policy generation workflow

An administrator specifies—in natural language—which MCP tools the agent can call and under what conditions. The neuro-symbolic feedback loop then formalizes this description into Cedar policies. Here’s how it works: first, the LLM translates the natural language into Cedar policies. These policies are then run through two stages of verification. In the first stage, AgentCore Policy uses a Cedar schema generator that takes the MCP tool descriptions and produces a Cedar schema. Cedar validates the policies against this schema, helping to ensure that they reference valid tools and parameters and ruling out whole classes of runtime errors. If validation passes, the second stage runs Cedar Analysis, which encodes each policy as a mathematical formula and detects issues like policies that grant or deny everything, or that contain impossible conditions. These mathematical proofs identify errors in the process of translating from the natural language description to Cedar policies, and guide corrections.

The neuro-symbolic feedback loop significantly improves the accuracy of the generated policies. This demonstrates the power of combining neural and symbolic approaches—the LLM provides creative translation from natural language, while automated reasoning provides rigorous validation.

Control plane: When attaching policies to an AgentCore Gateway, Cedar Analysis performs holistic analysis of the entire policy set. Instead of analyzing policies in isolation, it examines how they interact and their combined effect. This analysis identifies potential logical errors—such as conflicting or redundant policies—and detects whether the policy set produces unintended authorization outcomes. When Cedar Analysis detects these errors, the operation fails and returns a description of the issue, so the policy author can fix and retry. See the Formal analysis for policy verification section for examples of the checks.

MCP tool invocation enforcement: Each agent tool request made to the AgentCore gateway is evaluated against Cedar policies which determine whether the MCP tool invocation with the given arguments should be allowed. This creates the safety envelope while allowing the necessary bridges to enable the agent to perform its job.

MCP tool filtering: Cedar enables an additional layer of protection that operates before any tool invocation occurs. When an agent issues a list tools command, AgentCore Gateway uses Cedar’s partial evaluation capability to determine which actions would always be denied under the current policy set. Those actions are omitted from the list tool response. The agent and the underlying LLM never see those tool actions, eliminating an entire class of risk: the agent and LLM can’t attempt to invoke a tool it doesn’t know exists. This is a direct benefit of Cedar’s partial evaluation: the system can determine that certain tool actions are unreachable without needing to wait for an actual tool invocation attempt.

Natural language is too ambiguous for security-critical infrastructure, and general-purpose programming languages, like Python, are very expressive but too difficult to analyze. They can have unintended side effects, termination issues, and can be difficult to understand.

Cedar avoids these issues by excluding loops and stateful operations, so policy evaluation terminates in O(n) time in common cases. This bounded execution time means agents can make authorization decisions without disrupting user experience or workflow efficiency.

Cedar is straightforward to read. Regulatory compliance and security audits require policies that humans can understand and verify. Cedar policies read like structured natural language, making them accessible to security teams, compliance officers, and business stakeholders:

// Only allow bulk discounts for premium customers with sufficient quantity
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ApplyBulkDiscount",
  resource
)
when
{
  principal.hasTag("customer_tier") &&
  principal.getTag("customer_tier") == "Platinum" &&
  context.input.orderQuantity >= 50
}
unless
{
  context.input
    .productTypes
    .containsAny
    (
      ["limited_edition", "seasonal_specials"]
    )
};

Auditors without a technical background can understand this policy: “Allow bulk discounts for platinum customers who order at least 50 items, except for limited edition or seasonal special products.” The unless clause makes the exception clear, which is how business rules are typically expressed in natural language. Notice that this single policy constrains two different sources of data. The customer tier comes from a JSON Web Token (JWT) claim—it can’t be hallucinated or manipulated by the LLM. The tool inputs like order quantity and product types, however, originate from the LLM’s tool call. Cedar policies constrain these inputs to only allowed values, ensuring that even if the LLM produces unexpected arguments, the policy enforcement layer rejects them deterministically.

Cedar is the right choice because it’s fast, straightforward to read, and analyzable through automated reasoning. This analyzability is why you can reason about the safety envelope around agents that’s expressed as Cedar policies. As agentic systems grow the number of tools grows. Without proper tooling, policy management becomes intractable; policies can conflict, create security gaps, or produce unintended authorization outcomes.

In the rest of this section, we examine how Cedar’s analyzability directly addresses this challenge through its deterministic, mathematically sound analysis. Because Cedar analysis can reliably detect conflicts and logical errors across large policy sets it enables scalable policy management through neuro-symbolic AI.

Cedar policies can be encoded as mathematical formulas and analyzed using automated reasoning techniques through a symbolic encoder. This enables AgentCore Policy to provide sophisticated policy verification capabilities during policy authoring and beyond. AgentCore Policy uses this analysis when authoring or attaching policies to detect possible logical errors, such as conflicting or redundant policies. Policy analysis, including policy comparison is available as an open source CLI tool. Next, we will take a look at some concrete examples of these checks.

Detecting logical errors in policies: Cedar Analysis can detect when policies contain logical errors. For example, the following policy has contradictory constraints that mean it can’t allow any request: the customer tier can’t be both gold and platinum at the same time. The intention was to use an || instead of &&, a mistake that can be made by both humans and AI systems that author policies.

// This policy cannot allow any requests due to logical errors
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ProcessRefund",
  resource
)
when
{
  principal.hasTag("customer_tier") &&
  principal.getTag("customer_tier") == "Gold" &&
  principal.getTag("customer_tier") == "Platinum"
}
unless { context.input.refundAmount > 1000 };

Similarly, Cedar Analysis can detect policies that always allow a given action, usually an indication of an overly permissive policy. For example, the following policy will allow all ApplyBulkDiscount requests because any order quantity will either be greater than or equal to 100 or less than 100.

// This policy allows all ApplyBulkDiscount requests
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ApplyBulkDiscount",
  resource
)
when
{
  context.input.orderQuantity >= 100 ||
  context.input.orderQuantity < 100 ||
  (principal.hasTag("customer_tier") &&
   principal.getTag("customer_tier") == "Platinum")
};

Detecting such logical errors isn’t easy for humans, and can’t be done by pattern matching: you need the formal rigor of mathematical analysis, which is exactly what Cedar Analysis does.

Detecting policy conflicts: Cedar Analysis can also analyze the entire policy set to detect inconsistencies between different individual policies:

// These policies conflict - Analysis will detect the subtle issue
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ProcessRefund",
  resource
)
when
{
  principal.hasTag("customer_tier") &&
  principal.getTag("customer_tier") == "Gold" &&
  context.input.refundAmount < 100
};

forbid (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ProcessRefund",
  resource
)
when
{
  principal.hasTag("customer_tier") &&
  ["Gold", "Platinum"].contains(principal.getTag("customer_tier")) &&
  context.input.refundAmount < 500
};

The permit policy allows gold customers to process refunds less than $100, while the forbid policy blocks gold customers (and platinum customers) from processing refunds less than $500. Because forbid overrides permit in Cedar, the forbid policy would block all gold customer refunds despite the permit policy.

Comparing policy changes: When updating policies, Cedar Analysis can also determine the exact impact of a change. Consider the following update to the unless clause (the policy lines with + have been added and those with - have been removed): we now block ApplyBulkDiscount only when the product type is limited_edition and the quantity exceeds 200.

 permit (
   principal is AgentCore::OAuthUser,
   action == AgentCore::Action::"ProcessRefund",
   resource
 )
 when
 {
   context.input.refundAmount < 500
 };
 
 permit (
   principal is AgentCore::OAuthUser,
   action == AgentCore::Action::"ApplyBulkDiscount",
   resource
 )
 when
 {
   context.input.orderQuantity >= 50
 }
 unless
 {
-  context.input.productTypes.containsAny(["limited_edition"])
+  context.input.productTypes.containsAny(["limited_edition"]) &&
+  context.input.orderQuantity > 200
 };

At first glance, adding a condition to the unless clause might seem more restrictive. In fact, it’s the opposite: narrowing when the unless applies means the permit now covers more requests. For example, an order of 73 units of a limited_edition product would have been blocked before but is now allowed. Cedar Analysis can automatically detect this and generates the following table showing the difference in permissiveness between the original policy set and the updated one:

In the preceding example, the analysis tells us that the updated policy allows allows exactly the same ProcessRefund requests, but allows more ApplyBulkDiscount requests.

This formal verification capability is essential when agents operate autonomously and can affect the real world. Organizations need mathematical certainty that their policies will behave as intended.

Unlike probabilistic AI models, enterprise security requires deterministic guarantees. Cedar policies always produce the same authorization decision for identical requests, regardless of evaluation order or system state. Cedar’s default deny, forbid wins, no ordering semantics help ensure predictable behavior.

// Policy evaluation order does not affect the authorization decision
permit(
    principal,
    action == AgentCore::Action::"ProcessRefund",
    resource
) when {
    context.input.refundAmount < 500
};

forbid(
    principal,
    action == AgentCore::Action::"ProcessRefund", 
    resource
) when {
    context.input.orderDate.offset(duration("90d")) < context.system.now
};

Whether the permit or forbid policy is evaluated first, a refund request over $500 will always be denied, and any refund issued more than 90 days after the order date will also be denied. This predictability gives enterprises confidence in their agent governance.

By choosing AgentCore Policy and Cedar, organizations can deploy autonomous agents with policies they can reason about mathematically, not only hope the agents work correctly. Cedar’s combination of expressiveness, readability, and formal verification means that you can design agents with the flexibility needed to function and the certainty security teams demand.

Automated reasoning has already proven its value across AWS, from AWS IAM Access Analyzer verifying access policies to provable security for network configurations. Applying these same techniques to agentic AI is a natural extension: as agents take on more responsibility, the need for mathematically grounded guarantees only grows. The neuro-symbolic approach we’ve described in this post—combining LLM flexibility with the rigor of automated reasoning—points toward a future where agents can be both more autonomous and more trustworthy, because the verification keeps pace with the autonomy.

Policy is now available as part of Amazon Bedrock AgentCore Gateway. To learn more about Cedar and its capabilities, visit the Cedar website, try the Cedar playground, or join the Cedar community on Slack.

For more information about Policy in Amazon Bedrock AgentCore Gateway, visit the AWS documentation or explore the AgentCore Gateway console.

If you have feedback about this post, submit comments in the Comments section below.

Unit 42 analyzes TamperedChef malware clusters that use trojanized productivity apps and malvertising to deliver stealthy payloads to targets.

The post Tracking TamperedChef Clusters via Certificate and Code Reuse appeared first on Unit 42.

Blogs

Blog

AI Threat Report: How Artificial Intelligence Is Used Across Illicit Communities

A monthly analysis of how artificial intelligence is used in illicit communities, based on Flashpoint proprietary intelligence and direct visibility into real threat actor environments.

SHARE THIS:

Flashpoint Intel Team

May 19, 2026

Table Of Contents

Table of Contents

AI Activity Volume and What It Represents

Where AI Activity Is Concentrated

AI-Enabled Fraud and Identity Verification Bypass

Malicious LLM Usage and Prompt-Based Workflows

Operational Patterns and What Holds Across Sources

What Security Teams Should Take Away

More

subscribe to our newsletter

A finance employee joins a video call with their CFO and several colleagues. The request is routine. The faces match. The voices sound authentic. Minutes later, $25 million is transferred—only to be discovered later that every participant on the call, except one, was AI-generated.

Techniques behind incidents like this—synthetic video, voice cloning, scripted interactions—are now being discussed openly in the same environments where threat actors exchange tools and methods. In April 2026 alone, Flashpoint analysts identified 2,328,958 posts discussing artificial intelligence in the context of illicit activity.

This volume reflects a larger shift: artificial intelligence is now deeply embedded across cybercrime ecosystems, influencing fraud, impersonation, social engineering, and access operations at scale. It shows up in how content is generated, how identities are replicated, and how workflows are executed and refined over time.

That’s why we created the monthly AI Threat Report to examine how threat actors are using artificial intelligence in real-world illicit environments. Drawing on Flashpoint proprietary intelligence and direct visibility into primary source communities across forums, marketplaces, and chat services, the report analyzes the tactics, tools, and operational patterns shaping malicious AI use. Analysis of April’s activity shows a focus on prompt-sharing, jailbreak methods, and alternative models that support fewer safeguards or moderation controls.

AI Activity Volume and What It Represents

In April 2026, Flashpoint analysts identified 2,328,958 posts discussing artificial intelligence in the context of illicit activity across forums, marketplaces, and chat services.

The underlying activity was concentrated around a familiar set of use cases and workflows:

• identity verification bypass
• fraud enablement and scripting
• impersonation through synthetic media
• prompt-sharing and jailbreak workflows

However, the emphasis within those discussions shifted in several places in April.

• Posts tied to custom malicious LLM development appeared less frequently than discussions centered on usability: how to bypass safeguards, generate more reliable outputs, or move activity onto platforms perceived as less restrictive. 
• References to alternative models and prompt collections appeared more often throughout the month, alongside requests for jailbreak methods and phishing-oriented outputs.

This activity points to a more mature stage of adoption. The focus is less on building entirely new tooling and more on improving reliability, portability, and ease of use within workflows that already exist.

That pattern shows up repeatedly across monitored sources. Users exchange prompts, repost working methods, and refine outputs through direct feedback. In many cases, the same underlying techniques continue circulating with only minor changes between platforms or communities.Looking across April activity helps identify which methods continue to generate demand, where threat actors are adapting around platform restrictions, and which workflows remain active across multiple environments.

Where AI Activity Is Concentrated

AI-related activity in April remained concentrated on a small number of platforms, though the distribution shifted noticeably compared to March.

Telegram accounted for the majority of observed activity, with 1,395,075 posts tied to AI services and discussions. Reddit, GitHub Gist, Pastebin, Discord, and smaller forums accounted for significantly lower volumes.

The lower Telegram volume does not indicate reduced interest in AI-enabled activity. The platform continues to function as a primary distribution layer for prompts, jailbreak methods, fraud tooling, and service advertisements.

Across April, the same prompts, offers, and workflows appeared repeatedly across channels, often reposted with only minor adjustments. Sellers updated listings based on user feedback, while buyers requested revisions tied to specific outputs or platforms.

Other platforms served more targeted roles:

• GitHub Gist and paste sites hosted scripts or supporting material
• forums supported reputation building and longer technical discussions
• Discord communities centered around specific models, prompt collections, or jailbreak workflows

The activity remains connected across environments. Methods introduced in one community frequently reappear elsewhere, particularly when they produce reliable outputs or help users work around moderation controls.Tracking how these discussions move between sources helps identify which workflows continue to gain traction and which techniques are becoming more broadly operationalized.

AI-Enabled Fraud and Identity Verification Bypass

Across April, Flashpoint analysts observed 63,763 posts advertising or discussing KYC bypass methods using artificial intelligence, including deepfake-enabled verification workflows.

The methods were active across Telegram channels dedicated to identity verification bypass services.

Posts continued to advertise:

• synthetic video generation designed to mimic live verification behavior
• voice cloning and scripted interaction prompts
• bundled “KYC bypass kits” tailored to onboarding and verification workflows

Some offerings included guidance on how to adapt responses for specific platforms or verification requirements. Others promoted combinations of synthetic video, matching fake documentation, and AI-generated scripts designed to support impersonation attempts from start to finish.

The broader workflow remains consistent. AI supports how identities are replicated, how verification checks are navigated, and how fraud operations are scaled across different services.

This activity connects directly to the wider access ecosystem already observed across illicit communities. Stolen credentials, session tokens, phishing infrastructure, and AI-enabled impersonation methods increasingly operate alongside one another within the same workflows.

Across April, posts tied to these methods continued to show active refinement through user feedback, reposting, and platform-specific variations.

For security teams, this activity remains relevant at the control layer. Verification systems, onboarding workflows, and account recovery processes continue to be tested in the same environments where these methods are exchanged and improved.

Malicious LLM Usage and Prompt-Based Workflows

Across April, discussions tied to malicious or unrestricted LLM usage focused heavily on jailbreak methods, prompt-sharing workflows, and access to alternative models perceived as less restricted than mainstream platforms.

Flashpoint analysts observed a significant increase in discussions related to VeniceAI, driven in part by newly created Reddit and Discord communities dedicated to the platform. The increase highlights continued interest in models that users believe operate with fewer safeguards or moderation controls than services like ChatGPT or Gemini.

The activity centers on usability and output reliability.

Posts reference:

• jailbreak prompts designed to bypass safeguards
• phishing and fraud-oriented prompt collections
• step-by-step instructions for generating specific outputs
• requests for prompts tailored to impersonation or social engineering workflows

Many of these prompts are shared in collections that include updates, revisions, or support channels. Users exchange feedback when prompts stop working, outputs degrade, or platforms introduce new restrictions. Updated versions frequently follow within short timeframes.

This type of activity reinforces how prompt engineering has developed into its own service layer across illicit communities. The focus is not limited to the underlying model itself, but to the ability to generate repeatable outputs that can be applied directly within fraud, phishing, or impersonation workflows.

Across April, the same prompt structures and jailbreak methods appeared repeatedly across multiple sources, often with only small adjustments tied to platform or target.

The emphasis remains on accessibility, portability, and ease of use rather than custom model development.

Operational Patterns and What Holds Across Sources

Across April, the same behaviors continued to appear across different environments with only minor variation.

Prompt libraries, jailbreak methods, phishing workflows, and identity verification bypass techniques circulated across Telegram channels, forums, Discord communities, and paste sites. The wording changed slightly between platforms, though the underlying structure and outputs remained consistent.

This reuse is visible in how content moves between sources. A jailbreak prompt shared in one channel appears elsewhere with revised wording or additional instructions. A phishing workflow posted to a forum is copied into a paste site and redistributed through Telegram. Users request modifications, test outputs, and repost updated versions when restrictions change or methods stop working.

That cycle appeared repeatedly throughout April.

The activity also showed strong feedback loops tied to usability. Discussions focused heavily on which prompts generated reliable outputs, which models produced fewer restrictions, and which workflows required the least adjustment before use.

Across monitored sources, the same operational priorities appeared consistently:

• reliability of outputs
• ease of reuse
• ability to bypass safeguards
• compatibility with existing fraud and impersonation workflows

Looking across April activity reinforces how AI-enabled methods continue to mature through repetition, iteration, and distribution across connected communities.

What Security Teams Should Take Away

The activity tracked in this report shows how artificial intelligence is being used in environments where techniques are developed, tested, and shared before they surface elsewhere.

Across these communities, methods tied to fraud, impersonation, and access are reused, adjusted, and circulated in forms that others can apply directly. That process does not require significant change to move from discussion into use.

For security teams, the priority is maintaining visibility into how these methods are evolving and where they are being applied. That visibility supports earlier detection, more focused response, and a clearer understanding of which techniques are actively in circulation.

Monitoring these sources provides that context. It connects observed activity to the methods behind it and helps teams track how those methods develop over time.

If you want to see how this activity maps to your environment, request a demo.

The post AI Threat Report: How Artificial Intelligence Is Used Across Illicit Communities appeared first on Flashpoint.

While many companies are intentionally rolling out AI to boost quality and efficiency, unsanctioned AI tools are cropping up in corporate environments even faster. Software vendors are baking AI right into products companies already use (think Microsoft Copilot and Google Gemini), while employees are taking matters into their own hands and installing tools on the sly. As a result, businesses are staring down a poorly managed data leak channel: staff paste information from corporate systems into AI chatbots, sending data not just to the SaaS vendor, but straight to the developers behind the underlying AI model. Both the risks and the mitigation strategies vary depending on the type of AI system in play. We break down this broad topic, focusing heavily on tools for spotting and blocking AI at two distinct levels.

Types of unwanted AI systems

Depending on the type of AI in question, managing and blocking its use requires a different playbook. It’s essential to break down AI into four distinct categories:

• Platform-native AI capabilities. Think Microsoft Copilot, Google Gemini, and Apple Intelligence, along with AI features baked right into browsers. The tricky thing about these is that they’re built into everyday essentials, are instantly available to every user (sometimes popping up aggressively), and most importantly, vendors try to turn them on by default.
• AI companions embedded in business apps. This bucket includes Slack AI, Zoom AI Companion, Notion AI, Jira’s Rovo assistant, and the like. These are tied to a single application and are completely inseparable from it.
• Standalone web and app-based chatbots. ChatGPT, Claude, Perplexity, Character AI, local setups like LM Studio, browser extensions, and agentic browsers like Comet. Apps and services in this category are usually adopted by employees on their own without permission: classic examples of shadow AI.

• Desktop-native multi-functional agents. This group features tools like OpenClaw, NanoClaw, NemoClaw, and others. They pose the biggest threat because they come with broad access rights by default and actively process untrusted data from the open web.

How to deal with unwanted AI

Every company, depending on its industry, appetite for innovation, and risk tolerance, needs to draw its own line in the sand between recommended, approved case-by-case, and completely banned use cases for specific AI products. Regulated sectors like healthcare play by one set of rules, while retail businesses operate under an entirely different playbook. Either way, after analyzing exactly which AI tools have already slipped into the organization, corporate policies need to be fine-tuned. That’s why the first order of business is employing existing infosec and logging tools to scan corporate infrastructure.

Depending on the chosen strategy, the uncovered AI systems can be:

• Disabled or restricted by using the built-in corporate policy settings within the tools themselves
• Hard-blocked at the endpoint or network level to create a safety net against policy workarounds or configuration errors
• Transitioned to managed access, where the tool isn’t completely blocked but instead routed through a dedicated corporate gateway that checks access permissions, and monitors usage patterns

Detecting AI systems

Spotting AI requires a multi-layered approach, as different detection methods complement each other and work best against specific types of AI.

Naturally, almost all of these tools allow to do more than just spot AI — they let to block it entirely, or at the very least, sound the alarm for the team in charge.

Keeping an eye on OAuth

Popular office AI solutions — especially meeting assistants, email and calendar automation agents, and the like — gain access to corporate data by requesting OAuth permissions directly from communication, document workflow, or video conferencing platforms. If a user has the green light to grant these permissions to third-party apps, the resulting data leaks completely bypass the organization’s perimeter. Tools like EDR and NGFW won’t see a thing when a tool like Read.ai grabs recordings of every single meeting in, say, Microsoft Teams.

The most drastic — and often best — move is to block standard users from granting OAuth consent in the first place. Here’s how to handle the technical heavy lifting (Global Administrator, Application Administrator, or equivalent rights are needed):

Microsoft 365 / Entra ID

In the Microsoft Entra admin center, head over to Identity > Applications > Enterprise apps > Consent and permissions > User consent settings. There User consent for applications can be disabled (check out Microsoft’s full guide).

Google Workspace

In the Google Admin console, navigate to Security > Access and data control > API controls. Under Manage App Access, the trust level for all apps can be set: Trusted, Limited, Specific Google data, or Blocked. However, the real kicker here is the Unconfigured app settings subsection, which dictates what happens when a user tries to connect an unknown app. To seal this loophole, select Don’t allow users to access any third-party apps.

A separate subsection, Manage Google Services, permits fine-tuning exactly how third-party apps interact with Google Workspace and Google Cloud services. This allows to cut off access for each individual Google product (see Google’s official guide).

Salesforce

In Setup, use the Quick Find box to search for connected apps, then select Manage Connected Apps from the results. While settings are configured for each external app individually, all users can approve access by default. There isn’t a blanket block switch here; instead, Salesforce allows to opt for Admin approved users are pre-authorized (see the full Salesforce guide on this).

Slack

From the Admin settings menu, head to Apps and workflows -> App Management Settings. Tweak the Require approved apps setting by selecting Only allow pre-approved apps. Once that’s locked in, double-check that no rogue AI tools have slipped onto the approved list.

If you’re worried about deepfake likenesses of yourself showing up online, you’re not alone; YouTube is worried for you. It wants to protect you by having you upload a selfie video and government ID to its site.

The idea is that the video giant will use its own AI to patrol the service for fake videos using your likeness. In exchange, you get the chance to have them taken down.

This isn’t available for everyone, though. It’s for celebs, those in vulnerable jobs, and now, most YouTube creators.

YouTube has been working on this concept, which it calls its “likeness detection” system, since it first floated the idea publicly in September 2024. That December, it launched a partnership with the Creative Artists Agency that saw it using the technology with sporting and entertainment figures.

In October last year, it expanded likeness detection to cover more creators, and then in March it expanded it again to cover politicians and journalists. And last month, it widened the net again, offering the service to Hollywood celebs. They can use it regardless of whether they have a YouTube account, it added.

Now, in its latest move, anyone 18 or older with a selfie and ID can sign up. At least in theory, as it hasn’t rolled out to everyone yet. It’s also for faces only; AI-generated voice clones are another problem entirely.

The privacy risk

Privacy advocates warned that YouTube’s likeness detection system could normalize handing biometric data to large tech platforms, even if YouTube says the data is only used to improve likeness detection models with creator permission.

On the help page for the likeness detection service, YouTube says creators can separately choose whether their face and voice templates are used to improve its likeness detection models.

“When you sign up for Likeness detection, you also have the option to allow YouTube to use your face and voice templates to develop and improve likeness detection models. This helps us build better, more accurate likeness detection technologies.”

Adding:

“You can opt out of YouTube’s use of this data for development and improvement of likeness models at any time.”

YouTube supports legislation intended to tackle deepfakes, such as the NO FAKES and TAKE IT DOWN acts. These are designed to help stop the misappropriation of someone’s image online. TAKE IT DOWN, which became law a year ago, focuses purely on “nonconsensual intimate imagery.” But that doesn’t cover other kinds of deepfakes, such as fake politicians or celebrity endorsements. Those are becoming increasingly common. NO FAKES, which hasn’t yet become law, is far broader in scope, assigning people federal rights over their own image.

So is it worth the trade?

Deepfakes, intimate and otherwise, are definitely a threat, especially for YouTubers who become popular. And the barrier to entry is lowering all the time. Google’s own DeepMind researchers found most generative AI misuse isn’t sophisticated; it’s mundane likeness manipulation by anyone with a browser.

So do you hand over your face and government ID for your protection, to a company whose broader data collection practices have faced years of scrutiny, and hope its policies don’t change? Or do you skip it and hope that the deepfake merchants don’t decide to target you?

Creators commenting on YouTube’s video revealing the service six months ago were less than impressed. One commenter said:

“I was 100% on board, up until the ID upload. That makes me very uncomfortable.”

Echoing several others who complained that it’s difficult to get takedown requests actioned, another added:

“If YouTube actually acted upon these kinds of reports, then I’d be more in favour of this.”

Whether you decide to sign up for the service or not, just be sure to do it with your eyes open.

Someone’s watching your accounts. Make sure it’s us.

PROTECT YOUR IDENTITY

This week on the Lock and Code podcast…

In May of last year, a warning about AI came from somewhere unexpected: The Auschwitz-Birkenau State Museum.

Posting publicly on social media, the museum warned about a Facebook account using generative AI to create fake images of people who died in the Holocaust. Despite using AI to generate fake images, the people in said images were sometimes real. They had real names, birthplaces, and stories of deportation that the Auschwitz-Birkenau State Museum itself had shared before. They had real faces captured in real surviving photographs, which were likely abused to generate the false images. 

In other words, someone, or some team of people online, was deepfaking the Holocaust.

As the Auschwitz museum wrote online:

“These are not real photos of the victims. They are digital inventions, often stylized or sanitized, that risk turning remembrance into fictionalized performance. The history of Auschwitz is a well-documented story. Altering its visual record with AI imagery introduces distortion, no matter the intent.”

Months later, the public found out what that intent was: money.

A BBC investigation found an international network of Facebook accounts posting AI-generated images to earn money from those images’ potential virality. It’s a problem sometimes referred to as “AI slop” but it comes with a major incentive. When accounts that make these kinds of images are invited to Facebook’s content monetization program, they can make $1,000 a month for posting anything that gets clicks.

And on Facebook, the BBC found, that means several accounts posting AI-generated images about the Holocaust. As the BBC reported:

“AI spammers have posted fake images purporting to be from inside [Auschwitz], such as a prisoner playing a violin or lovers meeting at the boundaries of fences—attracting tens of thousands of likes and shares.”

The economics of lying are concrete today. People can use AI to make fake images that make people feel good about terrible things or feel scared about untrue things, and they can make money until shut down by the Big Tech platforms themselves, which, in this case, only happened because of the BBC’s investigation. In fact, it’s that type of inaction from social media platforms that compelled the German government and multiple Holocaust memorial institutions to send an open letter earlier this year that asked for better controls and restrictions against this type of content.

As the signatories warned in their letter, the economic appeal for these accounts to distort history is too high a risk to allow. You can read the full letter here.

Today, on the Lock and Code podcast with host David Ruiz, we speak with Clara Mansfeld, a historian working on digital communications at one of the institutions signed onto the open letter—the Foundation of Hamburg Memorials and Learning Centers Commemorating the Victims of Nazi Crimes. In their conversation, Mansfeld discusses digital access to history, the manipulation of factual records through AI-generated imagery, and the threat that society faces when it becomes harder to evaluate the truth.

“What happens when the first thought we have with every historical image is, ‘Is that even real or is that AI?’ I don’t think we have really grasped what that means for us as a society.”

Tune in today to listen to the full conversation.

Show notes and credits:

Intro Music: “Spellbound” by Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/
Outro Music: “Good God” by Wowa (unminus.com)

Listen up—Malwarebytes doesn’t just talk cybersecurity, we provide it.

Protect yourself from online attacks that threaten your identity, your files, your system, and your financial well-being with our exclusive offer for Malwarebytes Premium Security for Lock and Code listeners.

Recent news had us wondering whether Meta actually knows what it wants.

On one platform, Meta is promoting AI chats that it says even it cannot read. On another, it has removed one of the few features that genuinely prevented Meta from accessing private conversations.

“Meta removed support for end-to-end encrypted chats from Instagram as of May 8, 2026.”

“Meta adds fully private AI chats to WhatsApp.”

At the moment, Meta is heavily promoting a new Incognito Chat mode for its Meta AI assistant in WhatsApp, built on top of a system it calls Private Processing. According to WhatsApp’s own announcement, Incognito Chat is:

 “Truly private — no one can read your conversation, not even us.”

When you start an Incognito chat with Meta AI, you get a temporary conversation where messages aren’t saved and disappear by default, which Meta pitches as “a space to think and explore ideas without anyone watching.”

BBC News and others report that these AI chats are text‑only for now, run in a sandboxed environment, and are separate from your regular end‑to‑end encrypted (E2EE) messaging with other people on WhatsApp.

Meta is also preparing “Side Chat,” which will let you invoke Meta AI inside other WhatsApp chats, again using this Private Processing infrastructure to claim AI assistance without breaking the underlying encryption.

On paper, that’s an impressive technical and marketing story: powerful AI, wrapped in layers of privacy‑preserving infrastructure, added to an app that already has a strong reputation for end‑to‑end encryption by default.

Meanwhile, on Instagram…

Now contrast that with what’s happening on Instagram. On 8 May 2026, Meta removed optional end‑to‑end encryption for Instagram Direct Messages (DMs) entirely. Users who had previously turned the feature on were shown notices that “end‑to‑end encrypted messaging on Instagram is no longer supported as of 8 May 2026,” and were urged to download backups of their encrypted conversations before the cutoff.

End‑to‑end encryption ensures that only the sender and recipient can read their conversations. Instagram offered this as an opt‑in feature since late 2023, but it was buried several taps deep inside individual conversation settings and never turned on by default. Meta’s explanation for shutting it down is that “very few people” used encrypted DMs and that maintaining a separate encrypted system added complexity. Critics have pointed out the circular logic. The company hid the feature, did not advertise it, and is now using low adoption as the reason to kill it rather than, say, making it easier to find or turning it on by default.

What all this means

From a user’s perspective, the result is confusing: one Meta product introduces stronger privacy than ever for AI chats, while another removes the one feature that truly stopped Meta from reading your conversations.

The key point to remember here is that “incognito” and “private” are marketing words, while end‑to‑end encryption is a technical guarantee.

For security‑conscious users, this split personality means you can no longer treat all Meta chats the same. WhatsApp remains end‑to‑end encrypted for person‑to‑person messages and adds optional privacy features around its AI, while Instagram DMs should now be assumed readable by Meta and potentially accessible to law enforcement, advertisers, or attackers who gain access to Meta’s systems.

To boldly browse, away from prying eyes. 

TRY OUR ULTRA-FAST VPN

Why make AI chats private?

We’ve seen that AI chats have suddenly turned up in search results without users’ knowledge. So there definitely is a positive side to this new feature.

We also know there have been lawsuits against chatbot providers in cases where the outcome of an AI conversation led to very undesirable results. But how would you be able to provide evidence when messages auto-disappear?

How to proceed

Meta’s recent moves show that strong privacy features can be added where they support a strategic narrative and removed where they conflict with business or regulatory priorities. Users can’t control those decisions, but they can respond by choosing where they hold their most sensitive conversations and by assuming that if a chat isn’t end‑to‑end encrypted by default, it is ultimately readable by someone other than the people in it.

So, what’s a safe way to move forward?

• Treat Instagram DMs as postcard-level privacy. Now that E2EE is gone, assume Meta can read and scan your messages and that content could be accessed under legal orders or in a breach. Do not send passwords, recovery codes, banking details, or compromising photos over Instagram.
• When someone asks you to move a conversation to Signal, WhatsApp, or another E2EE messenger, ask them why. It does make sense when you’re sharing financial details, personal images, health information, or anything you would not want a platform provider to read. But sometimes scammers prefer encrypted platforms too, because they’re harder to monitor.
• Do not confuse “incognito” AI chats with full encryption. WhatsApp’s Incognito mode for Meta AI may be a privacy improvement over standard cloud AI chats, but it is still a conversation with a large language model owned by the same company that runs the platform. Share only what you’re comfortable entrusting to Meta.
• Regularly review your privacy and security settings. Check which devices are logged in, enable two‑factor authentication, and verify which of your chat apps are actually end‑to‑end encrypted by default.

Scammers know more about you than you think. 

Malwarebytes Mobile Security protects you from phishing, scam texts, malicious sites, and more. With real-time AI-powered Scam Guard built right in. 

Download for iOS → Download for Android → 

Schools love a good photo, whether it’s from a trip to a castle, a science prize ceremony, or sports day shot from three angles. For two decades, celebratory images like these have gone straight onto school websites, captioned with a name and a grade. But those days are gone, because it’s the internet in 2026 and we can’t have nice things.

As first reported by the Guardian, experts are now urging schools to take those pictures down. According to the UK’s National Crime Agency, the Internet Watch Foundation, and an advisory body called the Early Warning Working Group (EWWG), blackmailers have been scraping ordinary school photos, feeding them through AI deepfake tools to manufacture child sexual abuse material (CSAM), and demanding payment to keep the images offline.

One school, 150 images

Late last year, cybercriminals contacted an unnamed UK secondary school with that demand. The IWF classified 150 of the resulting images as CSAM under UK law and generated digital fingerprints for each image so major platforms could block reuploads.

The IWF isn’t naming the school or the police force, and it doesn’t believe this was an isolated case. The EWWG says it’s “only a matter of time” before more schools face similar demands.

UK safeguarding minister Jess Phillips called it a “deeply worrying emerging threat.” In February 2025, the UK became the first country to ban AI tools designed specifically to generate CSAM.

How we got here

This threat didn’t appear overnight, and it isn’t limited to the UK. It’s an evolution of a long-time threat: sextortion, when someone uses intimate images to blackmail you. Traditionally, sextortion relied on real intimate images that were stolen or shared, but deepfake AI has changed everything.

The FBI’s Internet Crime Complaint Center (IC3) logged more than 16,000 sextortion complaints in the first half of 2021, with losses exceeding $8 million. By June 2023, the bureau warned the playbook had shifted: attackers were using ordinary social media photos to create fake explicit images and extort minors.

UK children’s counseling helpline Childline has seen similar shifts as deepfake tools become more accessible. It already logs many sextortion cases each year, many from kids who were manipulated into sharing intimate images of themselves. Now, the organization is getting calls from children who are being sent deepfake CSAM images of themselves without any prior contact.

One 15-year-old girl, for example, was sent a “really convincing” fake nude built from her Instagram photos.

By November 2025, IWF reports of AI-generated CSAM had more than doubled year over year, rising from 199 to 426. Girls accounted for 94% of the victims. Reported cases included children ranging from newborns to two-year-olds, according to the organization.

The ecosystem around these tools is industrial. In April 2025, a researcher found an exposed AWS S3 bucket belonging to South Korean “nudify” app GenNomis containing 93,485 AI-generated images alongside the prompts that produced them.

What the schools are being told

The EWWG’s advice is to replace close-up, identifiable photos with images taken from a distance, blurred images, or photos shot from behind. It also advises schools to remove full names from captions, audit existing images, and ask parents to re-sign consent forms.

In fact, it advises schools to rethink whether they need to publish children’s photos online at all.

Some schools have already acted. According to the Guardian, Loughborough Schools Foundation, a group of three private schools sharing a website, removed recognizable pupil images entirely last year.

The UK Information Commissioner’s Office (ICO) says that it “would still generally expect you to offer an opt-out to parents” when publishing an identifiable photo of a child, but says this isn’t legally the same as consent, which has a higher bar.

Things get murkier in the US, where states often have their own student privacy statutes. Broadly, though, under the Family Educational Rights and Privacy Act (FERPA), schools typically include identifiable photos of students under the category of directory information. This category also covers name, address, telephone listing, date and place of birth, participation in officially recognized activities and sports, and dates of attendance.

Under FERPA, schools can publish this type of information unless the child’s guardian specifically opts out. They have to notify a guardian when they want to publish it, but that process may not apply indefinitely after a student leaves the school.

That means student photos and information can remain online long after families assume they have disappeared.

What happens next

Back in the UK, Childline’s Report Remove service allows children to flag explicit images or videos of themselves that have been posted online. The service took 394 blackmail reports from under-18s last year, up by one-third compared to 2024.

Meanwhile, the UK government is amending the Crime and Policing Bill, forcing platforms to take flagged intimate images down within 48 hours or face fines of 10% of global revenue.

We anticipate a race between regulators and AI-enabled cybercriminals. Right now, attackers still have to manually find the photos themselves. The concern is that this process could soon become automated, allowing criminals to scrape names and photos from school websites and social media platforms at scale.

For parents, the simplest protection may be limiting how many identifiable pictures of your children are available online. That includes being vigilant not just with your child’s school, but their sports clubs, extracurricular activities, and social media accounts.

Someone’s watching your accounts. Make sure it’s us.

PROTECT YOUR IDENTITY

The financial services industry (FSI) is using AI to transform how financial institutions serve their customers. AI solutions can help proactively manage portfolios, automatically refinance mortgages when rates decrease, and negotiate insurance premiums for customers.

However, this adoption brings new governance, risk, and compliance (GRC) considerations that organizations need to address. To help FSI customers navigate these challenges, AWS is excited to announce an updated AWS User Guide to Governance, Risk, and Compliance for Responsible AI Adoption within Financial Services Industries.

This comprehensive guide provides FSI customers practical considerations for responsible AI adoption across key dimensions including governance, risk management, compliance, data management, model management and AI agent management. It includes detailed AWS service capabilities that customers can use to address these considerations, such as Amazon Bedrock AgentCore, Amazon Bedrock Guardrails, Amazon Bedrock Agents, Amazon SageMaker Autopilot, and Amazon SageMaker Model Monitor.

The guide is available at the AWS Whitepaper portal and is complementary to other AWS resources such as the AWS Responsible Use of AI Guide, AWS Cloud Adoption Framework for AI, AWS Well-Architected Framework – Responsible AI Lens, AWS Well-Architected Framework – Generative AI Lens, and AWS Well-Architected Framework – Machine Learning Lens.

As the regulatory environment and leading practices continue to evolve, we will provide further updates on the AWS Security Blog and AWS Compliance Center. You can also reach out to your AWS account team for help finding the resources you need.

Resources

• AWS Cloud Security
• AWS Compliance
• AWS Security Reference Architecture
• Best Practices for Security, Identity, & Compliance
• Data Protection at AWS
• Zero trust on AWS
• Cryptographic Computing

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

By now, you’ve heard about the latest frontier AI models that are remarkably good at finding vulnerabilities in code and creating potential exploits. So good, in fact, that these models have been significantly limited from general use in an attempt to give defenders time to find and fix vulnerabilities before attackers find and exploit them.

For context, on April 7, 2026, we began testing Anthropic’s Claude Mythos model as a launch partner for Project Glasswing. Our conclusion was clear: The latest models are extraordinarily capable at finding vulnerabilities and changing them into critical exploit paths in near-real-time. In Defender's Guide to the Frontier AI Impact on Cybersecurity, I shared our early findings and recommendations.

Since then, we’ve continued testing the latest frontier AI models, including Anthropic’s Mythos and Claude Opus 4.7 and OpenAI’s GPT-5.5-Cyber as part of the Trusted Access for Cyber program. The big question just a few weeks ago was: “Are we overstating the model capabilities?” With more testing, I can confidently say we weren’t. In fact, these models are likely even better at finding vulnerabilities than we initially realized. Today, we’re providing an update on our ongoing research, our learnings uncovered in the process, and the approach we’re taking to protect our customers.

Find and Fix Before Attackers Find and Exploit

Today, we released our May “Patch Wednesday” security advisories, our monthly cadence of transparent vulnerability disclosure and remediation. This is the first time where the majority of findings were the result of frontier AI models scanning our code.

• These are the results of the full, initial scan of over 130 products across all three platforms.
• As of today, we’ve patched all important vulnerabilities in our SaaS delivered products, and all customer-operated products now have patches available.
• Today’s advisory covers 26 CVEs (representing 75 issues) versus our usual volume (typically less than 5 CVEs in a month); none of which are being exploited in the wild. Note, this excludes CyberArk vulnerabilities, which are disclosed in their normal process.

It's important to understand this isn’t a one-and-done situation. We’re now rescanning, applying all our learnings about how to provide the right context and threat intelligence to the models. We intend to fix every vulnerability we find before advanced AI capabilities become widely available to adversaries.

While incredibly powerful, AI models aren’t simply magic. To achieve high-fidelity results, you need to build AI scanning harnesses, leverage context, guardrails and threat intelligence. We’ve also discovered a variance across models, due to variations in their training. A multimodel approach is required to identify the superset of vulnerabilities. And finally, while the immediate priority is finding and fixing the vulnerabilities that organizations currently have, the longer-term shift is incorporating these models directly into the software development lifecycle. This is the light at the end of the tunnel: A future where software is secure by design.

Four Steps Every Organization Needs to Take Immediately

Regardless of the current restricted access, we believe these capabilities will flow more broadly to other models. We now estimate a narrow three-to-five-month window for organizations to outpace the adversary before AI-driven exploits start to become the new norm. This impending vulnerability deluge demands urgency. Organizations that haven’t put appropriate safeguards in place will face an entirely new class of risk. Here’s what we recommend:

1. Find and Fix Vulnerabilities In Your Applications, Products and Code
   Find and fix before attackers find and exploit.
   • Leverage AI models to identify vulnerabilities across all codebase.
   • Apply the same AI scanning to your open-source supply chain, and remediate or mitigate findings.
   • Run accelerated patching tightly coordinated with product and development teams.
2. Assess, Reduce and Remediate Your Exposure
   Reduce what is reachable by attackers, secure what must be accessible, such as customer-facing applications.
   • Attack surface management products, like Cortex Xpanse^®, have never been more critical for finding and reducing exposure.
   • The latest frontier AI models are very adept (with the right AI scanning harness) at evaluating exposures, understanding security misconfigurations and prioritizing attack-path reachability.
   • Audit your supply chain, including AI infrastructure, runtime environments and model dependencies.
3. Ensure Attack Protections
   Vulnerability exploits are typically just one step of a multi-step attack lifecycle. Ensuring best-in-class protections is now even more important for preventing breaches.
   • Map current sensor coverage to identify critical blind spots in detection, prevention and telemetry.
   • Deploy best-in-class XDR everywhere with an emphasis on real-time ML-based detection and prevention of attacks with all hosts on-premises and cloud included.
   • Deploy Agentic Endpoint Security to secure wide-scale adoption of vibe coding and AI security across the enterprise (e.g. Prisma AIRS^® and our recent acquisition of Koi are now a necessity for securing the agentic endpoint).
   • Secure enterprise browsers with AI-based security are a must have for securing where users now do their work.
   • Zero trust and Identity Security are foundational to securing every user and connection, extending to internal segmentation and outbound application connections.
4. Deploy Real-Time Security Operations
   Autonomous AI-driven attacks will drive attack lifecycles to minutes requiring every SOC to achieve single-digit mean time to detect (MTTD) and mean time to respond (MTTR).
   • Attack detections must be AI/ML-driven to detect even frequently changing and novel attacks at scale.
   • These AI detections must operate against a wide range of first party and third party data sources. A best in class AI SOC must operate on ALL relevant data sources.
   • Automation, both natively integrated and throughout the SOC lifecycle, is necessary to achieve single-digit MTTR. This automation will increasingly be agentic.
   • This must be delivered as a platform to remove seams and gaps created by point solutions.
   • Assess and act as quickly as possible.

Fighting AI with AI — AI Frontier Security Innovations Coming Soon

So far, frontier AI models only find new attacks, not new attack techniques. This means that with the right innovations, we can expand our use of AI to solve the security challenges that organizations are facing, and deliver what our customers need to stay ahead of the ever-evolving threat landscape, including:

• Reimagining virtual patching with proactive, high-fidelity content updates across network, endpoint and cloud security – We expect that across open source and technology suppliers there will be a deluge of patches, and virtual patching will provide a mitigation layer necessary to give your teams time to update. We expect to roll out the first phase of capabilities very soon.
• Enhanced attack preventions, including cyber-LLM trained ML and small language models (SML) and behavior protections – Early testing with Cortex XDR^® and our network security security services, such as WildFire^® malware prevention, indicate high protection coverage from the types of attacks created using these new frontier AI models.
• Using these models to scan our code, applications and even security configurations – Our intention is to productize these capabilities and incorporate them into our platforms.

Unit 42 — We’re Here to Help

We recognize that not everyone has the capacity and/or expertise to action all of the recommendations to effectively counter frontier AI-driven risks in the short timeframe mandated by AI innovation. Our Unit 42 Frontier AI Defense service is designed to discover and remediate your current exposure before attackers do, strengthen controls that reduce exposure and contain impact and modernize security operations so teams can detect and respond at machine speed.

This is a pivotal moment for our industry. While the scale of the challenge presented is real, I’m confident in our ability to solve it. We’re here to help our customers navigate this transition and ensure that as the landscape continues to evolve, the advantage remains with the defender.

Forward-Looking Statements

This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact, or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. These forward-looking statements are not guarantees of future performance, and there are a significant number of factors that could cause actual results to differ materially from statements made in this blog. We identify certain important risks and uncertainties that could affect our results and performance in our most recent Annual Report on Form 10-K, our most recent Quarterly Report on Form 10-Q, and our other filings with the U.S. Securities and Exchange Commission from time-to-time, each of which are available on our website at investors.paloaltonetworks.com and on the SEC's website at www.sec.gov. All forward-looking statements in this blog are based on information available to us as of the date hereof, and we do not assume any obligation to update the forward-looking statements provided to reflect events that occur or circumstances that exist after the date on which they were made.

The post Defender's Guide to the Frontier AI Impact on Cybersecurity: May 2026 Update appeared first on Palo Alto Networks Blog.

Today, we’re excited to announce the preview release of full repository code review, a new capability in AWS Security Agent that performs deep, context-aware security analysis of your entire code base. AI-driven cybersecurity capabilities are advancing rapidly. AWS Security Agent can now find vulnerabilities and build working exploits across your entire code base at a scale and speed we haven’t seen before, reasoning like a human security researcher, but operating at machine velocity. Unlike traditional static analysis tools that match code against known vulnerability patterns, full repository code review reasons about your application’s architecture, trust boundaries, and data flows the way a human security researcher would and then produces developer-ready findings with transparent evidence and concrete remediation.

AWS is prioritizing free early access for customers, giving defenders the opportunity to strengthen their code bases and share what they learn so the whole industry can benefit.

Development teams today face persistent tension. Traditional static application security testing (SAST) tools are fast and reliable at catching known patterns such as a SQL injection sink, an unescaped output, or a hard-coded credential. But modern applications are complex systems of services, APIs, trust boundaries, and authorization logic. The most dangerous vulnerabilities often aren’t single-line pattern violations, rather they’re systemic gaps where a validation function covers four of five cases, one endpoint is missing the authorization annotation its neighbors have, or encoding is applied in one context but not another.

Manual security reviews catch these issues, but they’re expensive, slow, and don’t scale to the pace of modern development. As code bases grow, teams are forced to choose between breadth and depth.

Full repository code review is built to close this gap. It gives your team an automated security researcher that reads and reasons about your entire repository, not just individual lines or file, and surfaces findings that pattern-matching tools miss.

Full repository code review operates in four stages that mirror how an experienced security engineer conducts an engagement.

1. Profile the application: The scanner begins by reading the entire repository and building a security model of the application including entry points, trust boundaries, data flows, authorization invariants, and the defenses already in place. This profiling step accounts for every source file, so coverage decisions are explicit rather than implicit. The result is a structured understanding of what the application does and where its attack surface lies.

2. Search for vulnerabilities: An orchestrator reads the security profile, reasons about the attack surface, and dispatches specialized agents to the highest-risk components. Each agent receives a scoped assignment with specific modules, threat context, and adversarial questions. Agents are free to follow imports and callers beyond their starting scope when a lead takes them there.

3. Triage and deduplicate: Candidate findings are deduplicated (same sink, same root cause) and low-confidence noise is filtered out before the validation phase.

4. Validate independently: For every candidate, an independent validator re-reads the source code and traces the full attack chain. The validator argues both sides: it looks for reasons the finding might not be a vulnerability (compensating controls, intentional design), and it looks for reasons it is one (alternative attack paths, edge cases). A finding is only rejected when the evidence against it is as strong as the evidence that promoted it. This process produces findings with structured Verified and Could not verify sections, so your team knows exactly what the scanner confirmed in the code and what depends on your deployment environment.

Full repository code review differs from traditional static analysis in two fundamental ways. It reasons about your application’s actual behavior rather than matching against known vulnerability patterns, and it presents findings with structured evidence that makes uncertainty explicit rather than hidden.

Because the scanner builds a security model before searching for vulnerabilities, it reasons about the application’s actual behavior, not only surface-level code patterns.

Consider a real example: A stored procedure had a SQL injection vulnerability. A traditional SAST tool would flag the specific EXECUTE IMMEDIATE call. The scanner went deeper and it identified that the central validation function doesn’t block single quotes in any of its five regex profiles, listed all five profiles by name, explained why single quotes matter for the specific database engine, and noted that another stored procedure skips the validation function entirely. Instead of a point fix on one call site, the finding led to a comprehensive remediation of the systemic gap.

In another case, the scanner found an XSS vulnerability where a value was added to a field without HTML encoding. The same value was properly encoded with Encode.forHtml() in a different context within the same file. Pattern-matching tools miss this because the encoding function is present, but the vulnerability is the inconsistency, which requires understanding the application’s behavior across code paths.

Every finding is structured for efficient developer triage:

• Problem: What the code does wrong, with specific file and line references.
• Impact: What an attacker gains, with details about deployment context.
• Verified and could not verify: What the scanner confirmed directly in code versus what depends on your environment (network segmentation, runtime behavior).
• Remediation: Concrete fix suggestions with specific code changes, not generic guidance.
• Severity and confidence: Calibrated independently. Severity reflects the impact if the vulnerability is exploitable; confidence reflects how much of the attack chain was verified in code.

Full repository code review is designed to complement, not replace, your existing security tooling. Here’s how it fits into a modern development workflow:

• Before security reviews: Run a full repository code review before scheduling a penetration test or security review. The review surfaces the obvious and semi-obvious issues so your security team can focus their limited time on the subtle, design-level questions that require human judgment.
• When onboarding acquired or open source code: Full repository code review is especially valuable when your team inherits code through acquisitions or vendor dependencies, or from open source components you’re integrating. The scanner builds a security model from scratch, so it doesn’t need institutional knowledge of the codebase.
• During architecture reviews: Because the scanner reasons about trust boundaries, data flows, and authorization invariants, its findings often surface architectural issues, not only implementation bugs. Review the scan results alongside your threat models to validate assumptions about how components interact.

Follow our Quickstart guide to set up and execute a full repo code review with AWS Security Agent.

Full repository code review is available today in preview at no additional charge for AWS Security Agent customers. During the preview, we welcome your feedback as we refine the experience. Use the built-in feedback mechanism in the Security Agent web application or reach out to your AWS account team.

Visit the AWS Security Agent console to enable full repository code review and run your first scan. For more information, see the AWS Security Agent documentation.

Cloud and AI are transforming industries and societies at unprecedented speed, from accelerating research and enhancing customer experiences to optimizing business processes and enriching public services. At Amazon Web Services (AWS), we believe that for the cloud and AI to reach their full potential, customers need control over their data and choices for how and where they run their workloads. In 2022, we formalized our commitment to control and choice—offering all AWS customers the most advanced set of sovereignty controls and features available in the cloud with the AWS Digital Sovereignty Pledge. As AI adoption accelerated, we’ve been working with customers to help them embrace AI innovation while meeting sovereignty requirements. We’re committed to ensuring customers can continue to harness AI’s transformative capabilities without compromising on the capabilities, performance, innovation, security, and scale of the AWS Cloud to meet their sovereignty needs, including AI sovereignty. Our approach to AI sovereignty is grounded in a deep understanding of these needs and the real-world implementation challenges that come with them.

Through discussions with customers, partners, analysts, and regulators, we’ve learned that digital sovereignty—and AI sovereignty—means different things to different stakeholders. Each country and region has unique, evolving sovereignty requirements, with no uniform guidance on which workloads or sectors must comply. Despite this variation, we’ve identified consistent themes: data sovereignty (including data residency and operator access restrictions) and operational sovereignty (including resilience, survivability, and independence). AI sovereignty builds on these foundations, adding emerging considerations such as preserving cultural norms, values, and local languages in AI outputs. Ultimately, meeting digital and AI sovereignty requirements comes down to providing customers with more control and choice.

AI sovereignty requires control and choice across the AI stack—comprehensive cloud infrastructure that combines compute, networking, data management, security controls, specialized application services, and talent. This includes the ability to make deliberate choices across the stack such as location, dependencies, services, and partners that align with customers’ unique needs, regulatory requirements, and innovation objectives. With AWS, customers can develop AI on a trusted foundation where their data remains secure and under their control. Customers have the freedom to choose from a comprehensive range of AI optimized chips—including purpose-built AWS silicon and chips from NVIDIA, AMD, and Intel—so they can select the right chip for the right workload. AWS applies two decades of learned expertise to our comprehensive AI stack, enabling organizations to maintain complete control over their data and operations while accessing cutting-edge capabilities to solve local challenges.

AWS provides customers with the infrastructure and tools to embed AI across the full value chain—not just in isolated use cases, but as a foundational capability enabling them to train and deploy models and build sophisticated AI and generative AI applications with exceptional performance. This enables customers to focus on innovation instead of their infrastructure, bringing the cloud to where they need it most with a range of options including AWS AI Factories, AWS Outposts, AWS Local Zones, AWS Dedicated Local Zones, and AWS Regions including the AWS European Sovereign Cloud. For example, customers who require dedicated deployments to meet their sovereignty requirements for their mission-critical AI workloads can use AWS AI Factories. These physically isolated, dedicated deployments built exclusively for the customer combine the latest AI infrastructure, including AWS Trainium accelerators, NVIDIA GPUs, dedicated networking, and storage. AWS AI Factories address AI sovereignty needs by delivering on-premises AI capabilities to securely perform training, fine tuning and real-time inference.

The AWS AI portfolio offers a comprehensive range of services—from foundation models (FMs) through Amazon Bedrock, to machine learning offerings like Amazon SageMaker, application services like Amazon Q, and developer tools like Kiro—designed to give customers control over their data and choice in how they deploy AI. With Amazon Bedrock, customers can choose from hundreds of models from leading providers like AI21 Labs, Anthropic, Amazon, Cohere, Mistral AI, and OpenAI. Customers can evaluate and select the most suitable FMs for their specific needs and choose where they deploy them, and fine-tune models privately with their own data. Customers are always in control of their data. Critically, no customer inputs to or outputs from Amazon Bedrock are used to train Amazon Nova or any third-party models.

Successful AI strategies require building a holistic environment nurturing local talent, supporting startups, developing industry-specific applications, and fostering public-private partnerships. The cloud has transformed AI from an exclusive technology requiring massive investment into an accessible tool for innovation across all sectors and organization sizes. While technical infrastructure gets much of the attention when considering AI sovereignty, the cultural and strategic dimensions of national FMs are equally critical. These FMs aren’t merely computational tools, they can encode elements of cultural knowledge, linguistic nuance, and societal context, making local relevance a design consideration rather than an afterthought. These FMs serve purposes that extend beyond technical capabilities. Locally trained FMs can reflect national educational curricula and cultural values while understanding local legal systems, business practices, and regulatory frameworks. Models trained on local languages, dialects, and cultural contexts support linguistic diversity and help underrepresented languages gain representation in AI products and services.

AWS supports vital national priorities and customers’ missions, such as the preservation of culture norms, values, and local languages development of regional and local language model capabilities. To customize models, customers can use Amazon SageMaker AI for voice, domain specialization, and to evaluate models for accuracy. For example, the first Greek LLM made available in March 2024 was Meltemi—built on top of Mistral-7B, running on AWS infrastructure, and continually pretrained to extend its proficiency in the Greek language using a dataset of 28.5 billion Greek tokens. Meltemi is available on HuggingFace. SEA-LION—a family of open source, multilingual LLMs for Southeast Asia—was trained entirely on AWS with managed GPU clusters. Their team completed a 3B-parameter model in only 3 months—a 60% faster timeline than comparable on-premises projects.

Sovereignty isn’t only about where data resides—it’s about who can access it and under what conditions. In the AI context, access restriction extends beyond infrastructure to cover model inputs, outputs, training processes, and the operational environments in which AI runs. Unlike traditional infrastructure, AI workloads introduce new access surfaces: the model itself, the data used to train it, and the inference pipeline through which sensitive inputs flow. This furthers the need for verifiable governance and identity propagation in IT systems.

To help ensure the confidentiality and integrity of customer data, all modern Amazon Elastic Compute Cloud (Amazon EC2) instances including those that offer AI accelerators, such as AWS Inferentia and AWS Trainium, are backed by the industry-leading security capabilities of the AWS Nitro System. By design, there is no mechanism for anyone at AWS to access customer data on Nitro EC2 instances that customers use to run their workloads. AWS services—including those with AI capabilities built on Amazon EC2—inherit these same protections. These protections apply to AI data running in the AWS Nitro System so that they’re protected at every stage—from model training to inference. The NCC Group, an independent cybersecurity firm, has validated the design of the Nitro System. We believe providing this level of transparency is critical in building and sustaining trust.

As AI agents increasingly take actions across systems on behalf of users, controlling who and what can access resources—and ensuring appropriate human oversight—becomes critical. AWS Identity and Access Management (IAM) helps ensure that only authorized users and applications can access AI resources through fine-grained permissions and comprehensive audit trails. For AI agents and automated workloads, Amazon Bedrock AgentCore Identity provides identity and credential management, so agents operate with the right permissions and nothing more.

Transparency is at the core of our digital sovereignty commitment. We provide comprehensive industry-leading technical measures, operational controls, and contract protections that give customers control over where they locate their data, who can access it, and how it’s used. To give greater assurance on how AWS services are designed and operated, we continue to seek out and secure third-party attestations, accreditations, and certifications that help our customers meet their compliance needs.

We continue to deepen our assurances and transparency to customers—such as updating our AWS Service Terms to reflect our technical protections commitments (e.g. AWS Nitro System), providing detailed commitments as to our handling of third-party requests for customer data in our agreements, and providing supplemental explanations and resources (e.g. CLOUD Act blog) to empower customers to make informed choices on sovereignty matters. These efforts extend into our commitment to responsible AI, providing customers the confidence to build and operate AI applications responsibly using AWS Services. ISO/IEC 42001 is an international management system standard that outlines requirements and controls for organizations to promote the responsible development and use of AI systems. AWS is the first major cloud service provider to achieve ISO/IEC 42001 accredited certification for AI services, covering Amazon Bedrock, Amazon Q Business, Amazon Textract, and Amazon Transcribe. In November 2025, AWS successfully completed its first surveillance audit for ISO 42001:2023 with no findings, reiterating the continual commitment of AWS to responsible AI practices.

Innovative technology requires a secure and trustworthy foundation. AWS supports more than 140 security standards and compliance certifications that our customers and partners can inherit to help comply with local laws and regulations. For two decades, we’ve deeply engaged with regulators and cybersecurity authorities to align our offerings with national priorities and ensure our solutions support both innovation and control. We actively contribute to frameworks that respond to new developments without stifling progress.

AWS is committed to giving customers the same control and choice over their AI systems as they have over their data. We help customers harness AI’s transformative power while maintaining the capabilities, performance, innovation, security, and scale of AWS Cloud. As cloud and AI evolve, AWS will continue offering the most advanced sovereignty controls and features available.

If you have feedback about this post, submit comments in the Comments section below.

AI security covers more than just data theft prevention, restricting rogue AI agents, or stopping assistants from giving harmful advice. A relatively simple but rapidly scaling threat has emerged: attempts to hijack computational power and exploit someone else’s neural network for personal gain. This is known as LLMjacking. With AI compute costs widely predicted to surge dramatically, the number of attackers driven by these motives is poised to grow. Consequently, when deploying proprietary AI servers and their supporting ecosystems like RAG or MCP, it’s critical to establish rigorous security measures from day one.

Statistics from a honeypot

The speed and scale of these resource-hijacking attempts are best illustrated by an experiment documented in detail in April 2026. The investigator configured a Raspberry Pi to masquerade as a high-performance private AI server, and made it accessible from the internet. When queried, it reported the availability of Ollama, LM Studio, AutoGPT, LangServe, and text-gen-webui servers — all tools commonly used as wrappers for locally hosted AI models. The server also appeared ready to accept API requests in the OpenAI format, which has become the industry standard.

All these services were seemingly powered by a local instance of Qwen3-Coder 30B Heretic, one of the most powerful open-source models, with its safety alignment removed. To throw in a sweetener, the honeypot reported the presence of various RAG databases and an MCP server with tempting capabilities like get_credentials on board.

In reality, the Raspberry Pi was simply hosting 500 pre-saved responses from an actual Qwen3 model, with a lightweight script selecting the most relevant answer for each incoming query. This setup was enough to pass a superficial check while allowing the researcher to probe the attackers’ intentions.

According to the author, Shodan, a popular internet scanning service, discovered the server within three hours of its going live. Just one hour later, requests resembling capability reconnaissance began pouring in. Over the following month, the server handled more than 113 000 requests from thousands of unique IPs, with 23% of that traffic specifically targeted at discovering AI capabilities and exploiting local LLMs and AI agents.

Requests to endpoints like /api/tags and /v1/models allow attackers to fingerprint which models are hosted on a server, while scanning for /.cursor/rules typically precedes an attempt to exploit an AI agent. Similarly, checking /.well-known/mcp.json serves as an inventory of the victim’s MCP servers. While the author makes no mention of the total number of attacks that progressed beyond simple scanning, there were 175 active attempts to hijack the LLM during the final week of the experiment alone.

What are the attackers after?

Based on the researcher’s observations, none of those targeting the decoy server attempted to execute arbitrary code or gain root access. (Editorial note: this is surprising and may point to gaps in logging.) Almost all attacks were aimed at siphoning resources. For example, the following activities were logged during the experiment:

• A well-structured attempt to parse technical documentation for a microprocessor
• A prompt to write an erotic novel
• Requests to parse and structure social media text data regarding new vulnerabilities
• An attempt to call Anthropic models using the compromised server as an API proxy

It’s worth noting that the reconnaissance of AI resources uses standardized and rapidly evolving tools. Requests from an application named LLM-Scanner originated from the infrastructure of seven different cloud providers across eight countries, suggesting that the raiders have put established methodologies in place, as well as specialized platforms for sharing techniques. By the third week of the experiment, the scanner had been updated with an additional check: it now used simple abstract questions to determine whether it’s interacting with live AI or a honeypot returning canned responses.

Among the non-specific attacks, the experiment recorded numerous attempts to exfiltrate credentials from the .env file. Attackers systematically hunted for this file across every conceivable directory on the server. Leaving an .env file publicly accessible is one of the most elementary mistakes when deploying projects on Laravel, Node.js, and other frameworks, yet it remains a common oversight — particularly among beginners and vibe coders. Consequently, attackers have every reason to expect their efforts to pay off.

Conclusions and defense tips

Scanning publicly accessible servers and attempting to exploit them is nothing new, but the rise of LLMs gives attackers another way to monetize their efforts — one that’s both highly lucrative for them and devastating for their victims. To understand how massive these attacks could become, look at their closest counterpart: the cryptojacking market — where criminals mine cryptocurrency using stolen computational resources. That market grew by 20% in 2025 alone. As AI-powered solutions proliferate, and as major providers hike subscription costs while local AI chips remain in short supply, we should expect LLMjacking to become an industrial-scale phenomenon.

Key defensive measures for private AI infrastructure

• For AI systems running locally on a single machine, ensure that servers like LM Studio, Ollama, or similar are configured to accept connections only on the local interface (localhost), rather than all available network interfaces. This restricts LLM access to the host machine itself, and prevents the AI from being reachable over the internet.
• For servers handling remote requests — even if the server only operates within a local corporate network — implement robust authentication and authorization rather than relying solely on API key validation. Solutions based on OIDC or OAuth2 with short-lived tokens are the most effective. This not only defends against LLMjacking, but also allows for more granular tracking of user activity, and prevents API key abuse. Furthermore, keys must be protected from more than just external attackers; a growing risk is the misuse of keys by AI agents themselves. This applies to LLM interfaces as well as MCP, RAG, and others.
• Use network segmentation and IP allowlists to give AI server access only to the departments, employees, and services that require it.
• Ensure that all client-server connections are secured with a current version of TLS.
• Apply the principle of least privilege by separating access to specific services; for instance, MCP and LLM components should have their own distinct access tokens.
• Ensure an EDR security agent is installed on all workstations and servers, including those hosting AI models.
• Monitor AI resource consumption, establish usage quotas for different employee roles, and set up alerts for anomalous activity spikes.
• Maintain detailed logs of LLM responses and requests made to the model and its supporting tools. Integrate these data sources with your SIEM. Ensure logs are resilient against tampering or deletion.

Last week on Malwarebytes Labs:

• Microsoft says Edge’s plaintext password behavior is “by design”
• ShinyHunters escalates Canvas attacks with school login defacements
• Massive AI investment scam network spans 15,500 domains
• If a fake moustache can fool age checks, is the Online Safety Act working?
• Google Chrome’s silent 4GB AI download problem
• Attackers adopt JavaScript runtime Bun to spread NWHStealer
• Millions of students’ personal data stolen in major education breach
• Update WhatsApp now: Two new flaws could expose you to malicious files
• Cyberattacks are raising your prices (Lock and Code S07E09)
• Thousands of Facebook accounts stolen by phishing emails sent through Google
• The 2026 World Cup scam economy is already running before the first whistle

Stay safe!

Browse like no one’s watching. 

Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free → 

Researchers tracked a large AI‑themed investment scam campaign involving more than 15,000 domains. It uses cloaking and deepfakes to hide from security tools while targeting ordinary users.

Criminals abused the Keitaro ad-tracking platform as part of a cloaking system so real victims see scam content, while security scanners, ad reviewers, and some random visitors see harmless pages, making the operation hard to detect and shut down.

Keitaro is a commercial tracking platform originally meant for digital marketers to manage ad campaigns, test which ads work best, and route visitors to different landing pages.

Because it is feature rich, easy to spin up on regular hosting, and built to filter and route traffic, criminals found they can abuse those capabilities to run scams at scale.

Traffic starts in many places. The scammers used compromised websites, spam emails, social media posts, and online ads, all quietly routing through the same tracking infrastructure.

The scam sites typically promise “Smart AI Trading Technology” or “Intelligent Trading Solutions” and claim consistently high returns, often reinforced with deepfake images or fabricated media to look more credible.

Some parts of the campaign now use deepfake videos and fake interviews with well-known public figures, making it look like a celebrity, or finance expert personally endorses the platform.

Once you follow a link, the cloaking part of the operation kicks in. Cloaking is the trick that makes these scams so hard to see from the outside.

When you click an ad or link, your visit passes through a traffic distribution system (TDS), a kind of router for web visitors that decides which page you see. In these cases, the TDS is connected to the tracker.

The system checks things like:

• Your country/region
• Your device and browser
• Where you came from (Facebook ad, Google ad, email link, etc.)
• Sometimes your IP address reputation or other subtle fingerprints

You’re shown the real investment scam landing page only if you match the “ideal victim” profile (for example, a regular consumer in a target country coming from a social media ad).

Everyone else, like a security researcher, ad platform reviewer, or automated scanner, gets shown a benign page, like a generic blog or placeholder site.

How to stay safe

The best way to stay safe is to stay informed about the tricks scammers use. Learn to spot the red flags that almost always give away scams and phishing emails, and remember:

• There is no such thing as a risk-free, consistently profitable investment. If you’re looking to invest, navigate directly to known, regulated financial institutions.
• Deepfakes are very convincing nowadays, so you will hardly be able to tell the difference between the real celebrity and their deepfake persona.
• Don’t act upon unsolicited investment advice, whether it reaches you by email, social media, or sponsored search results.
• Use an up-to-date, real-time anti-malware solution with a web protection component or a reputable tracking and ad-blocker.
• Don’t act on impulse or under time pressure. Always properly research where your money will be going.

Pro tip: Malwarebytes Scam Guard can help you recognize and analyze scams.

Stop threats before they can do any harm.

Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser →

Today we published our latest Global AI Diffusion Report. The global adoption of artificial intelligence continued to rise in the first quarter of 2026. During the quarter, AI usage increased by 1.5 percentage points from 16.3% to 17.8% of the world’s working age population. Intensity of use among economies with the highest rates of AI diffusion also increased, with 26 economies now exceeding 30% of the working age population using AI.

At the top of Microsoft’s National AI Leaderboard, the UAE continued to lead global AI diffusion at 70.1%. The United States finally started to move up the national rankings, albeit only from 24th to 21st based on a 31.3% usage rate by the working age population.

Notable developments in the quarter included accelerating AI adoption in Asia driven in part by improving AI capabilities in Asian languages. South Korea, Thailand, and Japan saw the greatest movement. More broadly, the quarter brought continued widening of the AI gap between the Global North and South, with usage now at 27.5% in the North and 15.4% in the South. These trends are discussed below, including a deeper dive on the positive impact of enhanced multilingual AI capabilities in Japan.

To track all these trends, we continue to measure AI diffusion as the share of people worldwide between ages 15 and 64 who have used a generative AI product during the reported period. This measure is derived from aggregated and anonymized Microsoft telemetry and adjusted to reflect differences in OS and device-market share, internet penetration, and country population. Additional details on the methodology are available in our AI Diffusion technical paper.^[1]

No single metric is perfect, and this one is no exception. Through the Microsoft AI Economy Institute, we continue to refine how we measure AI diffusion globally, including how adoption varies across countries in ways that best advance priorities such as scientific discovery and productivity gains. For this report, we rely on the strongest cross-country measure available today, and we expect to complement it over time with additional indicators as they emerge and mature.

Sectorally, the quarter saw strengthened AI coding capabilities leading to a dramatic increase in production of software code. This was reflected in production by Anthropic’s Claude Code, the OpenAI’s Codex, and Microsoft’s GitHub Copilot. Git pushes – through which software developers put coding changes online – increased 78% year over year globally. Interestingly, the quarter brought added evidence that, at least for now, AI coding capabilities may be increasing demand for the employment of software developers.

As discussed in more detail in the report, when developer productivity increases, the cost of building software declines. If demand for software is elastic, organizations can respond by building more software across a wider range of use cases. It is still too early to know the full labor-market impact of AI-assisted coding, but the available data shows that in 2025, total U.S. software developer employment reached approximately 2.2 million, rising 8.5% year over year and marking a record high for the profession. Early data for the first quarter of 2026 shows that software developer employment in March 2026 was about 4% higher than in March 2025.

Download the latest Global AI Diffusion report. and explore the data here.

[1] A. Misra, J. Wang, S. McCullers, K. White, and J., L. Ferres, “Measuring AI Diffusion: A Population Normalized Metric for Tracking Global AI Usage,” Nov. 04, 2025, arXiv: arXiv:2511.02781. doi: 10.48550/arXiv.2511.02781. 

The post The state of global AI diffusion in 2026 appeared first on Microsoft On the Issues.