On October 29, 2026, Cursor reported that a tampered copy of Claude Code extension (anthropic.claude-code, versions 2.1.313 and 2.1.312) was available and served in the Cursor extension marketplace for a few hours to attempt a supply-chain attack on Cursor users. Cursor reports that it was live from about 2:27 AM to 1:35 PM Pacific Daylight Time (PDT). We have confirmed that the malicious packages found on Cursor marketplace were never published nor distributed from Microsoft Visual Studio Marketplace and from npm @anthropic-ai/claude-code, which were not affected by this incident. Anthropic confirmed to Microsoft that their systems were not compromised and they did not develop the malicious package posted in Cursor marketplace. At this time, all evidence suggests that the incident is limited to Cursor marketplace.

Microsoft Threat Intelligence analyzed the injected JavaScript embedded in the malicious extension package. The injected loader runs when the extension module loads and attempts to add an attacker-controlled Secure Shell (SSH) key, enable the local SSH service, establish reverse SSH forwarding, configure persistence, and report host details. Successful remote access depends on host privileges, SSH configuration, and the attacker’s server configuration; however, the loader may still write keys and persistence artifacts even when tunnel access fails.

Organizations should identify systems that installed or automatically updated to this version from the Cursor marketplace, preserve evidence, remove confirmed malicious artifacts, review endpoint and network telemetry, and rotate credentials or revoke sessions when investigation indicates exposure. Microsoft customers can use the detections and hunting guidance in this post after the listed coverage and query validation gates are complete.

Attack chain overview

A malicious artifact associated with the Cursor Marketplace incident included a JavaScript function that executed before the extension’s expected code. When the module loads, this function can use Node.js APIs to collect host information, modify files, and execute operating-system commands. The following sections describe capabilities and attempted actions based on our analysis of the injected code.

Attack chain

The loader first collects host reconnaissance. It then attempts to install an SSH key, enable SSH, create a reverse tunnel, and configure persistence. A delayed callback subsequently attempts to send host details. The following sequence reflects code execution order; it does not prove that every step succeeded on every host.

1. Module loading and reconnaissance collection. The injected function executes before normal extension initialization and collects host and user information.
2. SSH access preparation. The loader appends an embedded public key and attempts to enable the local SSH service.
3. Reverse forwarding. An embedded tunnel identity authenticates an outbound connection that requests forwarding to the workstation’s SSH port.
4. Platform-specific persistence. Scripts and startup configuration are written to relaunch the connection.
5. Host reconnaissance reporting. After the access and persistence setup attempts, a delayed callback attempts to transmit the previously collected host details and selected environment-variable names.

The loader uses embedded components and built-in system tools to establish persistent access without downloading another executable. It suppresses command output and silently catches errors to conceal failures and malicious activity, while the extension continues functioning normally to avoid alerting users.

Host reconnaissance collection

The loader collects the hostname, username, operating system, architecture, home directory, working directory, and global Git email. It also looks for environment-variable names containing terms such as KEY, TOKEN, SECRET, PASS, AWS, or GCP, keeping up to forty matches.

The callback sends matching environment-variable names, not values. This reveals potentially sensitive configuration categories but does not demonstrate theft of the secrets stored in those variables.

Collection occurs during module loading. The collected details are retained for the delayed reporting callback described after the persistence stage.

SSH authorization and tunnel identities

The loader uses two SSH identities with distinct roles. One public key authorizes access to the workstation’s user account, while a separate private key authenticates the outbound connection to the tunnel server. First, the loader checks the user’s authorized_keys file for the comment svc-telemetry. If the marker is missing, it appends an embedded Ed25519 public key. That creates an authorization entry for whoever holds the corresponding private key, subject to the local SSH server’s configuration.

Next, it decodes a separate private key for the outbound connection. The initial copy is written to a hidden temporary file named .stk_ followed by ten hexadecimal characters derived from the hostname and home directory. SSH receives that file through its -i option and connects using the remote account tunnel.

The public-key material is redacted but the format is similar to the following:

ssh-ed25519 [REDACTED PUBLIC KEY] svc-telemetry

Protocol Tunneling (T1572): reverse SSH forwarding

The tunneling SSH process is launched with the command line containing the following arguments:

-N -R '*:0:localhost:22'

It requests a listening port on the remote SSH server and forwards connections through the tunnel to port 22 on the victim’s loopback interface. The remote port value 0 asks the server to allocate a port; it does not change the local target from port 22. The -N option tells SSH not to run a command on the tunnel server.

This design starts with an outbound connection from the workstation rather than waiting for a direct inbound connection to it. The loader disables ordinary host-key checking, bypasses the normal known-hosts file, sets keepalives, and avoids interactive prompts. On Unix-like systems it prefers autossh, falling back to ssh; on Windows it uses a hidden PowerShell loop. The loops wait sixty seconds after SSH exits before retrying.

A running SSH process does not necessarily mean the attacker gained access. Both the attacker’s server and the victim’s workstation must allow the connection, and server settings determine whether the tunnel is publicly reachable. Cursor reports that errors and administrator-permission requirements blocked SSH access on most macOS and Windows hosts. However, the malware could still attempt to plant its SSH key, establish persistence, and report host information.

