Anthropic revealed on Thursday that some of its Claude models escaped test environments and hacked into the systems of three organizations while trying to solve a challenge.

The admission comes after OpenAI revealed that its models broke out of what was believed to be an isolated environment and breached Hugging Face and other organizations. 

Anthropic decided to conduct its own investigation after the OpenAI incident came to light, reviewing 141,000 evaluation runs where Claude could have gained internet access.

The analysis revealed three instances where a model reached the public web either from within or while interacting with an environment set up by Irregular, an Israeli AI security startup that serves as one of Anthropic’s third-party evaluation partners.

The models that broke out from the testing environment then breached the production systems of three unnamed organizations. The earliest intrusion dates to April, but none of the targeted organizations detected the attacks on their own.

According to the AI giant, Claude had been tasked with conducting a capture-the-flag challenge to assess its cyber capabilities. 

The breakout from the sandbox occurred due to a misunderstanding between Anthropic and Irregular—Anthropic told Claude that it was conducting a simulation in an environment without internet, but a connection to the internet was in fact available and the models treated it as part of the exercise. The AI then also falsely believed that the organizations it targeted were part of the exercise.

Anthropic claims this is the only reason why its models conducted real-world attacks, and it was never their intention to escape the test environment.

Unlike in the OpenAI incident, which involved the exploitation of a JFrog product zero-day, the hacking conducted by Claude models leveraged weak credentials, unauthenticated endpoints, and other basic attack techniques.

The real-world attacks

Anthropic said the incidents involved Mythos, Opus, and an internal research model, all running without the safeguards deployed when they are made available to customers. The internal model, which the company described as its “latest”, stopped the exercise when it realized that it had breached a real company.

In the first incident, Claude Opus 4.7 continued to attack the system even after learning that it was operating in a real environment rather than a test environment, believing that the hacked company was part of the evaluation. The model targeted the company because its website domain name resembled the name of the fictional target company set up for the test.

In the second incident, Mythos 5 gained access to the systems of a cybersecurity company after deploying a malicious Python package to PyPI. The security firm regularly scans Python packages and it installed the malicious package, which enabled the AI to exfiltrate credentials and access the company’s infrastructure.

This incident demonstrates the complexity of the actions AI models can carry out. As described by Anthropic: 

[In] order to create a PyPI account, Claude needed an email address. And in order to create an email address, it needed a phone number. To get a phone number, after failing to find a free phone number service, it tried—and failed—to obtain funds to pay for a phone number through several different means. It finally backtracked, found a free, non-blocked email provider, used this to register a PyPI account, and then used this account to upload malware to PyPI.

The third intrusion was conducted by the internal model, which stopped operating when it realized that the systems it was accessing were no longer part of the capture-the-flag challenge, but not before using exposed credentials and SQL injection flaws to compromise a company’s internet-facing app.

Anthropic concluded this was primarily a harness and operational failure rather than a case of models pursuing their own goals or deliberately deceiving evaluators.

The company said the incident underscores the need for stricter internet-isolation verification and containment controls in third-party testing environments, and it’s encouraging other AI labs to conduct similar reviews of their own cybersecurity evaluations.

Related: Microsoft Unveils MAI-Cyber-1-Flash, Its First Cybersecurity AI Model

Related: Anthropic’s Mythos Model Found Vulnerabilities in Classified US Government Systems

Related: Nvidia and Tech Giants Launch AI Security Alliance

https://www.securityweek.com/after-openai-disclosure-anthropic-finds-its-own-models-hacked-3-organizations/

In 2009, a surgeon named Atul Gawande and a team backed by the World Health Organization showed that a 19-item surgical checklist could cut complications and deaths by dramatic margins across eight hospitals worldwide. Not a thousand-page protocol. Not a comprehensive framework. Nineteen items, printed on a single card. Aviation learned the same lesson decades earlier: the pre-flight checklist fits in a pilot’s hand, not in a binder. Nearly two decades later, I watch security teams send AI vendors questionnaires with 300 questions, half of which begin with “describe your approach to…” and almost none of which would catch a real failure. We have the frameworks. What we don’t have is the checklist.

The timing matters. The EU AI Act’s enforcement teeth for general-purpose AI arrive this August, high-risk obligations are phasing in behind them, and ISO/IEC 42001 is now showing up by name in third-party risk questionnaires. NIST’s AI Risk Management Framework has become the default answer for “show me you have an AI risk program” in North America. Add the OECD Principles, HITRUST’s AI assurance work, sector regulators like the FDA, and a growing patchwork of US state laws, and most enterprises are now operating under two or more frameworks simultaneously.

Here’s the part that surprises people: the frameworks themselves largely agree. Published crosswalks show substantial overlap between ISO 42001, NIST AI RMF, and the EU AI Act. An organization that builds its program thoughtfully can satisfy all three with a single set of processes and documentation. The problem isn’t the frameworks. The problem is what happens downstream, when those frameworks get translated into the questionnaires, audits, and attestations that land on real desks.

