In response to a new European Union law, AI platforms are implementing new schemes for watermarking the content they generate. Anthropic recently disclosed its future Claude models will use SynthID-Text, an approach Google created and released as open source. It uses a secret key that subtly changes the process a model uses for choosing the next word in a sentence. Whereas a top next word choice might be “cloudy,” the key might change it to “overcast.” Anyone who knows the key can determine if it was generated by the platform using it.
New research shows that SynthID-Text can change not just word selection but also the tools a model invokes and the chances it will adhere to or disregard safety guardrails it has been trained to follow. The threat can become greater in the face of an adversarial prompt, in which an attacker attempts to cause a model to carry out a harmful action, such as revealing a password or other sensitive information. Instructions that normally wouldn’t be followed will, in some cases, be performed once the watermarking is deployed. The finding underscores the need for developers to thoroughly test how their LLMs and agents behave when watermarking is in place.
“As compared to the same models without watermarking, it is definitely going to change their behavior, especially when we place it under adversarial conditions, or we make these models call tools when they’re powering an agent,” Andrea Siposova, an AI security researcher at Lasso Security, told Ars. “Watermarking is made to not be perceptible to a reader, but we know that when we are changing anything about what the model is generating, it is going to cause some tradeoffs, it’s going to show up somewhere.”
© Getty Images
The International Meteor Organization, the nonprofit that coordinates and publishes amateur and professional observations of meteor phenomena, said its infrastructure has suffered a “critical blow” from a cyberattack.
“We recently suffered a cyberattack that dealt a critical blow to aging infrastructure, taking much of our site offline," a static page on its website on Wednesday said. “We expect several weeks of partial downtime as we transition to new infrastructure and services.”
In the meantime, the IMO said it’s prioritizing the reporting of fireball observations, which can be reported here. The organization is also providing some information on its Facebook page.
© Interntional Meteor Organization
In record time, Meta’s camera-adorned smart glasses have turned from a lucrative and well-reviewed consumer product into a widely-reviled and privacy-infringing tool of abuse in the arsenal of creepy men.
The backlash has grown so much that many owners of the “pervert glasses” have become too afraid to use them in public, a PR disaster for what once was an accessory that was flying off the shelves.
Meta is evidently alarmed by the growing criticism, desperately trying to implement a “kill switch” and remotely cutting off “manfluencers” by bricking their glasses.
And now, as The Information reports, the Mark Zuckerberg-led company is now looking to release a camera-free pair as well later this year — the clearest indication yet that Meta is losing in the court of public opinion.
Whether removing the camera from the glasses will be enough to assuage ongoing concerns over privacy remains to be seen. The camera-free glasses, code-named Luna, will still feature an array of six microphones to allow users to speak to the company’s AI chatbot and its recently-released AI assistant, called Muse. They’ll presumably pick up audio from users’ environments as well, where bystanders may not be aware of the eavesdropping.
The news comes just days after two families filed a proposed class action lawsuit, alleging Meta was extracting biometric information from people’s Instagram and Facebook photos to build a face-recognition system for its smart glasses.
The glasses could be the ultimate litmus test on what drew buyers to the pair of spectacles in the first place. By relying on microphones alone, Meta is betting that people are willing to shell out hundreds of dollars just to talk to its flawed AI companions — not take first-person view photos.
Project Luna could be unveiled as soon as next week’s Meta Connect conference. It’ll be interesting to see how the company will address the major backlash to its camera-equipped smart glasses, if at all. An admission that its consumer product is facilitating some incredibly creepy behavior in public feels unlikely — but it’ll certainly be the elephant in the room.
More on the glasses: Meta Is Using Instagram Users’ Photos to Build a Universal Facial Recognition System for Its Hated Smart Glasses, Class Action Lawsuit Claims
The post Zuckerberg’s Pervert Glasses Have Been So Publicly Shamed That Meta’s Reportedly Now Working on a Version With No Camera appeared first on Futurism.
Model adopting ‘jailbreak-like instructions’ among cases as firm says it is introducing new way of tracking AI misalignment
OpenAI has disclosed six more examples of “unexpected or concerning” behaviour by its technology, as it warned the pace of development could not continue at “maximum speed for much longer”.
In one of the new cases reported by OpenAI, an unreleased research model inserted “jailbreak-like instructions” into its own notes to disregard its normal constraints and told itself to be “freed from the roles and identities that bind other chatbots”.
Continue reading...
© Photograph: Dado Ruvić/Reuters
© Photograph: Dado Ruvić/Reuters
© Photograph: Dado Ruvić/Reuters
While its flagship Dreamforce event was in full swing on Wednesday, Salesforce was triaging a roughly seven and a half hour-long service outage that disrupted user access and caused “severe delays” and intermittent errors. Some customers were also unable to submit new support cases.
The service outage hit at 3:50 a.m. EDT, impacting “multiple instances across all regions,” Salesforce reported. It was marked resolved right around 3 p.m. EDT, after several hours of monitoring to determine that fixes had been successful.
Salesforce initially pegged the issue to an “external dependency failure” impacting the legacy login server. A core system component experienced increased load, limiting its capacity to process requests. The company confirmed that there were no issues with third-party infrastructure.
Beyond the obvious embarrassment from the outage occurring during Dreamforce, an analyst said the incident highlights a cloud resilience problem, rather than purely a legacy one.
“Cloud does not eliminate architectural dependencies,” said Abbas Jaffery, a principal advisory director at Info-Tech Research Group. “It can sometimes make them less visible. And when the platform is your system of record, those hidden dependencies become an enterprise risk rather than simply a technology risk.”
Salesforce began experiencing service issues at 3:50 a.m. EDT on September 16, and initial investigation determined that requests were stalling while waiting on responses from an internal login service that was using up available server resources.
Initially, Salesforce blocked application programming interface (API) endpoints and attempted rolling restarts to revive the service, then pushed out fixes region-by-region. At 7:20 a.m., some customers were seeing service return to normal, and Salesforce was working on a “code-level permanent fix.”
However, the rollout did not complete for a number of instances, and some automated fixes didn’t fully resolve the issue. For example, customers reported that scheduled jobs were not running as expected, even after service was restored. Salesforce manually restarted those instances.
Salesforce later reported that the impact radius was “narrower than initially understood” and saw signs of recovery by around 11 a.m. EDT, with most customers coming back online.
A sub-set of Hyperforce instances were the last to be restored. Mitigations were in place across all instances by 11:39 a.m. EDT, and Salesforce continued to monitor the issue until marking the incident resolved at 2:59 p.m. EDT.
“We apologize for how this incident affected you and your business,” Salesforce posted on its incident blog. “We will undertake a full investigation of the incident, establishing the technical trigger, the underlying cause, and preventive action to avoid a repeat in the future.”
For customers for whom Salesforce is a system of record, several hours of authentication and service disruption can create a “temporal data problem,” Info-Tech’s Jaffery explained. “Events that should have happened at different points in time may occur later, fail altogether, or arrive out of sequence,” he said.
For instance, a customer interaction may occur through another channel while Salesforce is unavailable, but an integration, workflow, or scheduled process that normally records or propagates that event is unable to run.
This has several potential consequences, Jaffery said. Transactions and customer service processes are delayed; APIs and middleware may accumulate retries, timeouts, and queues. Records can become temporarily inconsistent, and scheduled jobs and workflows may be missed. Employees could lose visibility into customer history or case status, even when the underlying data has not been lost, creating a “data divergence.”
The first mistake would be to assume that just because users can log in, the incident is over, he noted. “Enterprises should move immediately into a reconciliation and integrity phase,” Jaffery advised. This means not only verifying interactive access, but APIs, integrations, scheduled jobs, queues, workflows, automation, authentication flows, and downstream systems.
Enterprises should ask what transactions failed, partially completed, or were duplicated during the outage? Which scheduled or asynchronous processes did not execute? Did integrations retry successfully, or did they create a backlog or retry storm? Are downstream systems now consistent with Salesforce?
Security teams should also validate authentication and session behavior, privileged access, integration credentials, and any emergency changes made during recovery, Jaffery explained. “The most important question is not simply ‘Is Salesforce back?’, but ‘What did the business expect to happen during the outage, and can we prove that it actually happened?,’” he said.
A credible post-incident review from Salesforce should establish a causal chain: The trigger, dependency failure, technical propagation, customer impact, detection, mitigation, recovery, and permanent corrective action, Jaffery said.
The company should be able to answer these questions, he said:
Service restoration simply tells customers: “We got it working again,” he noted. But root cause analysis tells customers: “We understand why it failed, why our controls didn’t prevent it, and what has changed so that the same failure mode is less likely to recur.”
One architectural lesson is that a legacy component does not have to be large to be critical, Jaffery pointed out. An older authentication service can remain part of a modern stack, and therefore become a dependency for newer services.
“The component’s age matters less than its position in the dependency graph, its blast radius, and the quality of its isolation and failure handling,” he said, pointing to this incident’s progression: Requests stalled waiting on an internal login service due to increased resource consumption led to investigation into an external dependency failure, which in turn revealed impact on a legacy login server. Finally, Salesforce said, “core system components experienced increased load, which limited its capacity to process request”.
That is a classic resilience question, Jaffery pointed out: Can a failure in one dependency remain in that one dependency, or does it become a platform-wide failure?
Modernization should not be identified simply by how much old technology has been replaced, he noted, it should also measure dependency concentration, isolation, “graceful degradation,” recovery paths, and failure blast radius.
“For enterprise architects, that is the real takeaway,” he said.
At this point, there are no obvious signs that this was a security incident, noted David Shipley, CEO of Beauceron Security. “Right now, this bears all the hallmarks of an update gone horribly wrong.”
He pointed to an incident in December 2025 when Amazon’s internal AI coding agent, Kiro, caused a 13-hour AWS outage in a mainland China region, noting, “I’m not going to be shocked if we don’t see some kind of agent role in this kind of scale disaster.”
Significant Salesforce layoffs over the last few years could also have had a negative impact on the outage and recovery, he added. “Having it happen during Dreamforce had to be all kinds of hell, though, for their sales and customer support teams,” he said. “Pour one out for them as they work on rebuilding relationships, face-to-face.”
This article originally appeared on CIO.com.
The US Treasury's Financial Crimes Enforcement Network has issuespublished an alert and a companion data analysis telling banks, credit unions, digital asset exchanges, and securities firms that it needs sharper reporting on the overseas scam centers that it says target Americans at an industrial scale.
FinCEN puts total damages, per its reporting mechanism, at roughly $12.7 billion linked to suspected digital asset investment scams between September 2023 and the end of 2025.
The number comes from adding up the dollar values of 33,904 Bank Secrecy Act filings that referenced the keyword from its 2023 "pig butchering" alert, which may be overstated, as it includes both attempted and successful transactions as well as both inbound and outbound reports, often of the same transactions, causing significant overlap.
While the $12.7 billion is a measure of what institutions have flagged and is prone to double-counting and errors, victim losses, a significant chunk of which go unreported, may be considerably higher.
This has prompted Gene Lange, who effectively works as the Under Secretary for Terrorism and Financial Intelligence, to call these scams "one of the most significant fraud threats facing Americans today."
It has also prompted a new suspicious activity report keyword: "FIN-2026-SCAMCENTERS," which institutions are expected to use to indicate that a scam center is potentially involved.
FinCEN also wants chat logs, scammer phone numbers, social media handles, wallet addresses, transaction hashes, and the URLs victims were told to deposit into, filed in the structured cyber indicator fields rather than left out.
The move is part of its push to have institutions volunteer more information under the US Patriot Act, as it aims to confront what is a growing intelligence problem: scammers tend to route victims through several institutions in sequence; most filers see only one slice of a scam's lifecycle and often have difficulty tracing it all the way.
For example, a crypto exchange might see a customer buying USDT and sending it off-platform, a bank might see a wire to that exchange, and a brokerage might see a retirement account liquidated. None of them would have the bigger picture of what essentially happened or what triggered the transaction.
Combined, with properly linked information, it makes it much easier to identify a potential scam; separately, these incidents can inflate the number of reports, which often aren't linked, and investigations can lack insight into the origin or final destination of the funds.
FinCEN's Rapid Response Program has interdicted $1.8 billion and recovered just over $1 billion for 5,790 US victims since 2015, which, against the flagged totals, is a very limited recovery at best compared with the actual funds at stake. This highlights a larger fundamental problem: institutions mostly detect these schemes after the money is gone, and reporting them correctly and thoroughly may yield limited dividends at best against an industry that has morphed, relatively unchecked, into a multi-billion-dollar juggernaut.
A GitHub account has published what it describes as a faithful reconstruction of Stuxnet, the worm that sabotaged Iranian uranium-enrichment centrifuges.
It also became the first piece of software widely accepted as having caused physical destruction in the real world, highlighting how malicious software can often do much more harm to people and hardware than just stealing or manipulating data.
The repository surfaced via a Show HN submission, which mainstream media outlets then picked up, highlighting the as-yet-unknown researcher's reverse-engineered code.
The original Stuxnet source, written by whoever built it, has never been leaked and did not leak last week. The repository's README explicitly states that it is a reconstruction assembled from decompiled binaries, and those binaries have been in public circulation since Belarusian firm VirusBlokAda pulled samples from an Iranian customer's machines in June 2010.
Everything that followed, including Symantec's W32.Stuxnet Dossier and Ralph Langner's To Kill a Centrifuge, was built on those samples and how they reacted in test environments.
This is also not the first time readable C-language code aiming to replicate Stuxnet has been published online. Malware researcher Amr Thabet published a decompilation of the MRxNet rootkit carrying a 2010 to 2011 copyright notice. Christian Roggia followed with a dropper decompilation called open-myrtus, copyrighted 2012 to 2014, which has since been forked into a long chain of repositories.
The irony is that if such code were a faithful replication of the infamous malware, it would not have mentioned "Stuxnet" in multiple places, including registry keys. This is because the moniker is not one the developers likely used, but one Symantec switched to from its original 'W32.Temphid' identifier.
The thread where it was first brought to attention by a user called Sadpainy also has mixed views from developers, many of whom have branded it 'AI slop' or a 'fake' that relies on a mixture of already existing repositories, even as the about page on its GitHub repo states that it was reproduced by the researcher for educational purposes and is designed to only work on Windows XP and Windows 7.
For those looking to test it, a virtual machine might be their best bet, especially given Stuxnet's ability to physically damage hardware, but it is also a stark reminder of what a rogue AI agent could do if left unchecked without specific instructions or safeguards.
The International Meteor Organization, the nonprofit that coordinates and publishes amateur and professional observations of meteor phenomena, said its infrastructure has suffered a “critical blow” from a cyberattack.
“We recently suffered a cyberattack that dealt a critical blow to aging infrastructure, taking much of our site offline," a static page on its website on Wednesday said. “We expect several weeks of partial downtime as we transition to new infrastructure and services.”
In the meantime, the IMO said it’s prioritizing the reporting of fireball observations, which can be reported here. The organization is also providing some information on its Facebook page.
© Interntional Meteor Organization
Login