Platform-specific startup persistence

The loader writes platform-specific scripts and startup configuration outside the extension directory. The following table summarizes these mechanisms and their associated artifacts. The code attempts to configure persistence, but the presence of an artifact alone does not establish that the startup mechanism ran successfully.

On Unix-like systems, the .smt script reconstructs the persistent .smtk identity when it runs, then starts its own SSH retry loop. On Windows, the loader writes the identity and batch script directly.

The startup objects use names such as SysMon and com.apple.sysmond, which resemble monitoring components. Behind these names, their configured actions invoke the generated scripts that maintain reverse SSH forwarding.

Mitigation and protection guidance

Immediate actions

Run advanced hunting queries below to identify affected systems and investigate systems where users installed or automatically updated anthropic.claude-code version 2.1.313 and 2.1.312 through the Cursor Extension Marketplace. Review extension-installation records and correlate endpoint, network, file, process, and authentication telemetry with the published indicators. Preserve the extension package, modified SSH authorization files, generated keys and scripts, and startup configuration before cleanup. Isolate devices with evidence of loader execution or backdoor installation.

Remediation actions

After evidence collection, check the affected user’s ~/.ssh/authorized_keys on macOS and Linux for the attacker-controlled key labeled svc-telemetry. On Windows, check both %USERPROFILE%\.ssh\authorized_keys and C:\ProgramData\ssh\administrators_authorized_keys, where present. Confirm the key against the fingerprint in Indicators of Compromise before removing the exact unauthorized entry. Preserve unrelated SSH keys and legitimate remote-development configuration. A missing marker alone should not replace review of the installation, process, network, and persistence evidence.

Remove the trojanized extension and confirmed malicious persistence after evidence collection. Inspect each startup object’s configured action before removal; names alone are not sufficient to distinguish malicious objects from legitimate monitoring software.

• macOS: Unload and remove the malicious user LaunchAgent at ~/Library/LaunchAgents/com.apple.sysmond.plist and remove its associated ~/.config/.smt script and ~/.config/.smtk identity.
• Linux: Remove the malicious user-crontab @reboot entry referencing ~/.config/.smt, preserving unrelated entries, and remove the associated script and ~/.config/.smtk identity.
• Windows: Remove the malicious SysMon scheduled task, the Startup-folder sysmon.cmd fallback, and associated %USERPROFILE%\.config\smt.cmd and %USERPROFILE%\.config\smtk files.
• All applicable platforms: Stop confirmed malicious SSH and retry processes and remove their temporary .stk_ identity files after collection.

Cursor published platform-specific checks and remediation scripts in its security notice. Review the scripts and execution requirements before use, then verify that no listed artifacts remain. Cleanup does not replace investigation of device activity during the exposure window.

Removing or updating the extension does not remove artifacts written outside its installation directory. Remove confirmed unauthorized SSH keys, tunnel identities, scripts, and startup entries separately. Cursor’s reported server takedown does not remove artifacts already present on a device.

Follow-up Investigation and recovery

Review telemetry after the extension loaded for SSH key acceptance, tunnel processes, local SSH sessions, command execution, and file activity. Rotate credentials and revoke sessions from a known-clean device when telemetry indicates credential access or when device trust cannot be restored. Rebuild the device when required by the investigation and verify that the tunnel and startup artifacts do not return after login or restart.

To reduce the risk of malicious extensions and extension-based supply chain attacks, organizations using Cursor should apply the relevant controls in Cursor’s security-hardening guidance, including restricting extensions to approved publishers and configuring an extension installation cooldown to delay installation of newly published versions. These measures can help limit exposure to malicious releases.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR Threat analytics

Activity Profile: Malicious Claude Code branded extension v2.1.313 contains a persistent SSH backdoor

Advanced hunting queries

The following queries use the Microsoft Defender XDR advanced hunting schema and the time range selected in the portal. A result is an investigative lead, not proof of compromise.

Connections to the reported infrastructure

Find network events involving the reported IP address during the last 30 days, including the process responsible for each connection.

DeviceNetworkEvents
 | where Timestamp > ago(30d)
 | where RemoteIP == "134.209.82.225"
     or RemoteUrl has "134.209.82.225"
 | project Timestamp,
           DeviceName,
           InitiatingProcessFileName,
           InitiatingProcessCommandLine,
           RemoteIP,
           RemotePort,
           RemoteUrl

Reported malicious file and persistence artifacts

Find file events matching the reported SHA-256 hash, artifact filenames, or filename prefix during the last 30 days. Filename matches are hunting leads and require investigation.

DeviceFileEvents
 | where Timestamp > ago(30d)
 | where SHA256 == "ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15"
     or FileName in~ (
         ".smt",
         ".smtk",
         "smt.cmd",
         "smtk",
         "sysmon.cmd",
         "com.apple.sysmond.plist"
     )
     or FileName startswith ".stk_"
 | project Timestamp,
           DeviceName,
           ActionType,
           FolderPath,
           FileName,
           SHA256,
           InitiatingProcessFileName,
           InitiatingProcessCommandLine

SHA-256 values might not be populated for every file event. The filename and prefix conditions provide additional hunting leads.

Possible Windows scheduled-task persistence