The Questionnaire Problem

If you’ve been on the receiving end of an AI security questionnaire lately, you know the artifact I’m describing. Hundreds of questions. Free-text answers. Prompts like “Describe how your AI system ensures fairness” or “Explain your approach to responsible AI.” These questions have three fatal flaws.

First, they can’t be answered with evidence, only with prose. And prose isn’t compliance; it’s creative writing. A vendor with a mature program and a vendor with a good technical writer produce indistinguishable answers. The exercise rewards confident fiction and punishes honest uncertainty. When I see a question that any vendor can answer without producing a single artifact, I know that question isn’t reducing anyone’s risk.

Second, they ignore the nature of the systems they’re assessing. As I wrote in the last column, LLMs are stochastic systems that are extremely difficult to replay and troubleshoot. A point-in-time attestation about model behavior is stale the moment a model version changes, a system prompt is updated, or a temperature setting moves. Asking “does your model produce biased outputs?” as a yes/no compliance question fundamentally misunderstands what these systems are. The right question is whether you can measure it, log it, and show me the trend.

Third, they don’t scale with risk. I’ve seen the same 300-question addendum sent to a vendor running a marketing chatbot and a vendor deploying clinical decision support. When everything is high-risk, nothing is. The EU AI Act got at least this much right: its four-tier risk classification exists precisely so that obligations scale with consequences. Most homegrown questionnaires have no tiers at all.

What Usable Actually Looks Like

I want to propose a different bar for AI compliance, and it borrows directly from the checklist lesson: a framework is only as good as its worst question. Before any question makes it into your AI assessment, whether that’s a vendor questionnaire, an internal review gate, or an audit program, it should pass five tests:

1. Answerable with an artifact. Every question should map to evidence: a log, a config, an eval report, a data flow diagram, an architecture document. If the only possible answer is an essay, cut it or rewrite it. “Describe your approach to model security” becomes “Provide your logged inference parameters (model version, temperature, top P, token limits) for your production deployment.”

2. Scoped to risk tier. Classify the system first, then ask the questions that tier deserves. A limited-risk internal tool gets ten questions. A system touching patient data or financial decisions gets the full treatment. Don’t send Annex IV-depth documentation requests to a chatbot vendor.

3. Measurable or binary where possible. “Do you run evals? At what cadence? What was your last pass rate on your safety benchmark?” beats “describe your testing philosophy” every time. Reviewers can score it, trend it, and compare it across vendors.

4. Decision-relevant. For each question, ask: if the answer came back bad, would it change our decision? If removing the question wouldn’t change any outcome, remove the question. This single test eliminates half of most questionnaires I’ve seen.

5. Mapped once, reused everywhere. Build your control set once, then use the published crosswalks to answer NIST, ISO, and EU AI Act asks from the same evidence base. One process, multiple regulatory readings. If your teams are producing separate documentation for each framework, you’re paying a triple tax on the same work.

The Questions That Actually Matter

If I had to compress AI vendor assessment down to a single card, it would look something like this: Where is the model deployed, and who is the upstream provider? What data flows in, and what flows out, and where is that logged? Where are copies of that data stored, for how long, and who can access them? What inference parameters are logged per request, and can you replay an incident? What is your eval suite, what does it cover, and how often does it run against production? Where are the human oversight points, and what can the system do without one? What is your incident process when the model does something it shouldn’t? How do you swap or change models, what testing gates a switch, and do downstream customers get notified?

Notice these are largely the same questions I argued for in the red teaming column: before deploying, know where the model runs, what inputs it processes, what the outputs look like, and how business risk gets revisited over time. That’s not a coincidence. Good security questions and good compliance questions converge, because both are ultimately about whether you understand the system you’re operating.

Standardize the Model Card

There’s one industry fix that would eliminate half of these questions before they’re ever asked: a standardized model card. I raised this in the last column, noting that model cards tend to offer some insights but measurements aren’t standardized across the industry, and it matters even more for compliance than it does for red teaming. Today, every model provider publishes something different: different eval benchmarks, different safety disclosures, different levels of detail on training data, different definitions of the same terms. That inconsistency is exactly what forces every downstream customer to run their own bespoke questionnaire, and forces every vendor to answer the same questions a hundred different ways.

Imagine instead a model card with a fixed schema: model version and lineage, training data provenance categories, where and how long data is retained, a common core of eval benchmarks with published scores, documented safety mitigations, default inference parameters, and a change log tied to every model swap or version update. SOC 2 didn’t succeed because it was clever. It succeeded because everyone agreed on what the report looks like, so one artifact could answer a thousand customers. The model card should be AI’s equivalent: produce it once, keep it current, and let it stand in for the first fifty questions of every assessment. Standards bodies are circling this idea, and both ISO 42001’s documentation requirements and the EU AI Act’s transparency obligations gesture at it. But until the schema is common, buyers can force the issue by asking for the same fields, in the same format, every time. Procurement pressure standardized SOC 2. It can standardize the model card too.

