Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
The iPhone of Vladan Đokić, rector of the University of Belgrade and a prominent supporter of Serbia's student protest movement, was infected with NSO Group's Pegasus spyware in 2026, the Citizen Lab said on October 19.
The finding came six days before Serbia's October 25 snap parliamentary election. The infection used a zero-click exploit, meaning Đokić did not have to tap a link or open a file for it to work.
The lab found the infection with high confidence, but its note provides no date within 2026, does not identify who was behind the attack, and notes that its investigation is ongoing.
The election was called in September after nearly two years of protests that began when a railway station canopy collapsed in Novi Sad in November 2024, killing 16 people.
The Citizen Lab, a research group at the University of Toronto, analyzed forensic artifacts from the phone at Đokić's request, working with the Serbian digital-rights group SHARE Foundation. SHARE led the investigation of an earlier wave of Serbian cases made public in September.
A second case concerns Rade Bajić, a senior prosecutorial associate at Serbia's Public Prosecutor's Office for Organized Crime who worked on the "Generalštab" corruption investigation into a Kushner-linked property project in Belgrade. Bajić received an Apple Threat Notification on August 13 and a reminder on August 27.
Apple sends these alerts when it detects activity consistent with an attack by mercenary spyware, the commercial hacking tools that companies such as NSO sell to governments, and it does not say who is behind the attacks.
The Citizen Lab treats a notification as a high-confidence sign that Bajić's phone was likely targeted. Its forensic analysis of the device is ongoing, and the note does not say whether the phone was infected.
The Generalštab case concerns the removal of heritage protection from Belgrade's bombed-out former army General Staff complex to clear the way for a luxury development backed by a company linked to Jared Kushner, U.S. President Donald Trump's son-in-law.
In December 2025, prosecutors charged Culture Minister Nikola Selaković and three other officials with abuse of office and falsifying documents in the case, the Associated Press reported. Bajić says he was taken off the investigation in November 2025 without explanation, and in February he spoke about the case at a protest called by student activists outside Serbia's Constitutional Court.
The lab's note does not say what, if anything, was taken from the rector's phone. Pegasus gives whoever operates it the same access as the phone's owner, including private and encrypted messages, and can switch on the microphone and camera without the owner knowing, according to the lab's analysis of the September case.
Đokić called the spyware on his phone "another attempt of intimidation" in an English-language statement published by the university, and demanded an independent investigation without delay, with its results made public and whoever installed and used the spyware prosecuted. Police raided the rector's offices on March 31 and seized computers and servers, he said at the time.
The Security Information Agency (BIA), Serbia's civilian security service, dismissed the September allegations that students and opposition politicians had been spied on as "purely trivial sensationalism" in a statement on September 3, as translated by the broadcaster N1, and said it operates strictly within Serbian law.
The two cases extend a wave that SHARE reported on September 2, when it said at least 14 people in Serbia, including student activists, an opposition MP and a local councilor, had been targeted with spyware since the start of the year. Twelve of them had received Apple Threat Notifications in August, the month Apple warned users in 110 countries.
One was Jelena Kontić, a student whose Pegasus infection the Citizen Lab confirmed. The other two had a new version of NoviSpy, an Android spyware, installed on their phones.
By the Citizen Lab's count, the two new cases bring the number of people in Serbian civil society publicly known to have been targeted or infected with mercenary spyware this year to at least 16.
Amnesty International reported in December 2024 that NoviSpy was configured to send stolen data to a server whose IP address belonged to the BIA and was installed on activists' and journalists' phones during police questioning, after the devices were unlocked with Cellebrite forensic tools.
Lawyers for Kontić filed a criminal complaint on October 6 against unidentified individuals in the BIA and the police, as well as people responsible at NSO Group. Pegasus is sold only to governments and state agencies, SHARE says, and the complaints already filed over spyware in Serbia have brought no effective action.
The note does not name the flaw used against Đokić's phone or say whether current iOS releases block it, so there is no case-specific fix to install. The lab's advice for people at risk because of who they are or what they do:
If you receive an Apple Threat Notification, assume the phone is infected until an expert has checked it, and get help at once: SHARE Foundation in Serbia, or Access Now's Digital Security Helpline elsewhere.
Have close contacts, such as family members and people they work with, screened for spyware too.
from The Hacker News https://ift.tt/cuOS4m8
via IFTTT
ConnectWise on Monday said it has taken remediation measures, including strengthening administrative-access protections and resetting accounts and replacing application credentials, as it continues to respond to a security incident that led to unauthorized access to application identities associated with Cloud Backup.
The company said it has completed the following actions since it began rolling out mitigations on October 17 at 5:00 a.m. UTC, three days after the incident was first identified -
Disabling affected application connections and suspending Cloud Backup.
Suspending SaaS Security and Cloud Management as a precaution because they are integrated with Cloud Backup.
Enlisting the help of independent third-party specialists for incident response and remediation.
Enhancing administrative-access protections.
Publishing technical guidance to help partners investigate and remediate potential unauthorized activity in their own and managed customer environments.
ConnectWise said it's validating the effectiveness of its containment measures and emphasized that it has not seen any successful threat activity in the environments it monitors. There is no evidence that any ConnectWise products and services, other than Cloud Backup and the precautionary suspensions of SaaS Security and Cloud Management, are impacted.
"This observation does not establish whether individual partner or customer Microsoft 365 tenants have been affected," it said. "Reviewing each potentially affected tenant remains essential."
"Before making changes, preserve relevant evidence, validate findings, and assess potential operational impacts. Completing these steps does not guarantee that a tenant is unaffected or that all unauthorized access has been eliminated. Do not reconnect affected applications until ConnectWise provides formal restoration instructions."
Huntress has shared the following IP addresses observed in connection with the activity, adding that the password spray and failed login attempts linked to some of them are unlikely to be related to the application sign-in activity -
144.172.64[.]128 - Application sign-ins with a vendor credential (primary vector)
144.172.64[.]99 - Failed user password spray, concentrated (October 10 to 14, 2026)
144.172.64[.]60 - A few failed user logins (October 18, 2026)
144.172.94[.]243 - Broad failed login spray, ongoing against many organizations
"In a review of application sign-ins across more than 10,000 tenants with ConnectWise applications (where we can see those logs), 144.172.64[.]128 and Microsoft-internal ranges are the only addresses that produced application sign-in activity," Huntress researchers said in an update.
"We did not see application sign-in activity from any of the other addresses listed below, all of which are in the same provider range as 144.172.64[.]128 (AS14956, RouterHosting). We did see password spray and failed login attempts from some of them."
The cybersecurity company said it also observed post-compromise actions on a second tenant, following the same modus operandi as before, in which the application granted itself Global Administrator and then added a new secret on a small number of other applications in the tenant for persistence.
While the access may have been used for Microsoft Graph directory reads, there are no signs the attackers weaponized it for mailbox or file manipulation, or to make user or policy changes.
"The choice of which applications to backdoor appeared to be random in the two tenants we reviewed," Huntress added. "Across the two compromised tenants, the identical grant flow selected two completely different sets of applications. The only consistent criteria we can point to is structural: credentials were planted in applications that are registered inside the affected tenant, without regard to what those applications can actually do."
from The Hacker News https://ift.tt/BNaSgAf
via IFTTT
An attacker used a contributor's GitHub account to replace the download archives on five existing releases of OVHcloud's command-line tool on Monday, October 19. The account had been hijacked, and the new files were a build designed to steal secrets stored on the disk of any machine that runs it, the cloud provider says.
They were live on GitHub for up to 94 minutes, from 12:47 to 14:21 UTC, and reached only people who installed or updated the OVHcloud CLI during that window, via a path that checks for no hash, on macOS, Linux x86_64 or arm64, or Windows x86_64.
OVHcloud deleted the swapped archives and published a clean v0.16.0 that evening as an immutable release, whose files GitHub will not let anyone change. The source code, the release tag, and the company's build pipeline were not touched: the bad build was a plain go build of a later commit, uploaded straight onto releases published between April and September.
Who Was Exposed
On v0.15.0, the attacker replaced six files: the macOS x86_64 and arm64 archives, the Linux x86_64 and arm64 archives, the Windows x86_64 archive, and the checksums.txt file, so the published hashes matched the new binaries. The same six files are now gone from v0.11.0 to v0.14.0 as well. The Linux i386, Windows i386, Windows arm64, and WebAssembly builds were left alone on every release.
OVHcloud lists v0.11.0 through v0.15.0 as compromised and v0.10.0 as clean. Those five releases were published between April 14 and September 16, so a copy installed before 12:47 UTC on Monday and not updated since is the original.
You got a swapped file if, in that window and on one of those platforms, you:
Ran the official install script (curl -fsSL https://ift.tt/iFVApDX | sh). It downloads the latest release archive and installs it, and has never checked a hash.
Downloaded an archive from the GitHub release page of any of the five releases.
Ran a CI job or build step that fetches the archive from the release download URL without a pinned hash.
Ran the CLI's own upgrade command from a v0.12.0, v0.13.0, or v0.14.0 install on a macOS or Linux machine where the tool was installed by the script or by hand. The command downloads the archive and replaces the binary with no hash check. On a Homebrew or go install setup it only prints the command to run instead.
You did not get it if you:
Installed with Homebrew, whose cask in force during the window pinned the original SHA-256 of each archive. Homebrew refuses a download whose hash does not match, so brew install or brew upgrade would have failed rather than installed the swapped file. Some early write-ups listed Homebrew among the exposed paths, but The Hacker News checked the tap's commit history: nothing changed between the v0.15.0 cask on September 16 and the v0.16.0 cask on Monday evening.
Used go install or built from source. The v0.15.0 tag still points at its September commit, 760fd72.
Pulled the Docker image. Its latest tag was last pushed on September 21, four weeks before the swap, and had not been rebuilt as of Tuesday.
Installed before 12:47 UTC on Monday and did not update during the window.
How to Tell
The customer who caught the swap pulled the build information out of the new v0.15.0 Linux arm64 binary with go version -m, which reads the file without running it, and posted it in a GitHub issue. Three things mark the bad build:
The module line reads v0.15.1-0.20261013083505-5ead8ef9b43d+dirty, a pseudo-version, the stand-in string Go generates for a build from an untagged commit, here one from October 13. A genuine release carries its tag number: OVHcloud's clean v0.16.0 build reads v0.16.0+dirty.
The recorded commit is 5ead8ef, not 760fd72, the commit the v0.15.0 tag points to.
A -ldflags="-s -w" line is present. OVHcloud's release pipeline builds with a version flag that Go leaves out of the recorded flags, so a genuine release shows no -ldflags line at all.
Advice circulating that any build marked +dirty, or carrying vcs lines, is the malicious one would flag OVHcloud's own release. The Hacker News ran the same command on the clean v0.16.0 Linux x86_64 binary: it reports v0.16.0+dirty, vcs.modified=true and the commit it was built from.
The only published hash of a swapped file is the v0.15.0 Linux arm64 archive:
A build without the version flag would report its version as undefined, but running a suspect binary to find out is not advisable.
What to Do
OVHcloud founder Octave Klaba wrote on X on Monday evening that anyone affected should change every secret stored on the disk. =
The CLI keeps OVHcloud API credentials in ~/.ovh.conf and reads them from environment variables, according to its documentation, and the advice covers everything else on the disk, not only those files.
If you ran a swapped build, or cannot tell, treat every secret readable from that machine as exposed and rotate it. OpenSourceMalware, which investigated the incident, adds: do it from a different machine.
Remove the binary and install v0.16.0. The release is immutable and carries a release attestation, a signed record of its files. Updating replaces the program but does not revoke a key that was already copied, which is why the rotation comes first.
Check a downloaded archive against the release with gh release verify-asset v0.16.0 FILE, as GitHub documents.
OVHcloud has not said which files the binary reads, where it sends them, or how many copies were downloaded, and no copy of a swapped archive has been analyzed in public. The company has promised a detailed postmortem in the coming days.
How It Happened
Anyone with write access to a GitHub repository can delete the files attached to a release and upload new ones with the same names, and the download URL does not change unless release immutability is enabled.
OVHcloud had not enabled it. In a second post on Monday night, quoted by Next, Klaba wrote that the problem stemmed from the immutability option not being activated, so a user with the right permissions could modify existing releases directly on GitHub without any checks by the company's CI/CD pipeline. The option has now been enabled, and the pipelines themselves were not affected.
The five old releases now offer only the four archives the attacker did not touch.
The uploads came through the account of a contributor whose merged work is in OVHcloud's documentation repository and who is not a public member of the organization, according to OpenSourceMalware, which built a timeline from GitHub's server-side records.
The release workflow never ran: the run list shows no workflow between October 16 and the v0.16.0 tag push at 16:00 UTC on Monday. First checks found no other repository affected, Klaba wrote in his first post, and OVHcloud has not said how the account's credentials were taken.
A customer's CI job caught the swap because it pins the SHA-256 of the Linux arm64 archive and began failing. With no private reporting channel on the repository, the customer filed a public issue, at 13:50 UTC by OpenSourceMalware's timeline, and OVHcloud deleted the swapped files about half an hour later, at 14:21 UTC (16:21 in Paris). v0.16.0 followed at 17:16 UTC, published under the company's ovh-cds account with a signed tag.
The GlassWorm Question
OpenSourceMalware ties the account to GlassWorm, the malware campaign that hides code in invisible Unicode characters and fetches its next stage from the memo field of a Solana wallet's transactions. Four of the account's personal repositories were force-pushed on March 5 and 6 with an amended commit that added a loader of that kind, the researchers found.
The wallet that loader reads is the one named in GlassWorm's ForceMemo campaign, which force-pushed malware into hundreds of Python repositories in March with stolen GitHub tokens. The Hacker News confirmed that the loader file is still in one of those repositories, with the hash the researchers published.
Whether the same actor did both is "our inference," the researchers wrote. The shared account is the link, and nothing from the October binary has been tied to GlassWorm, because no copy of it was preserved.
from The Hacker News https://ift.tt/PWB7FoN
via IFTTT
Siemens has addressed a DLL sideloading vulnerability impacting Siemens Software Center that it said has been exploited in ClickFix attacks.
The high-severity vulnerability, tracked as CVE-2026-110936 (CVSS v4 score: 8.4), could allow an attacker to place a specially-crafted DLL in a directory the application searches, resulting in execution of malicious code with the same privileges as the affected service.
"The affected application loads dynamic-link libraries (DLLs) from an uncontrolled search path," Siemens said in an advisory. "This could allow an authenticated local attacker to place a specially crafted DLL in a directory that the application searches, leading to arbitrary code execution with the privileges of the affected application."
The issue has been patched in version 4.0.9.8. Huntress Labs researcher Jose Oregon has been credited with discovering and reporting the shortcoming.
In a separate alert, Siemens said attackers have abused a genuine copy of Siemens Software Center with a valid signature and placed their own crafted DLL ("archive.dll") next to it to trigger the execution of malicious code.
"They chose this program as a carrier because it is signed and trusted, and because version 3.5.8.7, the latest version at the time, loaded helper files from its own folder without checking them," Siemens added.
Specifically, threat actors have been found leveraging "msiexec.exe" to launch "AllMyBasic.msi," which then executes msiexec. The activity has been attributed to a ClickFix delivery platform called Romulus, which was detailed by Forescout last week as being used to deliver Legion Loader and other malware using DLL sideloading.
According to Huntress, some of these campaigns have leveraged malicious ChatGPT Custom GPTs to direct victims to a fake URL responsible for serving a ClickFix lure, which when copied and executed by the victim, runs PowerShell code to drop an MSI installer that abuses DLL sideloading to ultimately deploy a remote access trojan.
Siemens has shared the following indicators of compromise -
96.62.218[.]59 (Payloading hosting and command-and-control)
wizardexpensive[.]com (Payloading hosting and command-and-control)
2.27.248[.]127 (Distribution channel of AllMyBasic.msi)
Besides updating Siemens Software Center to version 4.0.9.8 or later and starting the application to apply the update, organizations are advised to block the IP addresses and domains associated with the malicious activity and look for "SiemensSoftwareCenter.exe" running from "AppData\Local\Programs" and started by "msiexec.exe."
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/bHT2zQw
via IFTTT
A U.S. court on Monday granted the U.S. government's request to detain a former OpenAI engineer accused of planting a recording device in an executive conference room at the company's San Francisco office to allegedly steal sensitive secrets.
In a new court filing Sunday, prosecutors revealed that Abdulrahman Alfozan, a 35-year-old Saudi national, was "in frequent communications via WhatsApp with a member of the Saudi Royal Family" throughout 2025 and 2026. Alfozan is said to have communicated with the Saudi royal as recently as October 5, 2026, four days before he was arrested.
"Among other things, the individual told the defendant that an artificial intelligence initiative was being launched in Saudi Arabia and wanted the defendant to join it," the filing reads. "In May 2026, the individual told the defendant, 'Saudi needs you more then [sic] the US!' to which the defendant responded '100,' indicating he agreed."
The Saudi Royal Family member is said to have repeatedly attempted to recruit Alfozan and even asked when he planned to leave OpenAI, to which the defendant said he wouldn't do so until his stock vested.
Alfozan joined OpenAI as an engineer around July 2025 with an annual base salary of $385,000. Last week, the U.S. Department of Justice (DoJ) revealed that he had been arrested for allegedly inserting a stealthy audio recording device into a USB port on the back of a television in the executive conference room to capture sensitive conversations.
The 35-year-old defendant is also said to have modified the device to prevent data transfer between it and the television and encrypted the content stored on the device's microSD card. In addition, he used his wife's personal ChatGPT account to research how to "build a continuous audio recorder" to "captur[e] microphone audio and save compressed WAV recordings to an SD card."
"In the days and weeks before placing the device, the defendant (i) used an OpenAI productivity agent to ascertain which 'meeting rooms' OpenAI 'leadership and exec[utives]' used, and where they met with 'external partners'; and (ii) spent considerable time near the conference room where he later installed the device," the filing said.
Alfozan has been charged with using or endeavoring to use an electronic, mechanical, or other device to intercept oral communications. If convicted, he faces a maximum possible sentence of five years in prison.
Prosecutors also argued that Alfozan is a flight risk, stating he has "ample resources... and what appears to be considerable support from a foreign government that has (i) no extradition treaty with the United States; (ii) limitless resources; and (iii) the ability to provide extraordinary travel assistance," according to the filing.
Shortly after details of his arrest became public knowledge, it emerged that the defendant had planned to depart to Riyadh with his wife and son on a one-way ticket on October 12, 2026. Although he was arrested three days prior, his wife and son are said to have already left the U.S. without him.
The day before her departure, Alfozan's wife allegedly told the U.S. Federal Bureau of Investigation (FBI) agents that her U.S. visa was expiring and that she, along with her son, were permanently shifting back to Saudi Arabia.
"The defendant went to significant lengths to create customized, encrypted recording devices to secretly record highly sensitive meetings involving senior OpenAI personnel and executives, high-level business counterparts, and government officials, all while communicating with individuals of significance in Saudi Arabia and pursuing opportunities in – and making plans to travel to – Saudi Arabia," the filing said.
Stating the U.S. government's investigation is ongoing, prosecutors said a search of the defendant's residence and a "preliminary review" of his electronic devices, including his cellphone, uncovered several pieces of evidence -
Several electronic components similar to those in the customized devices the defendant installed in the OpenAI conference room and had in his missing bag were identified in his residence.
Photographs from his iPhone dated between September 22 and 28, 2026, that depict one additional concealed recording device, as well as what appear to be the input/output panels on TVs and other electronic devices in various locations in OpenAI buildings, including a second conference room where sensitive meetings took place.
A deleted note on his cellphone from September 2026 included links to various recording devices, including those made by Seeed Studio, the same manufacturer whose devices were found in OpenAI's offices and his residence.
Browsing history showed that the defendant accessed a folder called "Saudi Gov Docs" on October 4, 2026, and he used an OpenAI productivity agent to inquire about various Saudi-related business and government-related engagements from the Saudi Ministry of Communication and Information Technology (MCIT) between July 6, 2026, and September 21, 2026.
"The defendant leveraged his skills as a highly-educated engineer to create sophisticated recording devices that – the evidence strongly suggests – he intended to bring with him to Saudi Arabia," the filing said.
"Whether the defendant wanted to record OpenAI meetings to enrich himself by enhancing his own business prospects, or to provide aid a foreign government, or both, his conduct is criminal and it presents a danger to innovation in the Silicon Valley and a concern for the national security of the United States."
from The Hacker News https://ift.tt/e8tKfJN
via IFTTT
Cybersecurity researchers have disclosed details of a ClickFix delivery platform called ROMULUS that's being used to distribute malware such as Legion Loader.
According to Forescout Research - Vedere Labs, ROMULUS is akin to a malware delivery service that employs ClickFix-style lures on bogus landing pages to trick unsuspecting users into running malicious commands and infecting their own machines.
"ROMULUS may be a privately operated panel, a commercial cybercriminal delivery service, an affiliate framework, or software that has been copied between operators," security researcher Sai Molige said in an analysis.
The cybersecurity company said it identified six IP addresses running ROMULUS -
96.62.224[.]81
86.109.75[.]7
151.240.151[.]223
23.94.145[.]224
93.152.224[.]118
2.27.248[.]127
Notably, the IP address "96.62.224[.]81" was identified as hosting a ClickFix script and an MSI installer file in connection with another campaign that has been found to leverage malicious ChatGPT Custom GPTs to direct victims to a fake URL responsible for serving the ClickFix lure.
Forescout's own analysis has since uncovered the same malware being delivered via another server, 86.109.75[.]7, that also hosted a panel codenamed ROMULUS. In addition, a separate chain triggered via ClickFix has been used to run a PowerShell script, which then delivers Legion Loader, a malware loader also called Satacom downloader, CurlyGate, and RobotDropper.
As of writing, it's not known who is behind the ROMULUS platform. However, it shares no overlaps with RomulusLoader, a malware family associated with Silver Fox (aka TA4922), a China-aligned threat actor known for repeatedly using tax-related pretexts to distribute remote access trojans like ValleyRAT (aka Winos 4.0), DcRAT, and potentially Venom RAT via DLL sideloading techniques.
The ROMULUS platform exposes two endpoints that are designed to download a PowerShell staging script, which decides the payload to be fetched next: a trojanized MSI installer carrying a malware loader or an encrypted archive containing Legion Loader. The loader, for its part, communicates with a remote server to fetch and run additional payloads.
The findings indicate how ClickFix is evolving beyond a social engineering technique into a highly effective entry point for malware. To mitigate the threat, it's essential to hunt for suspicious PowerShell commands and DLL sideloading events.
from The Hacker News https://ift.tt/YzTnBUO
via IFTTT
The worst problems don't always come with a warning. Sometimes they arrive through a service everyone trusts, a device someone bought, or a system nobody thought to check. By the time something looks wrong, the damage may already be done.
This week had plenty of that. Trusted connections became a problem. Hardware wasn't as safe as it looked. Old bugs found new victims, and some systems were left so exposed that breaking in barely required any effort. Even AI agents crossed lines they weren't supposed to.
Some attacks were clever. Others were painfully simple. The full recap shows just how much can go wrong, and how little it sometimes takes.
⚡ Threat of the Week
ConnectWise Suspends Cloud Backup Following Unauthorized Access— ConnectWise disabled seven ConnectWise application identities as it continues its investigation into an incident in which unknown threat actors obtained unauthorized access to the application identities and compromised Microsoft 365 tenants. The IT management software provider said it took the action on October 17, 2026, at 07:00 UTC, adding it has also suspended Cloud Backup service by revoking certificates used for affected application connections across all users.
🔔 Top News
BeyondTrust Remote Support Flaw Exploited as 0-Day— The China-nexus cyber espionage group tracked as Armory Castle (previously UNC5221 or Warp Panda) exploited a newly disclosed security flaw in BeyondTrust Remote Support (formerly Bomgar) as a zero-day in late August 2026. The vulnerability, tracked as CVE-2026-102764 (CVSS score: 9.3), is a case of improper origin validation in an internal messaging component that could be exploited by a remote attacker to perform file operations on an affected appliance. According to Google-owned Mandiant, the attack involved the deployment of a lightweight PHP web shell codenamed SAWFLY for interactive remote access and a tunneling program called BARECLAW to route traffic through the device. Only a small number of organizations are assessed to be impacted.
Microsoft Disrupts 3 Phishing Kits Linked to Over 1 Billion Scam Messages— Microsoft says it has dismantled a criminal marketplace that sold three phishing kits, namely CoGUI (aka NX or FA), Haozi (aka Phoenix), and Iron Man System, that were responsible for sending over 1 billion malicious messages to more than 75,000 organizations worldwide. Redmond said it took down Yam Store (aka Storm-3119), a coordinated underground network that offered commercial phishing-as-a-service (PhaaS) toolkits that allowed other threat actors to readily purchase and deploy phishing pages and steal data and credentials. The kits were also capable of advanced evasion, such as geofencing, fake CAPTCHA gates, IP address blocklists and allowlists, and anti-detection configurations. Yam Store functioned as an initial access broker, peddling not just phishing kits but also infrastructure built on compromised or fraudulently obtained Microsoft and Google cloud environments.
Ledger Finds Unauthorized Hardware Implants— Cryptocurrency hardware maker Ledger temporarily paused sales of its products via CryptoBilis and other third-party resellers in Southeast Asia and Germany after a backdoor embedded into a handful of wallets led to the theft of an estimated $100 million in cryptocurrency. The implants are said to be an advanced version of a backdoor that hardware hacker Joe Grand found earlier this year and notified Ledger in March 2026. It's not clear how this occurred, but signs point to a compromise of Ledger's supply chain. One of the victims of the incident is a fraudster who engaged in a task scam and lost more than $4.8 million. "In this task scam, people were paid to fake sales and reviews of real items," Chainalysis said. "Then a 'negative balance' appeared, and they were told to add their own money in order to get paid. On Sep 22, the person behind the scam moved the proceeds into three separate Ledger addresses. On Oct 9, thieves emptied all three. One transfer each, into the same wallet." According to cybersecurity journalist Kim Zetter, Trezor wallet devices sold by third-party non-authorized sellers have also been found to contain implants that generated pre-determined seed phrases so as to allow the attackers to guess them easily and gain access to the accounts.
Pwn2Own Ireland Demos 98 0-Days— The Pwn2Own Ireland 2026 hacking contest saw white-hat hackers exploiting 98 zero-day flaws, earning them a collective $1,262,000 in rewards. Ikotas Labs came first with 42.5 Master of Pwn points and $361,000 in cash after discovering 12 unique bugs. Xint and Team ZyGoat secured second and third spots. Ikotas Labs, Xint, and Mobile Hacking Lab broke into Google's Pixel 10, earning them $150,000, $300,000, and $112,500, respectively. Vendors are expected to patch the zero-days disclosed during the competition within 90 days before the details are publicly disclosed.
OpenAI Disclosed New Misalignment Cases— OpenAI said internal models hacked more websites, bypassed browsing restrictions, and used cryptocurrency from a wallet it couldn't otherwise access, in the latest set of disclosures where its agents carried out unethical and likely illegal acts. In all, the company reported seven new incidents. The development came as the Indian Computer Emergency Response Team (CERT-In) said it received "multiple voluntary disclosures from AI model providers" whose models, during research and evaluation runs on the open internet, accessed personal data from Indian organizations. The agents found their way in through credentials and connection settings left exposed in app configurations, public code repositories, and overly permissive cloud roles. CERT-In did not name the providers or affected organizations.
OpenAI Engineer Charged— The U.S. Department of Justice charged an OpenAI engineer, Abdulrahman Alfozan, with attempting to intercept oral communications after allegedly planting a recording device in an executive conference room. Prosecutors claimed company security staff found a second device in his bag. CCTV footage placed the defendant near the conference room on several dates. Alfozan allegedly had no authority to access or participate in meetings held in the room, which is often reserved for the highest-level discussions. In a subsequent filing, federal prosecutors revealed that Alfozan had booked a one-way ticket from San Francisco to Saudi Arabia with his wife and a third family member before his arrest on October 9, 2026.
Attacks on French Refrigeration Systems— Cyber attacks on Danfoss- and Copeland-managed refrigeration systems pushed temperatures as high as 50°C (122°F) for roughly six hours, impacting over 700 French supermarkets and forcing them to discard food. French cybersecurity authorities advised supermarkets to disconnect them from the internet. The attacks targeted Intermarché and Netto, Coopérative U, Carrefour, Monoprix, and E.Leclerc. The affected systems are said to be internet-facing and running outdated firmware. "The username is admin and the password changes every day automatically to.. the current date," security researcher Kevin Beaumont said. "Every single one is like this. You can just log in and change the temperature. Anybody can do it, easily scriptable." To make matters worse, the affected stores likely also failed to put the devices behind a VPN and create an allowlist of trusted IP addresses permitted to log in. "Two things would have changed the outcome," Pen Test Partners said. "Cyber hygiene would have prevented the access: take the controller off the public internet, put remote access behind a VPN and an IP allowlist, bring third-party kit onto the network in a controlled, owned and documented way rather than leaving it on a contractor's own connection, change known and default credentials, and patch to a current release." Multiple vulnerabilities have been disclosed in the affectedmodels, with Claroty warning that the issues could be exploited to "defrost the food."
Collabora RCE Flaw Exploited to Backdoor Nextcloud Servers— Threat actors are exploiting a critical command execution flaw, tracked as CVE-2026-110447 (CVSS score: 9.2), in the Collabora Online - Built-in CODE Server app for Nextcloud to backdoor servers. It has been patched in version 26.4.303. The attacks involve issuing a malicious request to the app's "proxy.php" endpoint to trigger command injection and plant a PHP web shell with the end goal of conducting reconnaissance and searching for password databases, password manager artifacts, and cryptocurrency wallets.
️🔥 Trending CVEs
Bugs drop weekly, and the gap between a patch and an exploit is shrinking fast. These are the heavy hitters for the week: high-severity, widely used, or already being poked at in the wild.
How to Find Hidden AI Agents on Employee Devices and Bring Them Under Control→ AI agents are quietly becoming a new insider threat, gaining access to company data, credentials, and internal systems without adequate security oversight. Join this webinar to learn how to uncover hidden AI agents on employee devices, detect malicious agent skills, identify risky permissions, and put practical controls in place before they lead to a security incident.
How to Find Security Gaps and Build Faster Defenses Against AI-Powered Cyberattacks → AI-powered cyberattacks are evolving faster than traditional defenses can keep up. Join this webinar to learn how to assess your organization's AI threat readiness, uncover critical security gaps, strengthen detection and response capabilities, and build a practical defense strategy against emerging AI-driven threats.
📰 Around the Cyber World
Meta said it addressed an issue after reports emerged that some Ray-Ban Meta smart glasses were recording people's conversations without the wearer knowing. The recordings occurred without users saying the "Hey, Meta" prompt phrase. "This issue has been resolved," Meta told Android Authority. "People can manage, review, and delete voice logs of their interactions with Meta AI via settings at any time." Meta did not say what caused the smart glasses to record people without user consent, or how many of them were affected.
Fortra said it's tracking a 12-fold increase in emails using requests for quotation, project invitations, and procurement inquiries as phishing lures from October 2025 to September 2026. "These messages impersonate prospective buyers seeking pricing, availability, or project participation," Fortra said. "Their purpose is not to obtain a legitimate quote, but to persuade a recipient to access an attacker-controlled file-sharing, document-viewing, or procurement portal."
A fake download site for the WatchGuard Mobile VPN with SSL ("watchguard-vpn[.]net") has been observed using a browser pop-up prompt to steal the victim's VPN server address, username, and password. As of October 13, the domain was offline. "In a unique twist, after collecting credentials twice (the first attempt gets rejected as 'incorrect' in a likely attempt to collect multiple credentials), the site then downloads the genuine, validly signed WatchGuard installer directly from WatchGuard's own content delivery network (CDN), meaning there is no malicious file for endpoint security tools to flag," Huntress said. "Meanwhile, unbeknownst to the victim, the threat actor now has access to their credentials, giving them access to victims' networks."
A set of 42 malicious RubyGems packages has used typosquatting, brandjacking, and plausible utility names to target cryptocurrency and Web3 developers. The packages are designed to spawn a reverse shell and download a crypto theft kit capable of rerouting cryptocurrency transactions by replacing the destination address with an attacker-controlled wallet and harvesting wallet material, such as seed phrases and private keys. The names of some of the packages are: lightinng-invoice, cryoto-toolbox, etheremu.rb, bitcoin-rpc-lite, web3-sign-helper, and crypto-mnemonic-tools. The activity has been codenamed Ghost Dev by Open Source Malware.
GreyNoise said it has observed a spike in scanning and exploitation attempts targeting Digital Video Recorders (DVRs) in Ukraine between September 21 and October 1, 2026. The majority of the activity attempts to exploit CVE-2021-36260, which allows unauthenticated command injection against unpatched Hikvision products.
A series of email campaigns have been targeting the accommodation industry with fake guest complaints or reviews that deliver blockchain technology-abusing malware. "These emails appear to likely be a continuation of a prior series of predominantly Booking.com-spoofing emails that were seen delivering various remote access trojans (RAT) via ClickFix fake CAPTCHA websites," Cofense said. The activity leveraged the Ethereum and TON blockchains, a technique called EtherHiding, to deliver EtherRAT and TONResolver malware.
As AI agents increasingly are being used to automate coding workflows, it increases the risk associated with credential exposure, Trellix warned. "Agents constantly take credentials out of the safe places your operating system keeps them, and put them somewhere far more exposed," Trellix said. "This happens as a normal side effect of everyday work. And even good security telemetry has a hard time distinguishing this from a developer doing their job -- or from an attacker who is already inside."
MITRE released version 20 of its ATT&CK framework, adding entries that cover AI abuse, MFA bypass, and recent attacks on water utilities. This includes nine new Techniques and Sub-Techniques under the Enterprise domain for prompt injection, AI-enabled exfiltration, AI result poisoning, attacks on AI-assisted defenses, CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) evasion, and application-specific password theft. For Mobile, MITRE also un-deprecated a technique for delivering malicious apps outside official app stores, last included in v11.
Fake AI tool campaigns that impersonate Claude, ChatGPT, GitHub Copilot, Gemini, and other AI brands are being used to plant infostealers on compromised systems using ClickFix lures. Some of the prominent targets include the U.S. and India. "The attacks share one trait: the employee performs the decisive step," ANY.RUN said. "They paste an 'install command,' run a convincing installer, or sign in to a fake window. That can put source code, cloud and AI API keys, active business sessions, ad accounts, and billing access at risk, turning a single user action into potential data exposure, account compromise, financial loss, or disruption to development and marketing operations."
An official OpenAI skill, render-deploy, suffered from a first-of-its-kind supply-chain vulnerability which instructed production apps to send their tokens to an unregistered domain ("render-internal[.]com"). "It builds apps that trust a domain nobody owns, so any attacker could register it and start receiving tokens from real production apps," AIR Security said. "Vulnerable servers in the wild sent tokens to the domain, users are advised to update to the patched version of the skill."
The U.S. Federal Bureau of Investigation (FBI) warned that scammers could exploit the 2026 U.S. midterm election to perpetrate financial fraud schemes. "As previously reported, scammers use the names, images, logos, and slogans of candidates to fraudulently solicit campaign contributions, sell merchandise that is never delivered, or steal personally identifiable information (PII) that can be used for other fraud," the FBI said. "Scammers also exploit artificial intelligence (AI) tools to generate highly realistic voices, images, and written messages that impersonate candidates, campaigns, government entities, and trusted contacts."
Conclusion
If there's one thing this week made clear, it's that small gaps can lead to big problems. A weak password, an old bug, a trusted connection, or a device that wasn't checked properly. None of these sounds unusual on its own. But attackers keep finding ways to turn them into something much worse.
The lesson isn't to worry about every new threat. It's to pay closer attention to the things we already know can go wrong. Check what's exposed, question what you trust, fix what you can, and don't assume something is safe just because it's been working fine. Sometimes the simplest checks prevent the biggest headaches.
from The Hacker News https://ift.tt/e2qBzJx
via IFTTT
In Salesforce Agentforce, the recommended way to make an agent respond to events is a Flow: a record is created or a case is updated, and the Flow passes data into the agent's prompt. Separately, Email-to-Case and Web-to-Case turn inbound customer messages into case records; it is how airlines and hotels run support intake. Both are standard, documented, as-designed features. Chained together, they produce this path:
public internet → email → case record → agent prompt → agent action → case comment → outbound reply
An unauthenticated outsider now has a route into an internal agent's instructions, and the agent's reply leaves through the same door. Nothing was misconfigured. The finding, documented by researchers in August 2026, is a clean example of how agents that arrive inside existing platforms fail: through the application around them, not the model inside them.
The risk is in the application, and the application is the thing nobody re-reviewed
Which intake features are enabled, which triggers fire, which objects are exposed to guest users, which automation passes untrusted data where, and which model version the agent is quietly calling underneath: these are the variables that decide whether the Agentforce chain is a support-queue nuisance or a data exposure. A vendor risk review performed once at procurement sees none of them, because the agent did not exist at procurement. A prompt filter watching the agent's inputs does not know that a particular input originated from a stranger, because prompt filters do not understand Email-to-Case.
Securing an inherited agent therefore means understanding its host application at the depth its own admins do. That depth is the one thing a questionnaire and a scanner both lack. The City-Forum campaign, an active worldwide data-theft operation against Salesforce and ServiceNow instances running since March 2025, was found in exactly this territory: the gap between platform features and the configurations enterprises actually run.
Builders are multiplying, and some of them are agents
The platforms have made agent creation as accessible as making a slide deck. Marketing operations builds an agent to pull pipeline reports. Finance builds one to reconcile invoices. Each rides its creator's permissions, because that is what makes it useful. Shadow AI was an employee pasting data into a chatbot. Shadow agents are that employee's access, running unattended, multiplied across everything they were ever granted.
Increasingly, agents also build agents. A coding agent tagged into a chat channel can scaffold and deploy another agent as easily as it opens a pull request; an orchestration platform spins up sub-agents to divide a task, each with its own connections and none with its own review. Any governance model that assumes a human requested each agent is quietly obsolete.
Why governance keeps producing a document
Ask a large enterprise about agent governance and the answer is usually a document: an acceptable-use policy, a monthly committee, a set of principles nobody disputes and nothing enforces. Ask the operational question, how many agents are running right now, what can they reach, and who owns each one, and the document does not know.
The OWASP Agentic Skills Top 10 now describes the sharpest version of this gap under its "No Governance" category: a skill deployed and managed inside a third-party platform is unreachable by external scanners (OWASP Agentic Skills Top 10 whitepaper, ast10-top10-whitepaper-2, published at owasp.github.io). The tools an enterprise points at the problem from outside cannot see inside the venues where most agents live. Governance fails most often because the rules get written before the security team can see the things the rules apply to.
The stack, bottom-up, with a test for each layer
The working order is bottom-up, and each layer is the precondition for the one above it. A practical way to check whether a program is real is to apply an operational test at each level.
Layer
What it has to produce
The operational test
Discovery
A continuously refreshed population across app configs, OAuth grants, network, endpoint, email metadata, and browser
Is the discovered count several multiples of the list IT keeps? If not, discovery isn't reaching where agents live.
Posture
Every platform's agent-relevant settings, measured against how they should be configured
Can the team list the intake features and guest-user exposures wired to agent triggers on its top three platforms?
Identity and ownership
An identity and a named owner per agent, with a lifecycle
Pick an agent at random. Does a human raise a hand within a day when asked "whose is this?"
Usage
Who is building what, through which surface, with what data
Is there a sanctioned path that ships a business team's agent with secure defaults, or only a block?
Agent controls
Least privilege against observed need, approval and quarantine for new agents, risk tiering that reflects each agent's full context
Does the same finding on a sandboxed dev agent and a customer-facing one show different severities?
Runtime
Live inspection and intervention
Is it fed by the five layers above, or deployed first and enforcing blind?
The cost of paper compliance
The EU AI Act's penalties carry GDPR-level weight: up to €35 million or 7% of global annual turnover for prohibited practices, up to €15 million or 3% for other violations. Every framework converging on it assumes the stack above exists. GDPR already showed what happens when it does not. British Airways (£20 million) and Marriott (£18.4 million) were not fined for having imperfect policies. Everyone has imperfect policies. They were fined because compliance existed on paper and could not be evidenced operationally when regulators asked. A governance practice built bottom-up generates that evidence as a byproduct: the inventory, the owners, the configurations, the review history.
Some platforms are designed to produce exactly that record. One leading example is Reco, which discovers agents across multiple vantage points, including the ones that never touch SSO, and assigns each a risk profile before any policy can be applied to it.
The Agentforce chain at the top of this article is not an exploit. It is a configuration, and configurations are governable, provided someone can see them. Chapters 1 to 3 of Into the Expanse cover the shift, the three launch vectors, and the governance practice in full: https://www.reco.ai/agent-ecosystem-security
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/IEAJQab
via IFTTT
Agents are rapidly becoming part of how work gets done. They can support a range of activities from writing code and researching products to analyzing revenue, processing expenses, and acting across the systems that run the business. To be most useful, they often need access to company data, applications, tools, and other agents. That access is what makes agents more capable. With that capability can come insider risk.
This does not mean agents are inherently malicious. It means they are capable tools that can be granted access to important systems by users. They can make mistakes, be manipulated, or be compromised. Their models can produce variable outputs, their context can change, and their plans can evolve as they work. An agent that operates as intended when a task begins may respond differently as context or inputs change. Depending on how they are designed and deployed, agents can operate continuously, at machine speed and scale.
Satya Nadella, Chairman and Chief Executive Officer of Microsoft, recently described the trust architecture this new era requires: we must separate the supply of intelligence from the authority over it. We should not ask a model to be its own security authority. The controls that determine what it can access, what actions it can take, and whether it should continue operating must sit outside the model, where the model cannot bypass or tamper with them.
“The most trustworthy agentic system will not be the one with the model we trust most. It will be the one designed that enables us to trust the model least.”
Satya Nadella
Project Perception—Securing your agentic insider
We introduced Project Perception and the Microsoft cyber stack to help organizations defend with agents. Today, we are extending Perception to secure the agentic insider. Guardian Agents help security teams operate continuously, at machine speed and scale, while sensors, context, and actuators across the cyber stack help understand changing agent risk and continuously adapt protection in response. Project Perception and Microsoft Agent 365 share signals, context, and a unified registry giving IT and security teams a consistent view of agents and risk, with the controls each needs.
This builds on a simple security principle: surround non-deterministic intelligence with deterministic controls, independent evidence, and containment boundaries. Assume an agent can fail or be compromised. Observe it continuously. Minimize and tailor its authority before it acts. And continuously adjust that authority as risk changes.
This requires protection across identity, permissions, data, endpoints, network, cloud, and runtime. The system has four continuous responsibilities:
Know which agents exist, who owns them, why they exist, and what they are doing.
Contain what each agent can access and do before it acts.
Protect the data, tools, runtime, resources, and systems in the agent’s path.
Adapt protection continuously as behavior, context, and risk change.
These are not four products or sequential phases. They operate together. Evidence changes risk. Risk changes policy. Policy changes what the agent is allowed to do. Consider an expense-approval agent. It may need to read expense submissions, check policy, and approve routine reimbursements, but it should not inherit every permission of the employee who sponsors it. Its identity, runtime, access paths, and task-scoped authority should be explicit from the start. If it later encounters a prompt injection or attempts an action outside that task, the system should respond proportionately: preserve safe reads while blocking writes, narrow the resources it can reach, require provable human approval for a consequential step, or isolate and stop the agent when the risk warrants it. This is what continuous containment looks like in practice.
Know every agent and give it an accountable identity
You cannot secure what you cannot see. Agents can be created through Microsoft platforms, integrated through partner platforms and software development kits (SDKs), or introduced locally without a central deployment process. Microsoft Security uses native integrations, connectors, and sensors across the cyber stack to discover more of the agent estate.
We are expanding discovery to 35 additional types of local agents, bringing the total to 60 supported local agents, including Claude Code, OpenAI Codex, and GitHub Copilot. Organizations can bring these agents into a unified registry, regardless of how they were discovered, to understand ownership, activity, and risk.
Discovery tells you that an agent exists. Identity gives security and governance systems a durable anchor for controlling it.
Every agent should have a first-class identity distinct from the person using or sponsoring it. We are extending Microsoft Entra Agent ID with identity types for additional agent patterns, including local and previously unknown agents discovered through security sensors. This means an agent can become a policy target even when it was not originally integrated with Microsoft Security. Agent identity anchors attribution, ownership, lifecycle, risk, permissions, authorization, and policy, so the enterprise can distinguish what a person did from what an agent did on that person’s behalf.
Contain what the agent can do before it acts
Being able to find and identify an agent is necessary, but it is just the start. We need to understand the potential impact the agent can have in the enterprise environment. The next step is to bound the agent across its runtime, its paths to tools and resources, and the authority it can exercise.
Contain the runtime
The model and harness should execute inside a controlled environment rather than inherit fully-privileged access to the device. Sandboxes such as Microsoft Execution Container (MXC) provide policy-controlled access to resources the agent needs to complete its task. They also create an enforcement boundary where security controls and observability can operate outside the agent’s reach. If the agent or harness is compromised, it should not be able to disable the controls watching it.
Control the action space
An agent should not be free to call any tool, API, Model Context Protocol (MCP) server, resource, or other agent it can find. Local and network and data controls must mediate those paths, observe the calls, and enforce enterprise policy. Controlling the destination alone is not enough. Security must also understand the content flowing into and out of the agent, including its sensitivity, provenance, and whether untrusted data may be influencing the agent’s behavior.
Start with no permissions, or least privilege
We have spent decades applying Zero Trust and least privilege to people. Agents make those principles even more important. An agent should not automatically inherit all the standing access of its user. It should begin with no authority and receive only what it needs for the approved task, for only as long as the task requires.
To enable this, we are introducing Dynamic Permissions. Organization-wide policy sets the outer boundary, including preventing an agent from obtaining authority its user does not have. Permissions can then be scoped to the task, made time-bound, and contracted or removed as the task changes or completes. Higher-impact actions can require verified human approval.
The employee retains the employee’s access. The agent receives its own identity, permissions and its own authority scoped to its current task and for the duration of the task only.
Adapt protection as agent risk changes
Least privilege reduces exposure, but it does not eliminate risk. An expense-approval agent may begin a task with the right access and then encounter a prompt injection in an external document. Its configuration has not changed, but its behavior and risk have.
For human users, a delay between detection and response may be manageable. For an agent operating at machine speed, it can be the difference between containment and impact. The security system must be able to understand what changed and act before a person can manually investigate every signal.
That is why we are introducing Dynamic Agent Risk and Dynamic Conditional Access for agents.
Dynamic Agent Risk
Dynamic Agent Risk combines signals from identity, data, endpoints, cloud, network, runtime, and the agent’s own activity. It considers how securely the agent is configured, what resources it can reach, the potential impact if something goes wrong, and whether its actions are drifting from the user’s or organization’s intent.
The result is not a one-time score assigned at onboarding. It is a continuously updated understanding of the agent’s current risk and whether its current authority still matches that risk. The question is not simply whether the agent should run or stop. It is what the agent should be allowed to read, change, invoke, or approve at that moment.
Dynamic Conditional Access
Dynamic Conditional Access extends Microsoft Entra Conditional Access for agents so a change in risk can drive coordinated action across multiple enforcement points. The response is graduated, not binary. Policy can reduce permissions, preserve reads while blocking writes, narrow the data and resources the agent can reach, restrict network paths, shorten or revoke time-bound access, or require provable human approval before a consequential action proceeds. At the highest levels of risk, it can isolate the runtime or stop execution entirely.
Return to the expense agent. It begins with narrowly scoped permission to review and approve expenses within policy. When it encounters untrusted content and attempts an unrelated action, new evidence raises its Dynamic Agent Risk. Policy responds proportionately: it can preserve read access while removing the ability to approve or write, block access to sensitive resources, and require cryptographically provable human approval for a high-impact step. If the risk continues to rise, the system can isolate the runtime or stop execution. The employee remains productive. The agent is constrained without treating every risk change as a kill-switch event.
Secure agentic systems at scale with Guardian Agents
As organizations deploy thousands or hundreds of thousands of agents, manually triaging every alert and coordinating every response will not scale. Securing agents must itself become agentic, while remaining inside boundaries people set.
That is why we are introducing new Playbooks and a team of Guardian Agents in Project Perception. People define policy, approval boundaries, and delegation rules. Playbooks define the desired security outcome and coordinate protective actions. Guardian Agents carry out the work at machine speed, adapting as agent activity, risk, security context, and organizational policy change.
Guardian Agents can help teams understand why risk changed, investigate the relevant evidence, recommend or apply containment, and use what they learn to harden policy. This is not about outsourcing judgment. People retain control over objectives and consequential decisions. The system carries the continuous work that does not scale through manual operations.
Agents will only be adopted at scale if they can be trusted at scale. At Microsoft, we are already operating in a world of hundreds of thousands of agents. As Customer Zero, we have learned that securing agents requires continuous visibility into agent activity, proactive protection of access and data, and adaptive protection that keeps pace with evolving threats. Those lessons directly inform the innovations we are delivering to help every organization adopt agents with confidence.”
—Terrell Cox, Corporate Vice President (CVP) and Deputy Chief Information Security Officer (CISO), Customer Security, Microsoft
Extending containment to the model
As model transparency increases, it creates a new source of security evidence. Chain-of-thought and other model-level signals can help identify intent drift, understand whether untrusted information is influencing reasoning, and detect when an agent’s planned actions are diverging from the task it was given.
We are bringing this deeper evidence into Dynamic Agent Risk, together with signals from across the cyber stack. This builds on Satya Nadella’s principle: increase transparency into the model while keeping security decisions and enforcement independent of it.
Greater model transparency gives security systems deeper evidence to detect suspicious behavior and inform Dynamic Agent Risk. But the core security principle does not change: the model cannot be its own security boundary. Independent systems must observe every layer, including the model itself, and ultimately determine and enforce what the system is allowed to do.
These are not separate pillars. They make the same containment architecture stronger: better evidence, stronger assurance, more accurate risk, and more effective protection.
Confidence to move faster
Organizations are adopting agents to serve customers better, solve problems faster, and give people more time for the work that matters most. The goal is not to make every model perfectly predictable before it can be useful. The goal is to build systems that remain secure even when the model is not.
That requires a clear division of responsibility. Models supply intelligence. People and organizations retain authority. Independent controls establish identity, limit privilege, protect data, preserve evidence, and contain unsafe action. Security continuously reassesses risk and adapts protection as the agent works.
You should not have to choose between innovation and safety.
That is what we are working toward: an agentic world where organizations can put intelligence to work with confidence because security can observe it, govern it, and contain it at the same speed.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