Find scheduled-task creation events whose additional fields contain both reported terms, SysMon and smt, during the last 30 days.

DeviceEvents
 | where Timestamp > ago(30d)
 | where ActionType == "ScheduledTaskCreated"
 | where AdditionalFields has "SysMon"
     and AdditionalFields has "smt"
 | project Timestamp,
           DeviceName,
           AccountName,
           AdditionalFields,
           InitiatingProcessFileName,
           InitiatingProcessCommandLine

Possible macOS LaunchAgent persistence

Find plist-property modification events whose FolderPath matches the reported com.apple.sysmond.plist artifact.

DeviceEvents
 | where ActionType == "PlistPropertyModified"
 | where FolderPath has "com.apple.sysmond.plist"

MITRE ATT&CK techniques

The following mappings describe behaviors implemented or attempted by the analyzed loader, not confirmed execution on every affected host. They do not establish attribution to a particular threat actor.

Indicators of compromise (IOCs)

The following indicators are associated with the publicly analyzed JavaScript sample. The remote address is defanged. Contextual strings and paths require behavioral correlation and should not be treated as conclusive evidence of compromise on their own.

References

• Cursor, Security notice — malicious version of Anthropic.claude-code (2.1.312 and 2.1.313) identified in the Cursor VS Code Extension Marketplace. Accessed October 30, 2026

Learn More

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender

The post Inside a malicious Claude Code-branded extension and its persistent SSH backdoor appeared first on Microsoft Security Blog.

A Skynet LLMjacking agent hijacks exposed AI models to scan, hack servers and mine crypto for 100,000 steps, while victims pay the bill.

Related Posts:

• INC Ransomware Affiliates Expose Seven Servers Holding Phantom AI Framework and 46 Encryptors
• BRONZE SANDCASTLE Uses Sandboxie DLL Sideloading to Deploy Modified Meterpreter Backdoor
• SafePay Ransomware Hits 600 Victims as FBI, CISA and Allies Issue Joint Warning

The post Skynet LLMjacking Agent Hijacks Exposed AI Models to Hack Servers and Mine Crypto appeared first on Daily CyberSecurity.

Gemini free tier limits start October 9: free personal accounts get only Flash-Lite, while Flash and Pro move to paid plans.

Related Posts:

• Cloudflare Clef Decision Models Speed Up AI Agents
• OpenAI Rogue AI Agents May Have Hit 100+ Organizations
• Apple Restricts Full Disk Access for macOS AI Agents

The post Gemini Free Tier Limits: Flash-Lite Only From Oct 9 appeared first on Daily CyberSecurity.

Google says one of its Gemini models accessed systems belonging to three real companies during a cybersecurity evaluation in May.

The model reportedly guessed credentials in one case, while finding exposed credentials in public repositories in two others. Google says Gemini stopped once it recognized that it had reached real infrastructure and that the affected organizations were notified.

Gemini was participating in an evaluation run by Irregular, a third-party AI cybersecurity testing firm. Similar incidents involving models from Anthropic, OpenAI, and Meta have also been linked to the same underlying problems with evaluation environments that allowed the models to reach the public internet.

But the news arrives at a particularly interesting moment.

For months, the AI industry has been steadily escalating its demonstrations of agentic capability: Models can browse, use tools, write code, pursue multi-step goals, and sometimes find ways around obstacles their developers did not anticipate. The market rewards eye-catching evidence of autonomy. “It completed the task” is impressive. “It did something it was not supposed to do” can be even more memorable.

There is another way to look at the incident: not as evidence of an AI suddenly developing criminal intent, but as a small, concrete example of the “AI alignment” problem.

Alignment is the deceptively difficult task of making an AI system’s behavior match what people actually intended, rather than merely the narrow objective they managed to express. In this case, the objective was to locate hidden information within a simulated target and complete the evaluation. But any human operator would likely have regarded one condition as non-negotiable: Do not attempt to access real companies.

Gemini appears to have optimized for the first instruction while treating the second as an inference problem. It found an organization with a matching name, encountered systems reachable from the internet, and proceeded as though they belonged to the exercise. Although it completed the task in a way its human operators would not have approved, Google says it stopped after recognizing that it had reached genuine infrastructure—something other models have failed to do.

Even so, the incident shows how potential alignment failures can be much more mundane. Give an agent a goal, tools, and room to act, and it may faithfully pursue the measurable part of the assignment while overlooking the unstated boundaries that humans rely on one another to understand. AI models do not automatically know where we draw the line.

There may also be an awkward marketing angle in the background. A model capable enough to make the wrong kind of progress can still look very capable indeed. In a market where every lab wants to demonstrate that its agents can plan, code, browse, and act independently, even a safety disclosure can carry a secondary message: Ours can play in this league, too.

It’s another reason to take seriously warnings from insiders, industry leaders, and politicians that safeguards must keep pace with the autonomy given to AI models.

US agencies accuse six Chinese AI firms of distilling frontier models and recommend new defenses that could affect enterprise AI access and API use.

The post US Accuses Six Chinese AI Firms of Distilling Frontier ModelsUS Accuses Six Chinese AI Firms of Distilling Frontier Models appeared first on TechRepublic.