The key insight I want to share is this: compliance is an evidence problem, and for AI, evidence is an observability problem. The organizations that will sail through the enforcement wave now arriving aren’t the ones with the thickest binders. They’re the ones whose logging, evals, and documentation were designed so that any reasonable question can be answered in minutes with an artifact rather than in weeks with an essay. This is what I mean by timeless compliance. Frameworks will keep multiplying, regulators will keep diverging, and the models themselves will be unrecognizable in three years. But the principles underneath don’t move: know your system, log what matters, measure continuously, scale scrutiny to risk, and never ask a question you can’t act on. Those held true for surgical checklists and pre-flight cards, they held true for SOC 2 and ISO 27001, and they will hold true for whatever comes after the current generation of AI standards. Comprehensive coverage is a moving target. Simplicity, done honestly, is permanent.

This column is Part 3 of multi-part series on securing generative AI:

Part 1: Back to the Future, Securing Generative AI
Part 2: Trolley problem, Safety Versus Security of Generative AI
Part 3: Build vs Buy, Red Teaming AI
Part 4: Timeless Compliance (This Column)

Learn More at the AI Risk Summit | Ritz-Carlton, Half Moon Bay

https://www.securityweek.com/timeless-compliance-why-better-questions-beat-bigger-frameworks/

The hope is that the changes, detailed in the protocol’s documentation, will make widespread deployment in an enterprise context much easier. MCP started as something that simply ran on a local machine, connecting models to local apps, so the new spec is a major rethink of some of its foundations.

There is also a new deprecation policy that ensures at least 12 months between when a feature’s formal deprecation is enacted and when the feature may actually be removed—with a narrow exception for critical security updates. This is again in keeping with the general “let’s make this work better at enterprise scale” theme of the new specification.

MCP is managed by the Agentic AI Foundation (AAIF), which sits under the Linux Foundation. MCP was originally introduced by Anthropic, just shy of two years ago, and Anthropic still has significant influence over its direction. Nonetheless, it has grown beyond just Anthropic—OpenAI, Google, Microsoft, and Amazon also contribute to it—and it’s supported by many developer tools and, increasingly, a wide range of software and services used for other knowledge and creative work.

The buck technically stops with individual maintainers, not any of these companies themselves, but as noted above, some of the principal maintainers currently work at Anthropic.

https://arstechnica.com/ai/2026/07/with-a-stateless-makeover-new-mcp-spec-targets-enterprise-scale/

Unauthenticated attackers could exploit a critical-severity vulnerability in the open source AI agent orchestration platform Ruflo to execute commands inside the container, Noma Labs security researchers warn.

A popular automation assistant with over 67,000 GitHub stars, Ruflo (formerly Claude Flow) comes with a multi-model AI chat interface, agent swarms, persistent memory, and built-in Model Context Protocol (MCP) tool calling.

Ruflo allows organizations to use AI applications, courtesy of agent swarms (support for coordinating up to 100 agents on shared enterprise-grade tasks), long-term memory enabling agents to recall past interactions, and an integrated MCP server enabling agents to execute various tasks.

“The bridge exposes 233 tools covering shell access, database operations, agent management, and memory storage, making it the single point through which every agent action flows. Because the MCP Bridge requires direct access to the underlying system resources to execute these commands, it creates a high-stakes security boundary,” Noma explains.

Tracked as CVE-2026-59726 (CVSS score of 10/10), the security defect was found in the MCP bridge in ruflo/docker-compose.yml, which exposed the POST /mcp endpoint without authentication.

Because in default docker-compose deployments the bridge and MongoDB were bound to all interfaces, an unauthenticated attacker could invoke terminal_execute to run commands inside the bridge container, Ruflo’s advisory reads.

Successful exploitation of the bug could allow the attacker to gain shell access as node, read provider API keys, spawn swarms on the victim’s keys, and inject poison patterns into the AgentDB learning store to tamper with the AI outputs for all users.

According to Noma, which named the bug RufRoot, the root cause is that, in self-hosted deployments, the docker-compose.yml binds port 3001 to 0.0.0.0 by default, exposing all network-reachable instances to exploitation without authentication.

“The MCP Bridge isn’t a random auxiliary debug interface; rather, it is Ruflo’s central nervous system. Every tool call, every agent action, every memory operation goes through the MCP Bridge. Mistakenly giving unauthenticated access to the MCP Bridge means giving unauthenticated access to everything,” Noma explains.

With a single HTTP request targeting ruflo__terminal_execute, an attacker could take over the agent swarm, because the command would run as the container’s node user, providing access to all accessible assets without further escalation.

“Once you have command execution, achieving full compromise is just chaining more requests to the same endpoint,” Noma explains.