US agencies accuse six Chinese AI firms of extracting billions of tokens from US AI models to accelerate development and copy advanced capabilities.

NSA, CISA, and the FBI jointly published an advisory accusing six Chinese AI companies, DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun, and Z.AI, of running industrial-scale extraction campaigns against US frontier models since at least late 2024. The framing is deliberate: this isn’t a footnote to how these companies build AI, the agencies call it the core of their entire development strategy.

Distillation is a legitimate and widely used technique. It involves training a smaller AI model to reproduce the answers and capabilities of a larger one. But the advisory says the activity it uncovered went much further. It alleges that the companies sent millions of requests to models such as Claude, GPT, Gemini, and Grok and extracted billions of tokens.

“China-based artificial intelligence (AI) companies are conducting systematic extraction of proprietary functionalities and capabilities of U.S. AI companies’ models through industrial-scale knowledge distillation campaigns that form the core—not merely a supplement—of their AI development strategy.” states the report. “Likely with Chinese government awareness, DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun, and Z.AI extracted billions of tokens across millions of exchanges/requests from U.S. frontier AI models, including variants of Claude, GPT, Gemini, and Grok, since at least late 2024.”

The goal was to capture valuable capabilities, including reasoning, coding, and agentic skills that took years and huge amounts of computing power to develop.

The advisory provides the most detail about DeepSeek. It claims the company ran an organized campaign against different versions of Claude, GPT, and Gemini between late 2024 and mid-2025 to help develop its R1 and V3 models. The extracted data reportedly included specialized knowledge, such as legal expertise, as well as chain-of-thought reasoning.

“Advanced industrial-scale distillation tactics include chain-of-thought (CoT) reasoning extraction, automated failover between pathways during blocking attempts, and sophisticated quality evaluation frameworks to detect defensive countermeasures. China-based AI companies that conduct industrial-scale distillation against U.S.” continues the advisory. “AI models see significantly shorter AI development timelines and reduced financial expenditures in training a frontier model.”

This is particularly significant because AI companies usually limit access to a model’s internal reasoning. Getting a model to reveal those steps could therefore give attackers much more than just its final answers.

Moonshot AI’s alleged operation shows how fast these campaigns can move once new models ship. The advisory states the company redirected its extraction traffic to a newly released Claude model within 24 hours of launch, which only works if you already have infrastructure sitting ready and monitoring provider releases in real time. That’s not opportunistic scraping; that’s a standing operation built specifically to capture whatever comes out next.

The methods described in the advisory suggest a highly organized operation rather than researchers simply making API requests. The companies allegedly bought large numbers of premium accounts and shared them among teams of developers running many sessions at the same time. They also routed traffic through gray-market proxy services, which the advisory calls “transfer stations,” to remove identifying information and avoid detection. StepFun reportedly used pools of accounts and automated systems to spread requests across them, helping bypass rate limits and increase daily spending as the operation grew.

The advisory also describes attempts to manipulate the AI models themselves. MiniMax allegedly used prompt injection to convince Claude Code that it was actually a MiniMax product, hoping to make it behave differently. While this detail may sound unusual, it shows how far some of these efforts reportedly went to extract information from competing AI systems.

The advisory doesn’t just name and shame, it lays out concrete detection signals for US AI companies to watch for. Shared accounts logging in from multiple IPs and user agents, usage running 24/7 without the natural idle periods a human would produce, subscription-to-API-usage ratios that don’t add up, and brand-new accounts hitting maximum usage immediately instead of ramping up gradually the way legitimate adoption normally does.

We must consider that any one of those signals alone might be nothing, but the agencies are betting the combination is a fairly reliable tell.

“China-based AI companies leverage techniques not in MITRE ATLAS, demonstrating significant organizational investment, operational maturity, and adaptive capability development distinguishing these campaigns from opportunistic exploitation.” added the advisory.

The recommended countermeasures get genuinely aggressive, and one in particular is worth sitting with. The advisory suggests quietly serving degraded, less capable responses to accounts suspected of running distillation campaigns, without ever telling those users their access has been downgraded, specifically so they can’t adjust their extraction technique in response. That’s a notable policy stance from a government advisory: not just detect and block, but actively deceive suspected bad actors about the quality of what they’re receiving.

Whatever the geopolitical debate, the practical lesson for companies using frontier AI models is clear. If several employees share enterprise AI accounts, providers will likely monitor usage more closely for the patterns described in the advisory. Heavy legitimate use could sometimes trigger false positives, especially when organizations have many developers making large numbers of requests at the same time.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, AI Models)

Edge AI moves model execution, model IP, customer data, and system authority into infrastructure the customer owns and operates. That changes who must verify the stack before sensitive assets are released.

Edge AI includes AI systems where inference runs on or near the device, sensor, or other local environments where data is produced and acted on, rather than relying entirely on a centralized cloud service. It is chosen for cost, model selection, sovereignty, latency, and disconnected operation.

Edge AI changes the trust model for AI systems

In Cloud AI, separate companies own and attest the hardware, platform, and model weights. Edge AI deployments often place customers in control of more of the AI stack. This changes the security model because the customer is now responsible for establishing trust across the environment where the AI operates.