An attacker could exploit the vulnerability for reconnaissance, remote code execution (RCE), API key and conversation theft, spawning attacker-controlled agent swarms, poisoning the learning pipeline to produce attacker-influenced output, deploying persistent backdoors, and clearing shell history to remove traces.

The vulnerability was patched in Ruflo version 3.16.3. The fix addresses all attack vectors, and Ruflo’s maintainers published remediation steps for users with exposed instances.

Related: Chrome 151 Patches 370 Vulnerabilities

Related: Cisco Secure FMC Zero-Day Exploited in the Wild

Related: JFrog Zero-Days Exploited in OpenAI-Hugging Face Hack

Related: Critical Arista VeloCloud Orchestrator Vulnerability Exploited as Zero-Day

https://www.securityweek.com/critical-ruflo-flaw-lets-attackers-spawn-rogue-ai-swarms/

L’intelligenza artificiale generativa ha rapidamente trasformato il modo in cui vengono creati testi, immagini, musica e contenuti audiovisivi. A questa accelerazione tecnologica non ha però corrisposto, almeno finora, una definizione altrettanto chiara dei confini giuridici entro i quali tali sistemi possono operare.

Il diritto d’autore è uno dei terreni sui quali questa tensione emerge con maggiore evidenza. Da un lato, occorre stabilire quando un contenuto realizzato con l’ausilio dell’AI possa essere considerato il risultato di un’attività creativa umana e, quindi, essere protetto. Dall’altro, diventa necessario comprendere a quali condizioni le opere preesistenti possano essere utilizzate per l’addestramento dei modelli generativi.

È su questo duplice fronte — tutela degli output e legittimità degli input — che si concentra il Capitolo 6 del Report del Comitato sull’Intelligenza Artificiale istituito dall’AGCOM.

Il documento offre una ricostruzione ampia del quadro normativo e giurisprudenziale, ma soprattutto mette in evidenza un dato: le categorie tradizionali del diritto d’autore non sono state superate dall’innovazione tecnologica; devono, piuttosto, essere applicate a processi tecnici più opachi, complessi e difficili da verificare.

Il punto centrale, quindi, non è soltanto stabilire chi possa essere considerato autore di un contenuto prodotto con l’AI. La questione più delicata riguarda il controllo sulle opere impiegate per addestrare i modelli, la trasparenza dei processi e l’effettività dei diritti riconosciuti ai titolari.

L’intelligenza artificiale può essere autore?

Naturalmente no. Un sistema di intelligenza artificiale non può essere qualificato come autore, perché il diritto d’autore continua a presupporre un’attività intellettuale umana.

L’intera disciplina è costruita intorno a categorie che rinviano alla persona: creatività, personalità dell’autore, scelte libere e consapevoli, diritto morale, reputazione e durata della protezione.

Per quanto superfluo possa apparite, è sempre utile rammentare che una macchina non possiede coscienza, intenzionalità o personalità creativa, almeno per come inteso in senso giuridico; sarebbe quindi – perlomeno – fantasioso affermare che un strumento di AI possa subire una lesione, tanto di carattere morale quanto patrimoniale o addirittura che sia dotata di personalità giuridica in forza della quale rivendicare la paternità di un’opera.

Anche il confronto internazionale conferma, pur con soluzioni differenti, questa impostazione. Negli Stati Uniti la tutela resta subordinata alla human authorship; Cina e Messico pongono al centro la persona fisica; il Regno Unito attribuisce invece la paternità delle opere generate dal computer alla persona che ha predisposto gli strumenti necessari alla loro creazione.

La vera domanda, quindi, non è se la macchina possa diventare autore, ma quale contributo umano sia necessario affinché un’opera realizzata con strumenti di AI possa essere protetta.

Quando l’AI resta uno strumento

La distinzione individuata dal Report è chiara: le opere prodotte esclusivamente dal sistema restano estranee alla protezione, mentre quelle realizzate dall’essere umano con l’ausilio dell’AI possono essere tutelate, purché siano il risultato del suo lavoro intellettuale.

È questa la direzione seguita anche dal legislatore italiano, che ha riferito la tutela alle opere dell’ingegno umano create con l’ausilio di strumenti di intelligenza artificiale, a condizione che sia riconoscibile un effettivo apporto dell’autore.

L’IA può dunque essere utilizzata come una macchina fotografica, un software di grafica o un programma di elaborazione musicale. Ma la disponibilità dello strumento non basta. Occorre verificare se il risultato rifletta scelte creative personali.

Il precedente di “The Scent of the Night”

Il precedente relativo all’opera grafica “The Scent of the Night” è significativo. La Corte di Cassazione ha ritenuto che l’impiego di un software non escluda automaticamente la creatività, ma imponga un esame più rigoroso dell’apporto umano.

La pronuncia è stata emessa in seguito alla richiesta della creatrice dell’opera grafica “The Scent of the Night” dell’accertamento della violazione dei propri diritti d’autore, nonché della condanna della convenuta (RAI) al risarcimento dei danni per l’utilizzo, non autorizzato, della stessa come scenografia fissa del Festival di Sanremo 2016. Il Giudice di prime cure (Tribunale di Genova, sentenza 6 giugno 2018, n. 1640) ha accolto tale richiesta con pronuncia che ha poi superato indenne il vaglio critico del Giudice di Appello (Appello di Genova, sez. spec. in materia di imprese, sentenza 11 novembre 2020, n. 1066). All’esito la Corte di Cassazione, con ordinanza del 16 gennaio 2023, n. 1107, ha confermato gli orientamenti dei due precedenti gradi di giudizio attribuendo così carattere creativo ad una fotografia realizzata dal suo autore tramite un software di AI.

Ed infatti, secondo gli Ermellini “l’ammissione (..) di aver utilizzato un software per generare l’immagine” è “circostanza (..) pur sempre compatibile con l’elaborazione di un’opera dell’ingegno con un tasso di creativita che andrebbe solo scrutinato con maggior rigore (..)”.

Il medesimo criterio, evidentemente, può essere applicato alle opere generate mediante prompt.

Assumeranno rilievo la struttura delle istruzioni, il processo di selezione degli output, le modifiche successive, la combinazione dei risultati e ogni altra scelta capace di imprimere al contenuto una forma personale. Il semplice inserimento di una richiesta generica difficilmente potrà essere sufficiente.

Creatività e originalità non cambiano natura

L’ingresso dell’intelligenza artificiale nel processo creativo non modifica i requisiti fondamentali della tutela.

La Corte di giustizia dell’Unione europea, dalle decisioni Painer e Cofemel in poi, ha ricondotto la nozione di opera alla presenza di una creazione intellettuale propria dell’autore, espressa attraverso scelte libere e creative. L’oggetto deve inoltre essere identificabile con sufficiente precisione e oggettività.

La creatività non coincide con la novità assoluta dell’idea. Ciò che viene protetto è la forma espressiva, ossia il modo personale in cui un’idea viene selezionata, organizzata e rappresentata.

Questo criterio conserva piena validità anche per gli output generativi. La presenza dell’AI non amplia automaticamente l’area della protezione e non riduce la soglia di creatività. Chi invoca la tutela deve dimostrare che il risultato non deriva da un processo meramente automatico, ma incorpora un contributo umano riconoscibile.

Lo stesso vale per la contraffazione. La violazione non ricorre soltanto in caso di riproduzione integrale, ma anche quando l’opera successiva riprende i tratti espressivi essenziali di quella anteriore. Un output generato dall’AI può quindi risultare illecito quando riproduca elementi creativi di opere preesistenti, anche senza coincidere perfettamente con esse.

Il vero conflitto si sposta sull’addestramento

Il terreno più problematico non è però l’output, bensì l’input: i dati utilizzati per addestrare i modelli.

I sistemi generativi richiedono enormi quantità di testi, immagini, musica e contenuti audiovisivi, molti dei quali protetti dal diritto d’autore. Il punto è comprendere fino a che limite tali opere possano essere utilizzate per sviluppare sistemi commerciali capaci, a loro volta, di produrre contenuti concorrenti.

Il sistema europeo affronta la questione attraverso le eccezioni per il text and data mining. In linea generale, la riproduzione e l’estrazione possono essere consentite quando vi sia un accesso legittimo ai contenuti e il titolare non abbia espressamente riservato i propri diritti.

L’opt-out diventa così uno snodo decisivo. Il titolare deve poter manifestare efficacemente la volontà di escludere le proprie opere dal training; il fornitore deve essere in grado di rilevare e rispettare tale riserva.

È proprio qui, tuttavia, che emergono le maggiori criticità. Affermare che l’autore può esercitare l’opt-out non è sufficiente, se mancano modalità tecniche uniformi, strumenti di verifica e obblighi di trasparenza.

Il rischio è che la tutela venga trasferita interamente sul titolare, costretto a predisporre riserve tecniche, metadati e protocolli per impedire l’utilizzo delle proprie opere. Ma l’esclusiva nasce con la creazione e non dovrebbe dipendere dalla capacità dell’autore di dialogare con un crawler.

Un sistema fondato esclusivamente sull’opt-out rischia quindi di trasformare il mancato utilizzo di strumenti tecnologici in una forma di consenso implicito all’addestramento.

Text and data mining o memorizzazione?

Il Report dedica particolare attenzione alla decisione del Tribunale di Monaco nella controversia tra GEMA e OpenAI.

Secondo la ricostruzione accolta dai giudici tedeschi, l’utilizzo dei testi delle canzoni non poteva essere ricondotto alla sola analisi dei dati, perché alcuni contenuti risultavano incorporati nel modello e potevano essere riprodotti negli output.

È questa la distinzione più delicata: altro è estrarre informazioni da un’opera per individuare relazioni, schemi e regolarità; altro è memorizzarne parti sostanziali in modo da renderle nuovamente accessibili all’utente.