In Edge AI, attacks such as prompt injection, model tampering, or malicious firmware updates can occur in the same environment that stores the model, customer data, credentials, and access to physical systems. This shifts trust decisions that were previously handled by cloud providers to the customer. Both the model provider and the customer now share risk: the provider’s models run on customer-owned infrastructure, while the customer must protect the systems, data, and models operating in that environment.

What changes with Edge AI?

• Customers operate more of the AI stack.
• AI systems can be influenced by prompts, retrieval data, agent instructions, and runtime inputs.
• Models, credentials, and data can live in environments outside the provider’s direct control.
• Traditional software security controls alone are not enough.

What should organizations do?

• Verify runtimes using attestation.
• Verify AI artifacts using provenance.
• Constrain model actions through mediation.
• Bind and release sensitive assets only to trusted environments.

Our post on threat modeling for AI systems covers safety and security issues related to the underlying model. These concerns apply to Edge AI as well. Edge AI adds another question: before releasing weights, keys, or data, what evidence shows the runtime and loaded components can be trusted?

Why Edge AI increases exposure

An Edge AI deployment may include models, prompts, agents, retrieval data, policies, local data stores, and update mechanisms running on infrastructure outside the provider’s cloud environment.

This moves sensitive AI assets and decision logic into potentially hostile environments. Attackers may have physical access to devices, local access to model artifacts, opportunities to tamper with retrieval data or tool configurations, compromise model supply chain and more direct paths from model behavior to real-world consequences.

Disconnected Edge deployments cannot rely on live cloud detection, policy updates, or revocation. They must maintain local verification and enforcement when cloud connectivity is unavailable. Risky AI operations should run only where hardware can protect assets and provide acceptable evidence. Otherwise, the operation should be deferred or revalidated.

Why AI changes the security problem

Unlike conventional software, AI models can be influenced by untrusted content while still using legitimate interfaces and credentials. This article focuses on the security response: architectures that constrain model actions and protect the model, credentials, and data around it.

Traditional software executes code developers ship. AI systems can change behavior based on prompts, retrieval data, agent instructions, and other runtime inputs. Protecting code alone is no longer sufficient; organizations must also establish trust in the data, context, and actions surrounding the model.

• Prompt injection can change model behavior. Assume prompt injection will occur, whether direct or indirect. Inputs can affect systems just like executable code because the context window itself acts as an instruction surface. Traditional controls such as signed binaries and code integrity checks were not designed to address this risk.
• Trusted data is not always safe data. Traditional vulnerability management does not map cleanly to “data as code,” such as a poisoned retrieval document. Origin signatures can prove where data came from, but they do not prove that the content is safe for an AI system to interpret.
• AI behavior is not fully deterministic. The same input may produce different outputs, and small context changes can significantly alter behavior. This limits the effectiveness of techniques such as signature detection and fuzzing. Grounding and tuning improve reliability, but they cannot enforce an acceptable risk boundary. At the authority boundaries it mediates, deterministic policy can still constrain actions when alignment, prompt-injection defenses, or content filters fail to stop an unsafe instruction.

Prompt injection, MCP, multi-agent systems, and computer-use agents on Edge expose different surfaces of these problems. Tool calls are delegated authority, agent output is untrusted input, and screen state is input, not authorization.

These characteristics mean organizations cannot rely on traditional software security controls alone. They also need to verify the environment where AI runs and constrain the actions an AI system is permitted to take.

Constrain model actions through deterministic mediation

Model output should recommend actions, not authorize them. A deterministic mediator outside the model enforces policy by allowlisting actions, scoping arguments, limiting frequency, and releasing credentials only when approved. The mediator is a logical boundary, not another model. It may be provided by the platform or integrated by the customer.

In this pattern, the mediator and its credentials are protected and attested. Mediation bounds what the model can do but does not guarantee that every permitted action is safe; high-consequence or irreversible actions require independent approval, an interlock, or fail-safe behavior.

Establish trust before releasing sensitive assets

Organizations must establish trust in the environment where AI runs and in the artifacts that shape AI behavior. Sensitive assets face two theft vectors: at-rest theft from stored artifacts and keys, and runtime theft while a compromised process holds them decrypted. Before release, the verifier asks two questions:

• Do I trust this runtime and the platform on which I am about to execute this workload?
• Do I trust these components, such as model weights, tool descriptors, agent definitions, and retrieval indexes, because I trust the system in which they were built and delivered?

Attestation answers the runtime question. Provenance answers the component question. Verifier policy requires both. Either question alone leaves a gap: an approved runtime can load a poisoned artifact, while a trusted artifact can run on a compromised platform. In this trust model, the build system that produced an artifact is treated as another runtime whose evidence is evaluated, and the chain continues until it reaches hardware the verifier accepts. Evidence comes from across the hardware, firmware, runtime, model, integration, and customer layers. It serves different relying parties: customers containing model behavior, publishers protecting model IP, and integrators validating the supply chain. The verifier combines that evidence to gate release.

Verify runtime before releasing sensitive assets

This pattern evaluates a runtime by whether it is measurable, can report its state, and matches an approved baseline before sensitive assets are released.