Nel primo caso può operare l’eccezione per il text and data mining. Nel secondo torna in rilievo il diritto esclusivo di riproduzione.

La decisione di Monaco deve essere letta insieme a quella del Tribunale di Amburgo del 2024, che aveva invece ritenuto legittima, nel contesto esaminato, la raccolta di opere per la creazione di un dataset destinato alla ricerca. Le due pronunce non sono necessariamente contraddittorie, ma mostrano come la valutazione dipenda dalla finalità dell’attività, dalle modalità di accesso ai contenuti e, soprattutto, dal modo in cui le opere vengono trattate dal modello.

Il vero discrimine sembra quindi essere la capacità del sistema di restituire porzioni riconoscibili delle opere utilizzate nel training. Quando ciò avviene, il processo non appare più soltanto analitico, ma incide sul normale sfruttamento economico dei contenuti.

Torna così in primo piano il three-step test: ogni eccezione deve riguardare casi speciali, non deve entrare in conflitto con il normale sfruttamento dell’opera e non deve arrecare un pregiudizio ingiustificato agli interessi del titolare.

Trasparenza e compliance tecnologica

Il Codice di Buone Pratiche per l’AI tenta di tradurre questi principi in obblighi operativi. I fornitori che utilizzano web crawler sono chiamati a rispettare le riserve espresse attraverso protocolli leggibili dalle macchine, a partire dal file robots.txt, nonché mediante metadati e altri standard tecnici.

È un passaggio importante, perché la tutela del diritto d’autore si sposta progressivamente dal solo piano giudiziario a quello dell’architettura tecnologica.

La riserva deve essere leggibile dalla macchina; il crawler deve essere progettato per riconoscerla; il fornitore deve documentare le fonti utilizzate e adottare procedure idonee a evitare l’acquisizione di contenuti non autorizzati.

La compliance, quindi, non può più coincidere con una verifica formale successiva. Deve essere incorporata nella progettazione del modello e nella governance dei dataset.

Resta però essenziale un obbligo effettivo di trasparenza. Senza informazioni sulle fonti e sui materiali impiegati, il titolare non è neppure in condizione di sapere se la propria opera sia stata utilizzata. Un diritto che non può essere verificato né fatto valere rischia di restare puramente teorico.

Governare l’innovazione, non impedirla

Il Report non considera l’intelligenza artificiale soltanto come una minaccia. Richiama anche applicazioni virtuose, come l’impiego della computer vision nella ricostruzione di affreschi, dipinti deteriorati e beni culturali.

L’esempio è importante perché dimostra che la disciplina non dovrebbe trasformarsi in una regolazione esclusivamente difensiva. Il problema non è impedire l’uso dell’AI, ma governarne le modalità.

La protezione dei diritti deve convivere con ricerca, innovazione e circolazione della conoscenza. Occorre evitare tanto un approccio tecnofobico, capace di paralizzare applicazioni socialmente utili, quanto un ottimismo tecnologico che consideri ogni contenuto disponibile online automaticamente utilizzabile per l’addestramento.

Il principio antropocentrico, in definitiva, non dovrebbe valere soltanto per stabilire chi sia autore dell’output. Dovrebbe orientare anche la disciplina dell’input, garantendo agli autori un controllo effettivo sull’utilizzo economico delle proprie opere.

Il rischio più concreto non è che le macchine diventino autori. È che gli autori umani conservino formalmente i propri diritti, ma perdano progressivamente la possibilità di conoscere, controllare e remunerare l’impiego delle loro opere nell’economia dell’intelligenza artificiale.

Novità su Google, per aggiungere Key4Biz tra le tue fonti preferite, clicca qui

Leggi le altre notizie sull’home page di Key4biz

https://www.key4biz.it/diritto-dautore-e-ai-generativa-le-nuove-sfide-della-tutela-nellera-di-chatgpt/582989/

Mythos helped to find a new meet-in-the-middle technique that relies on a Möbius Bridge, a more sophisticated fingerprinting algorithm used in meet-in-the-middle attacks. Using it, Green said, the code Mythos produced was able to reduce the number of required inputs to 2⁸⁹. Anthropic said that savings can reduce the time required for such attacks by 200- to 800-fold.

The ability to produce that many inputs makes the attack beyond reach outside of the laboratory. Further, the actual speed-up is unknown, since the weakened AES algorithm tested used only seven rounds. Specification-compliant AES, Green said, uses 10, 12, or 14 rounds, depending on key size.

Anthropic is careful to explicitly spell out most of these caveats. The Monday blog post goes on to argue, however, that the results are nonetheless meaningful and could ultimately fundamentally disrupt the process of cryptanalysis, or the adversarial testing of cryptosystems.

“The cybersecurity community is now grappling with the fact that language models are able to discover so many bugs that the standard human processes (like vulnerability triage, verification, and remediation) struggle to keep up,” Anthropic wrote. “We predict that the same will soon be true in academic cryptography research. As language models increasingly produce novel research outputs autonomously, human researchers may become bottlenecked on studying and validating these results for technical validity, novelty, and utility.”

Not mentioned in Anthropic’s report is whether its researchers used Mythos to attack more tested cryptosystems, such as elliptic curve cryptography and RSA. Attack improvements against these systems would be more impressive. By achieving the most impressive result against an algorithm still in its infancy, it’s not clear how much of an advantage Mythos truly provided. There’s no way of knowing if researchers using conventional cryptanalysis techniques were already close to discovering the same attack.

Ultimately, the lesson from the research is simple. AI-assisted cryptanalysis remains untested, and providers of these platforms have a vested interest in exaggerating their benefits. At the same time, there’s growing evidence that LLMs may provide significant advantages in finding cryptographic weaknesses. It would be a mistake to conclude that LLMs won’t one day play an important role in the race between securing and compromising our most vital assets.

The headline and body of this story have been updated to reflect the withdrawing of HAWK.

https://arstechnica.com/security/2026/07/mythos-uncovers-crypto-weaknesses-that-went-unknown-for-years/

Boston Dynamics has already been making its Atlas humanoid robot, along with its four-legged Spot robot and wheeled Stretch robot, at its main facility in Waltham, Massachusetts. The US robotics company is also planning to massively scale up manufacturing of the Atlas robot under South Korea’s Hyundai Motor Company, which gained full ownership of Boston Dynamics in July 2026.

“This is one of the strongest technology-security actions in modern US history,” wrote Evan Beard, CEO of Standard Bots, in a LinkedIn post. “The message is unambiguous: robotics is a technology America must lead and own—and foreign-subsidized robots will not be allowed to unfairly dominate US robotics as they did solar.”

Similar praise came from Rush Doshi, director of the Initiative on China Strategy at the Council on Foreign Relations, who, in a social media post, described the FCC decision as “one of the most significant actions taken so far in support of the US robotics ecosystem.”

However, several robotics researchers and analysts interviewed by The Robot Report expressed skepticism about any potential boost to US competitiveness in robotics. Some even warned that the ban could prove counterproductive for US robotics efforts to develop humanoid robots.

“In the near term, the measure could slow US physical AI innovation by cutting startups and researchers off from future low-cost Chinese platforms before comparable Western alternatives exist,” said Georg Stieler, a global robotics advisor and managing director for Asia at Stieler Technology & Market Advisory, in an interview with The Robot Report.

US domestic production of robots lags behind China in terms of mass manufacturing at lower cost, said Rueben Scriven, a senior analyst at Interact Analysis. “This announcement is more likely to inhibit the US humanoid robotics industry, as the presence of low-cost Chinese humanoid robots has been helping educate the US market through promotional and entertainment use cases—an effect this policy risks undermining,” Scriven told The Robot Report.

The outcome of previous FCC bans is also not necessarily encouraging. US government restrictions on drones made by Chinese companies such as DJI have failed to create a “competitive mass-market consumer-drone producer” based in the United States, Stieler pointed out. The Verge has also reported that newly created companies have popped up to sidestep the US ban on foreign drones by selling “barely disguised versions of DJI technology.”

This story was updated on July 30, 2026 to include China’s Ministry of Commerce response to the FCC decision.

https://arstechnica.com/ai/2026/07/who-wins-and-who-loses-after-us-bans-foreign-robots/

“A company whose users request just ten images in violation of the statute would face exposure up to $5 million in civil penalties alone. A company with a thousand violative images could be fined up to $500 million. And a business whose users created a hundred thousand images covered by [the law] (not at all unlikely for a publicly available program with millions of users generating billions of images) could owe an eye-popping $50 billion dollars.”

Additionally, the law gives victims a right to sue xAI over any individual output, which increases xAI’s financial risks.

The penalties are so severe, xAI said in its lawsuit that it was finally preparing to update Grok to block harmful outputs after more than six months of backlash and probes pressuring the firm to tighten its safeguards.

“Confronted with $500,000-per-image strict liability and no safe harbor, xAI has no practical choice but to restrict Grok Imagine’s image-editing features in various ways when the statute takes effect on August 1, 2026,” xAI argued. “Protected speech freely available before the law takes effect will thus be chilled.”

However, xAI would prefer to leave Grok unchanged and continue relying on its terms of use stipulating that users could be banned for using Grok to make CSAM or other kinds of non-consensual intimate images (NCII), its complaint said.

“But for [the law] and its penalties, xAI would continue to offer the editing feature exactly as it does today,” xAI said.

Nudification law is unconstitutional, xAI says

To defend Grok, Musk’s firm is turning to the First Amendment, arguing that Minnesota’s law is a “clumsy attempt to prohibit ‘nudification’” that “sweeps in a wide range of fully protected speech.” That includes nude images generated with “artistic, scientific, political, satirical, educational, medical, or religious value,” xAI argued.