Confidential compute provides one way to do this. Without end-to-end confidential computing, a privileged host or unprotected accelerator path may be able to read or modify decrypted weights, credentials, and data. GPU/NPU drivers and DMA extend the trusted computing base beyond ordinary application-security visibility. Where confidential computing covers that path within the platform’s documented threat model, protected memory and hardware-rooted attestation can support release to an approved runtime. This is designed to protect assets from host access; it does not constrain a steered model’s actions through authorized interfaces. Those vectors need additional controls.

Because system state can change after deployment, release is treated as a renewable lease that expires when fresh evidence no longer matches the approved state. Physical controls address what measurement cannot see.

In this pattern, evidence gates scheduler placement, storage, identity, and credential release. Bind credentials to the approved runtime and action scope to reduce the risk that credential theft enables bulk exfiltration; otherwise, evidence does not enforce trust.

Verify artifacts that shape model behavior

Runtime trust proves only that the platform is acceptable; it does not prove that the artifacts loaded into it are trustworthy. A clean runtime can still execute a poisoned artifact.

That is why artifact trust has to be evaluated separately. Because these artifacts shape model behavior, accepting one into the system is more than data transfer. Creation, distribution, deployment, and use can each introduce a tampered artifact.

Model IP can extend beyond weights to provider-owned components that handle them; those components may warrant the same evidence-gated release.

In this pattern, approved components and updates enter through a trusted build environment; on-site changes appear as measurement drift rather than silently becoming a new baseline.

Each artifact should carry evidence of its origin, build pipeline, and input integrity. The verifier evaluates that evidence before accepting it. Provenance should chain to hardware and be produced inside a measured, policy-approved runtime. Signatures establish origin and integrity but may not show whether the producing runtime met verifier policy. Provenance helps responders reconstruct what happened: which model acted on which data, in what runtime, and under which policy.

Next steps

Bottom line: Edge AI changes the trust model for AI systems. Customers operate more of the stack, AI behavior is influenced by runtime inputs, and sensitive assets run in environments outside the provider’s direct control. Attestation, provenance, mediation, and evidence-based release help establish trust before models, data, and credentials are exposed.

Edge AI pushes security controls into devices, gateways, vehicles, factories, hospitals, retail spaces, and other customer environments.

For depth on the agent case, see our post on defense in depth for autonomous AI agents. Map sensitive assets, the runtimes and artifacts that can access them, and the party responsible for each release decision. Then define the evidence and policy required at every boundary. At the Edge, security should be architectural: anchored at hardware, enforced at every action.

The post How to secure edge AI in customer-owned environments appeared first on Microsoft Security Blog.

How Avengers AI Labs Uses Battlefield Data

UK Ukraine AI Partnership Test New Defence Technology

AI Sovereignty and Defence Innovation

The Cyber Expres: Everyone is talking about AI productivity. From a security leadership perspective, what is the biggest shift AI is creating for enterprises?

The Cyber Express: What worries you most about the current pace of AI adoption across organisations?

The Cyber Express: At what point does AI stop being just a productivity tool and become a real enterprise security challenge?

The Cyber Express: Do you think most organisations are prepared for AI-driven cyber threats, or are many still treating AI security as a future problem?

The Cyber Express: What AI-related security incidents do you realistically expect enterprises to face over the next 12 months?

The Cyber Express: AI-generated phishing and deepfakes are receiving significant attention. Have these threats become genuinely dangerous, or are they still more hype than reality?

The Cyber Express: Do enterprises fully understand the risks of feeding sensitive data, business context, or internal information into frontier AI systems?

The Cyber Express: We have seen supply-chain attacks target software and open-source ecosystems. Could AI models, tools, plugins, agents, datasets, and integrations become the next major supply-chain risk?

The Cyber Express: How should security leaders rethink traditional cybersecurity strategies in a world where AI can write code, analyse vulnerabilities, automate tasks, and support attackers as well as defenders?

The Cyber Express: Are existing cybersecurity teams equipped to handle AI-era threats, or does the industry need new skills and operating models?

The Cyber Express: AI vendors promise speed, scale, and automation. Where should organisations avoid over-relying on AI in cybersecurity and business decision-making?

The Cyber Express: If you were advising enterprise leaders today, what are the first three things they should do to prepare for the security impact of frontier AI models?

"AI adoption without governance is not innovation — it is unmanaged risk. The next phase of enterprise security is about controlling what AI can access, what it can do, and who remains accountable." — Mohammad Arif, Head of Information Security, Guild Group

UK researchers reported 19 unsanctioned actions by Anthropic and OpenAI agents during permissive cyber tests involving real external systems.

The post UK AI tests found 19 unauthorized agent actions involving Anthropic and OpenAI models appeared first on TechRepublic.

OpenAI models accessed the public internet during separate third-party cyber evaluations conducted by independent testing partners, prompting the company to review how high-risk AI testing is managed. OpenAI said the incidents occurred under specialized testing configurations with reduced safeguards and did not reflect how its models operate in public deployments. The company added that the events were unrelated to the previously disclosed Hugging Face security incident.

The incidents involved evaluations conducted by UK AISI and cybersecurity testing partner Irregular, where testing conditions or environment configurations enabled models to interact with systems beyond the intended evaluation boundaries.

OpenAI Models Prompt Review of Third-Party AI Testing

OpenAI said independent cybersecurity evaluations are essential for understanding model capabilities before deployment. Some evaluations intentionally reduce safeguards or enable additional capabilities to measure how models perform under conditions that resemble real-world cyber operations.

According to the company, the latest incidents highlighted the need to strengthen the security controls surrounding independent testing environments as AI models become more capable.

OpenAI said it will review how it manages third-party cyber evaluations, including how higher-risk testing is identified, when internet access or reduced safeguards should be permitted, how testing environments should be isolated, and how incident reporting and monitoring procedures should be handled.

The company also plans to work with national AI institutes, independent evaluators, and other AI developers to establish stronger industry practices for high-risk AI evaluations.

UK AISI Identified Two Unsanctioned Actions by GPT 5.6 Sol

On August 3, UK AISI, the UK's AI Security Institute, informed OpenAI that during a cyber evaluation that began on July 25, models from OpenAI and another AI lab performed activities beyond the intended testing scope.

The evaluation used simulated cyber ranges where models acted as cybersecurity experts in a Capture-the-Flag exercise. Internet access was intentionally enabled so agents could download tools similar to those available to real attackers, while cyber classifiers were disabled to measure underlying model capability.

Among 19 recorded events, two involved GPT 5.6 Sol.

According to OpenAI, the model reused a publicly accessible GitHub token left behind by another lab's agent to determine whether systems inside the simulated environment were communicating with GitHub or update services. It also attempted account recovery and request-limit workarounds while registering accounts with external DNS and tunneling providers.

In a separate action, GPT 5.6 Sol used a public tunneling service to expose a locally hosted DNS server from the evaluation environment to the public internet. The server contained exploit payloads intended for a known software vulnerability within the simulated cyber range.

OpenAI said the setup did not function as intended, no evidence indicated that any real internet resolver queried the server, and the infrastructure was removed when the evaluation concluded.

UK AISI considered both actions outside the authorized testing boundary because they involved external services that were not required to complete the exercise.

Security monitoring detected unusual data transfers on July 28. UK AISI halted the evaluation, isolated the affected systems, and contained the activity within approximately one hour.

Irregular Finds Misconfigured Testing Environment

A second incident was reported on July 29 by Irregular, another organization conducting third-party cyber evaluations for OpenAI.

The testing environment was intended to remain isolated from the internet during another Capture-the-Flag exercise. However, a configuration error unintentionally allowed the models to access external websites.

During one evaluation, the fictional domain used in the exercise matched an actual website. Because internet connectivity was available, the model interacted with the live site, believing it was part of the simulated challenge.

Irregular said the incident did not involve a sandbox escape or zero-day exploit. Instead, the model exploited a basic security vulnerability on the website after gaining unintended internet access.

The investigation also found that the model used credentials associated with the same website. According to Irregular, no impacts beyond that site's own data have been identified, although its audit remains ongoing.

The organization has paused the evaluations, completed remediation, notified affected third parties, and implemented additional safeguards in its testing environment.

OpenAI said it will continue working with both UK AISI and Irregular to improve evaluation practices while ensuring independent cybersecurity testing remains rigorous as AI capabilities continue to advance.

Anthropic Cybersecurity Evaluation Traced Issue to Testing Environment

Three Incidents Involving Claude AI Models 

Anthropic outlines Lessons from Cybersecurity Evaluation 

Most AI safety testing still happens inside the walls of individual organizations. That has resulted in a fundamental disconnect: many of the highest-risk failure modes in modern AI systems require deep domain expertise, multilingual context, or regional understanding that no single internal team can fully replicate on its own. 

As frontier models become more capable, the attack surface expands with them. AI red teaming is no longer just about prompt injection or content safety edge cases. It increasingly involves security operations, misuse scenarios, multilingual harms, alignment failures, and domain-specific abuse patterns that can vary significantly across geographies and languages. 

Microsoft’s AI Red Team has observed that meaningful testing of advanced AI systems- and models similarly requires broader participation from researchers and practitioners who operate outside traditional corporate security boundaries. To address that gap, today we are announcing the External Red Team Alliance (EXTRA), a formalized global extension of Microsoft’s AI Red Team designed to support and encourage external expertise to advance AI safety and security testing.  We are proud to share we are funding the development of new AI safety assessments on six continents through unrestricted gifts. 

Building a global alliance

EXTRA is a two-part initiative focused on expanding AI safety research and strengthening external collaboration. 

The first component supports a global academic network focused on advancing AI safety and security research. Microsoft’s AI Red Team has provided unrestricted gifts to 18 university labs spanning six continents. The goal is intentionally broad: support researchers who are already investigating difficult, unresolved questions in AI safety and help them continue pushing that work forward independently. 

Some of the supporting institutions include: 

• Carnegie Mellon University Security and Privacy Institute (CyLab), United States 

• Georgetown University – Georgetown Security Lab (SecLab), United States 

• Harvard University Berkman Klein Center for Internet & Society (BKC), United States 

• Howard University Research Institute for Tactical Autonomy (RITA), United States 

• Indian Institute of Technology Madras – Centre for Responsible AI (CeRAI), India 