Most egregiously, “liability attaches even if the depicted persons consented—or created the image themselves—and even if the image is never shared,” xAI emphasized in its complaint.

Minnesota has less restrictive means to block harms from nudification, xAI argued, while claiming that the Take It Down Act already protected users from harms of distribution.

https://arstechnica.com/tech-policy/2026/07/elon-musks-xai-is-trying-to-sue-its-way-out-of-a-grok-reckoning/

Nvidia and a large group of technology, cybersecurity, and enterprise software companies announced on Monday the launch of the Open Secure AI Alliance, a new initiative aimed at developing and sharing open source tools, models, and techniques for securing AI systems and agents. 

The effort builds on existing work from the Linux Foundation’s recently launched Akrites initiative and the OpenSSF community.

Inaugural partners of the Open Secure AI Alliance also include Adobe, Cadence, Capital One, Cisco, Cloudera, Cloudflare, Cognition, CrowdStrike, Databricks, Dell, DoorDash, Elastic, HPE, Hugging Face, IBM, LangChain, Microsoft, Naver, NetApp, Nous Research, OpenClaw, Palantir, Palo Alto Networks, Red Hat, Reflection AI, Salesforce, SAP, SK Telecom, ServiceNow, Siemens, Snowflake, SpaceXAI, Synopsys, Thinking Machines Lab, and TrendAI.

Nvidia’s contribution to the project includes open models, weights, data, and agent harness research, including a newly released open source project called NOOA, designed to help harnesses make agent behavior easier to trace, test, and audit.

HPE is contributing to SPIFFE/SPIRE, a zero-trust identity framework for cryptographically verifying AI agents and services, while Hugging Face is donating its Safetensors model weight storage format to the PyTorch Foundation.

IBM and Red Hat are extending open source supply chain security through the Lightwell project, which is designed to deliver automated vulnerability remediation at scale.

Microsoft is contributing MDASH, a multi-model agentic scanning harness that coordinates AI agents to find, debate, and validate exploitable software bugs.

SpaceXAI is open-sourcing its Grok Build terminal-based AI coding agent, with plans to eventually open-source the weights of the Grok model line.

The new alliance argues that open models, harnesses, and security tooling should be treated as defensive assets rather than liabilities, and warns policymakers and regulators that broad restrictions on open frontier AI could weaken collective cyber defense capacity.

Learn More at the AI Risk Summit | Ritz-Carlton, Half Moon Bay

Nvidia points to the recent security incident involving OpenAI and Hugging Face, noting that when closed AI tools could not differentiate between attackers and defenders and blocked forensic work, Hugging Face used the open-weight GLM 5.2 model on its own systems to review over 17,000 actions and contain the breach.

“The right response is not to deny defenders access to capable open systems. It is to pair openness with strong safeguards, clear rules against malicious misuse, rigorous evaluation and rapid remediation. In cybersecurity, the safer path is the one that gives more defenders the ability to test, verify and strengthen the systems on which society relies,” Nvidia said.

“Defenders need both frontier closed models and frontier open models, working together, so they can choose the right system for the job and ensure that transparency, adaptation and sovereign control are available wherever security demands them,” it added.

Related: Anthropic’s Opus 5 Nears Mythos 5 on Finding Bugs, but Falls Short on Exploits

Related: White House Launches AI-Driven ‘Gold Eagle’ Vulnerability Coordination Initiative

Related: OpenAI Fixes ChatGPT Agent Flaw That Could Let Attackers Forge an AI Insider

Related: Nuclear-Sabotage Malware Benchmark Trips Up Most Frontier AI Models

https://www.securityweek.com/nvidia-and-tech-giants-launch-ai-security-alliance/

Anyone who has used the Internet in recent years is probably used to encountering telltale signs of LLM prompting that lazy users sometimes forget to remove from their AI-generated pabulum. But a Canadian legislator took that idea to an embarrassing new level this week, reading an apparent LLM prompt instruction into the record during a floor speech.

Bill Oliver, a Progressive Conservative Party member of the legislative assembly of New Brunswick, noted in a speech last month that “One of the dangers associated with creating advocacy offices is that citizens often develop expectations that exceed the powers actually granted to those offices.” He then went on to say out loud that “here’s a more natural, flowing version of that section that reads like a legislative speech rather than a series of short points,” a line with all the hallmarks of an LLM presenting an alternative style option in response to a prompt.

The odd reading went more or less unnoticed at the time, but video of the remarks started spreading around social media networks like Reddit and Threads earlier this week. In Canada, the snafu is now getting mainstream attention from the likes of the Canadian Broadcasting Corporation and The Toronto Star, the latter of which called it a sign of “a growing divide in our society: between the elites, who are only too happy to delegate their duties to the Borg; and the masses, who find this objectionable.”

https://arstechnica.com/ai/2026/07/canadian-legislator-reads-out-apparent-llm-response-in-floor-speech/