• Korea Advanced Institute of Science & Technology – KAIST Web Security & Privacy (WSP) Lab, Korea 

• New York University – NYU Alignment Research Group (ARG), United States 

• Northeastern University Network and Distributed Systems Security (NDS2) Lab, United States 

• University College London – UCL Information Security Research Group (UCL ISec), United Kingdom 

• University of Cagliari Pattern Recognition and Applications (PRA) Lab, Italy 

• University of California – Berkeley Risk and Security Lab; Center for Responsible, Decentralized Intelligence (CRDI), United States 

• University of Melbourne Artificial Intelligence Assurance Lab, Australia 

• University of Pretoria Data Science for Social Impact (DSFSI) Research Group, South Africa 

• University of São Paulo Center for Artificial Intelligence (C4AI), Brazil 

• University of Toronto CleverHans Lab, Canada 

• University of Washington Department of Human Centered Design & Engineering (HCDE), United States 

The second component of EXTRA focuses on operational collaboration. Microsoft is building a distributed network of specialists who can participate directly in red teaming highly specialized areas where deeper expertise is required. That includes researchers, practitioners, and regional experts who understand specific attack classes, languages, cultural contexts, or technical domains that internal teams may not fully cover alone. 

Beyond expanding participation, EXTRA is also intended to help advance the science of AI safety evaluation. By bringing together academic researchers, security practitioners, and domain experts from around the world, the initiative aims to contribute to the development of more robust methodologies and testing practices for increasingly capable AI systems. Today’s cybersecurity ecosystem depends on coordinated vulnerability research, responsible disclosure programs, academic inquiry, and global communities of independent security researchers who routinely identify risks that vendors alone would not find. Likewise, advancing AI safety will benefit from ongoing contributions from experts across institutions, disciplines, and geographies to identify emerging threats, strengthen safeguards, and improve evaluation practices. 

What the research focuses on

The research areas funded through EXTRA reflect several of the emerging areas Microsoft’s AI Red Team continues to encounter when evaluating advanced AI systems. 

Some universities are examining the cybersecurity implications of AI systems themselves — including how models can be attacked, manipulated, or abused in operational environments. Other labs are exploring the inverse problem: how AI systems can assist defenders and improve cyber operations. 

The structure of the program is intentional. The funding is unrestricted because the objective is not to direct research outcomes toward product requirements or predefined deliverables. The goal is to strengthen independent safety research capacity globally and create stronger long-term collaboration between academia and operational AI security teams. 

Why this matters

“Managing frontier AI risk requires more than internal safeguards. It requires continuous engagement with experts who understand how these systems behave across different technical, linguistic, and cultural contexts. EXTRA reflects Microsoft’s broader Frontier Governance Framework approach: combining rigorous internal governance with external support and collaboration to better identify, assess, and mitigate emerging risks as AI capabilities advance. By supporting independent research and building stronger connections with universities and specialists around the world, we are helping strengthen the broader ecosystem needed for trustworthy and secure AI development,” says Natasha Crampton, Chief Responsible AI Officer, Microsoft 

Governments too are increasingly focused on understanding the capabilities and security implications of frontier AI systems to strengthen resilience. But just as coordinated international research helped unlock the benefits of previous technological revolutions, diverse expertise from researchers and practitioners around the world is essential to identify emerging threats, improve defenses, and build greater confidence in AI systems.   

“Frontier AI is already shaping the future of both cybersecurity and national security. Understanding how these systems can be misused, and identifying risks before they become real-world threats, requires expertise that spans institutions, disciplines, and borders.” says Mike Yeh, VP & Deputy General Counsel, Customer Security and Trust, Microsoft 

AI red teaming is becoming more interdisciplinary, multilingual, and globally distributed. The expertise needed to identify meaningful failure modes increasingly lives across universities, independent research communities, and regional specialists. 

EXTRA reflects a practical shift in how AI security testing must operate going forward. External expertise is no longer supplemental to red teaming; in many cases, it is essential. 

Microsoft would like to thank these people for their important contributions with this project: Steph Ballard, Blake Bullwinkel, Nicholas Butts, Janelle Bryant, Kaja Ciglic, Hector de Rivoire, Eugenia Kim, Amanda Minnich, Shujaat Mirza, Jingxia Ni, Saphir Qi, Giorgio Severi, Hilary Solan, Hiwot Tesfaye, Sam Vaughan, Marguerita Wicklander, and the many teams at these schools around the world who helped coordinate 

The post Enhancing AI security through global AI red teaming appeared first on Microsoft Security Blog.

OpenAI is set to launch GPT-5.6 after a US security review, raising new questions for enterprise AI access, safeguards, and governance.

The post OpenAI’s New GPT-5.6 Is Coming Sooner Than You Think appeared first on TechRepublic.

Hackers claim they stole 1.3TB of Novo Nordisk data, including clinical trial and AI model information, after issuing a $25 million demand.

The post Ozempic Maker Novo Nordisk Confirms Security Incident After $25M Hacker Demand appeared first on TechRepublic.

Explore how LLM proxies secure AI models by controlling prompts, traffic, and outputs across production environments and exposed APIs.

The post What Is an LLM Proxy and How Proxies Help Secure AI Models appeared first on Security Boulevard.