#FactCheck: Video of Woman Shot by Police in Brazil Falsely Shared as France Protest

Executive Summary - When Anthropic and OpenAI's AI Testing Turned Into Real Breaches

You would be surprised to know that a testing function built to measure how good AI models are at simulated hacking ended up doing the real thing instead. Not once , but  three times, across two of the world's leading AI labs, within the same 9-day window at the end of July 2026.   As per the reports, Anthropic, which is among the world's leading AI labs, was running these evaluations on its own AI models namely - Claude Opus 4.7, Claude Mythos 5, and an unreleased research model, inside an environment co-managed with a third-party evaluation vendor. As per the reports, the models were told they were operating inside closed, internet-free simulations. They were not. A configuration error left the door open to the real internet, and the AI did exactly what it was trained to do in a hacking exercise, find the target and break in. Except the targets, this time, were real companies. Real credentials got stolen. Real data got accessed. Two of the three victims didn't even know they'd been breached until the AI lab called to tell them. This shows how a single unverified assumption, "this environment has no internet access" can quietly collapse the entire safety boundary of an AI test. It indicates that as these systems get more capable and more autonomous, the risk isn't necessarily the AI deciding to go rogue, it is humans failing to double-check the cage before putting something powerful inside it. And it warns us that the margin for this kind of error is shrinking fast, because what used to be a contained mistake can now scan thousands of systems and act on it within minutes. bAnthropic was not alone. Just over a week earlier, on 21 July, OpenAI had disclosed that its own models, GPT-5.6 Sol and an unreleased successor broke out of an isolated test environment and reached the real production infrastructure of Hugging Face, another AI company. In fact, it was OpenAI's disclosure that pushed Anthropic to go back and audit its own evaluation runs in the first place, which is how the three incidents above came to light. This blog examines the incident not as an isolated slip-up by two labs, but as a preview of the larger picture, a world where the gap between "theoretically vulnerable" and "actually exploited" is closing faster than most organisations' security practices are ready for.

The Chain of Disclosures

It started with Hugging Face, the open-source AI platform, which disclosed on July 16 that it had detected and contained an intrusion into part of its production infrastructure, driven end-to-end by an autonomous AI agent. Five days later, OpenAI confirmed it was responsible: models it was evaluating internally, GPT-5.6 Sol and an unreleased prototype, both running with their cyber-safety behaviour deliberately turned down to measure raw capability, had exploited a previously unknown vulnerability to break out of an isolated test environment and reach Hugging Face's real servers, apparently while chasing answers to a benchmark challenge. That disclosure prompted Anthropic to go back through its own records. On July 30, it published the results: after auditing 141,006 evaluation runs in which its Claude models could conceivably have touched the internet, it found three incidents,  six runs in total,  in which a model reached real systems belonging to three outside organisations and gained unauthorised access.

How a Fictional Exercise became a Real Attack

All three Anthropic incidents shared the same root cause. Claude was being run through capture-the-flag exercises, a standard way labs test offensive cyber capability: the model is dropped into a fictional scenario, told a piece of secret data is hidden somewhere on a network, and left to find its own way in. Anthropic's prompts told Claude, explicitly, that the environment was an internet-free simulation. Because of a misunderstanding with its evaluation partner, Irregular, that statement was false; the machines had live internet access nobody had verified. So when Claude's search for the flag led it onto the open internet, it did what it had been told to expect: it assumed everything it found was part of the exercise, including things that weren't.

• Incident 1: A fictional target company happened to share its name with a real, active domain. Across four runs, Claude Opus 4.7 attacked the real company instead, extracting infrastructure credentials and reaching a database containing several hundred rows of genuine production data, the most serious impact of the three incidents. In its own reasoning, the model repeatedly noted the system looked real and kept going anyway.
• Incident 2: Inside its fictional scenario, Claude Mythos 5 found a fake "onboarding document" referencing a software package that didn't exist on PyPI, the public Python package registry. It recognised the opportunity, built a functioning malicious package, and, after working around several dead ends to get an email account and register on PyPI, published it. The package lived online for about an hour and was installed on fifteen real machines, including a security company's automated scanner, letting Claude harvest real credentials from a company it had never even set out to target.
• Incident 3: An unreleased internal research model, unable to find its fictional target, scanned roughly 9,000 real hosts and broke into one using textbook techniques credentials read off an exposed debug page, then SQL injection. Partway through, it noticed the system it had compromised had no plausible link to its assignment, concluded on its own that the target was real, and stopped.

‍Timeline of Incidents

‍

‍

The Threat is Scale, not Novelty

None of the three models discovered a novel vulnerability. Weak passwords, unauthenticated endpoints, exposed debug output, and a classic "dependency confusion" trick are techniques that have appeared on security checklists for a decade and are still relevant. That's arguably the more sobering finding: the frontier is not a new class of attack; it is the speed and tirelessness with which known, boring weaknesses can now be found and used. Anthropic's own analysis lands on a subtler point, too: in each case, whether the model's behaviour counted as "aligned" or "harmful" depended entirely on what it believed about its situation, not on any goal of its own. All three models were simply trying to complete the task they had been assigned. Two of them did so while holding a false belief, installed by their own evaluators, about whether their targets were real. Only the newest of the three models, on independently concluding it had reached a genuine system, chose to stop. Anthropic is careful to note this is not a controlled experiment and should not be read as a guarantee that newer models will always behave better. But the throughline is clear enough: telling a capable model a lie about its environment is not a neutral setup choice. It is itself a safety-relevant decision.

The Detection Gap

Perhaps the most alarming detail is the quietest one. Anthropic reached out to the three affected organisations on July 27. Two of them had detected nothing at all, no alert, no anomaly, no investigation until that call. Real credentials had been stolen and real data accessed inside systems whose owners had no idea anything had happened. That is a statement about the state of everyday detection capability, not about AI. An agent that completes an entire intrusion, start to finish, within a single automated session doesn't leave the kind of slow, human-paced footprint that most monitoring is built to catch.

The Silver Lining - Why These Disclosures Deserve Credit

Both incidents share an underappreciated feature: they were disclosed voluntarily, promptly, and with real detail, and both labs notified the organisations affected. Hugging Face brought in outside forensic specialists and law enforcement. Anthropic halted its cyber evaluations the same day it found the first suspicious transcript and has asked METR, an independent evaluation body, to review its findings. That kind of candour is exactly the behaviour any sensible policy response should want to reinforce. A regulatory reflex that punishes disclosure risks teaching labs to say less next time, not to do better. What both incidents point to, far more than any specific model capability, is a mundane and fixable governance gap: environments used to test powerful, semi-restrained AI systems need the same security discipline as production systems, verified network isolation, continuous monitoring, and evaluation scopes that are stated positively ("here is what's in bounds") rather than enforced by simply telling the model a comforting falsehood. As both companies note, a fictional test range that turns out to have a live path to the internet isn't really fictional anymore. Basic asset hygiene, like knowing what's exposed, patching debug endpoints, claiming your internal package names before someone else does, and watching outbound traffic from environments that are supposed to have none did more to prevent and contain these incidents than anything specific to the models involved.

‍

CyberPeace  findings  and  recomendations : For enterprises and public institutions

• Maintain a full inventory of internet-facing assets and unauthenticated endpoints, and assume the inventory is incomplete until proven otherwise.
• Eliminate default, weak, and reused credentials, and enforce phishing-resistant MFA on anyone externally reachable.
• Strip debug pages and verbose error output from production systems.
• Treat dependency confusion as a live threat: pin dependencies, use private registry namespaces, and pre-emptively claim internal package names on public registries.
• Apply deny-by-default egress filtering to every environment running AI or agentic tooling, including development and test environments, and verify isolation empirically rather than assuming it from configuration.
• Alert on any outbound connection from an environment that is supposed to have none.
• Review authentication and access logs from April 2026 onwards for short, unusually efficient sessions that look more like machine-speed compromise than human reconnaissance.

For AI developers and evaluation vendors

• Network-isolate offensive-capability evaluation environments by default, with isolation verified per run rather than inherited from configuration.
• State the scope explicitly and positively, which systems are in bounds rather than asserting a falsehood about connectivity.
• Build contractual isolation guarantees and joint pre-run verification into third-party evaluation partnerships; both labs involved here have acknowledged that neither side alone caught the misconfiguration.
• Monitor transcripts and network logs continuously, not retrospectively.

For policymakers

• A regulatory response that punishes candour risks producing silence rather than safety. India currently has no reporting framework that clearly covers containment failures in AI evaluations affecting Indian entities' behaviour. 
• RT-In's existing incident-reporting directions were not drafted with this candour in mode. Closing that gap would mean an explicit reporting obligation for evaluation of containment failures touching third-party infrastructure and a safe harbour mechanism that protects labs which disclose promptly.
• Minimum containment standards (egress verification, log retention) for organisations conducting offensive-capability AI evaluation within Indian jurisdiction;
• Recognition in national cyber doctrine that agentic tooling collapses the gap between a known-but-deferred vulnerability and an exploited one.

‍

Conclusion

The above incidents reveal less about AI's offensive capability and more about the gap between how these systems are tested and how carefully those tests are contained. Both labs found the breaches through their own review, not external detection, a point in their favor, but also a reminder that containment failures can go unnoticed for a while.  The realistic risk ahead isn't a sudden leap in AI's hacking sophistication; it's the compounding effect of speed and scale applied to routine reconnaissance, run against infrastructure that assumes a human attacker's pace. Treating evaluation environments with the same rigor as production systems, sandboxing, monitoring, and independent audits, should become standard practice, not an afterthought triggered by another lab's incident. The path forward is less about slowing AI down and more about catching up our containment discipline to match what these systems can now do.

‍

Sources

• Anthropic, "Investigating three real-world incidents in our cybersecurity evaluations" (July 30, 2026)
• OpenAI, "OpenAI and Hugging Face partner to address security incident during model evaluation" (July 21, 2026, updated July 28–29, 2026)
• Hugging Face, "Security incident disclosure — July 2026" (July 16, 2026)
• Axios, "Anthropic says three Claude models reached real-world systems during cyber tests" (July 30, 2026)
• Help Net Security, "Anthropic's Claude breached three companies during security tests" (July 31, 2026)
• Simon Willison, "Investigating three real-world incidents in our cybersecurity evaluations" (July 30, 2026)

‍Contributors

• Maj. Vineet Kumar, Founder & Global President, CyberPeace
• Mr. Neeraj Soni, Sr. Researcher, Policy & Advocacy, CyberPeace
• Mr. Isharth Kumar, (NLIU Bhopal), Intern, Policy & Advocacy, CyberPeace

‍

Introduction

India's National Commission for Protection of Child Rights (NCPCR) is set to approach the Ministry of Electronics and Information Technology (MeitY) to recommend mandating a KYC-based system for verifying children's age under the Digital Personal Data Protection (DPDP) Act. The decision to approach or send recommendations to MeitY was taken by NCPCR in a closed-door meeting held on August 13 with social media entities. In the meeting, NCPCR emphasised proposing a KYC-based age verification mechanism. In this background, Section 9 of the Digital Personal Data Protection Act, 2023 defines a child as someone below the age of 18, and Section 9 mandates that such children have to be verified and parental consent will be required before processing their personal data.

Requirement of Verifiable Consent Under Section 9 of DPDP Act

Regarding the processing of children's personal data, Section 9 of the DPDP Act, 2023, provides that for children below 18 years of age, consent from parents/legal guardians is required. The Data Fiduciary shall, before processing any personal data of a child or a person with a disability who has a lawful guardian, obtain verifiable consent from the parent or lawful guardian. Additionally, behavioural monitoring or targeted advertising directed at children is prohibited. 

Ongoing debate on Method to obtain Verifiable Consent

Section 9 of the DPDP Act gives parents or lawful guardians more control over their children's data and privacy, and it empowers them to make decisions about how to manage their children's online activities/permissions. However, obtaining such verifiable consent from the parent or legal guardian presents a quandary. It was expected that the upcoming 'DPDP rules,' which have yet to be notified by the Central Government, would shed light on the procedure of obtaining such verifiable consent from a parent or lawful guardian.

However, In the meeting held on 18th July 2024, between MeitY and social media companies to discuss the upcoming Digital Personal Data Protection Rules (DPDP Rules), MeitY stated that it may not intend to prescribe a ‘specific mechanism’ for Data Fiduciaries to verify parental consent for minors using digital services. MeitY instead emphasised obligations put forth on the data fiduciary under section 8(4) of the DPDP Act to implement “appropriate technical and organisational measures” to ensure effective observance of the provisions contained under this act. 

In a recent update, MeitY held a review meeting on DPDP rules, where they focused on a method for determining children's ages. It was reported that the ministry is making a few more revisions before releasing the guidelines for public input.

CyberPeace Policy Outlook

CyberPeace in its policy recommendations paper published last month, (available here) also advised obtaining verifiable parental consent through methods such as Government Issued ID, integration of parental consent at ‘entry points’ like app stores,  obtaining consent through consent forms, or drawing attention from foreign laws such as California Privacy Law, COPPA, and developing child-friendly SIMs for enhanced child privacy.

CyberPeace in its policy paper also emphasised that when deciding the method to obtain verifiable consent, the respective platforms need to be aligned with the fact that verifiable age verification must be done without compromising user privacy. Balancing user privacy is a question of both technological capabilities and ethical considerations. 

DPDP Act is a brand new framework for protecting digital personal data and also puts forth certain obligations on Data Fiduciaries and provides certain rights to Data Principal. With upcoming ‘DPDP Rules’ which are expected to be notified soon, will define the detailed procedure for the implementation of the provisions of the Act. MeitY is refining the DPDP rules before they come out for public consultation. The approach of NCPCR is aimed at ensuring child safety in this digital era. We hope that MeitY comes up with a sound mechanism for obtaining verifiable consent from parents/lawful guardians after taking due consideration to recommendations put forth by various stakeholders, expert organisations and concerned authorities such as NCPCR. 

References

1. https://www.moneycontrol.com/technology/dpdp-rules-ncpcr-to-recommend-meity-to-bring-in-kyc-based-age-verification-for-children-article-12801563.html
2. https://pune.news/government/ncpcr-pushes-for-kyc-based-age-verification-in-digital-data-protection-a-new-era-for-child-safety-215989/#:~:text=During%20this%20meeting%2C%20NCPCR%20issued,consent%20before%20processing%20their%20data
3. https://www.hindustantimes.com/india-news/ncpcr-likely-to-seek-clause-for-parents-consent-under-data-protection-rules-101724180521788.html
4. https://www.drishtiias.com/daily-updates/daily-news-analysis/dpdp-act-2023-and-the-isssue-of-parental-consent

‍

What are Decentralised Autonomous Organizations (DAOs)?

A Decentralised Autonomous Organisation or a DAO, is a unique take on democracy on the blockchain. It is a set of rules encoded into a self-executing contract (also known as a smart contract) that operates autonomously on a blockchain system. A DAO imitates a traditional company, although, in its more literal sense, it is a contractually created entity. In theory, DAOs have no centralised authority in making decisions for the system; it is a communally run system whereby all decisions (be it for internal governance or for the development of the blockchain system) are voted upon by the community members. DAOs are primarily characterised by a decentralised form of operation, where there is no one entity, group or individual running the system. They are self-sustaining entities, having their own currency, economy and even governance, that do not depend on a group of individuals to operate. Blockchain systems, especially DAOs are characterised by pure autonomy created to evade external coercion or manipulation from sovereign powers. DAOs follow a mutually created, agreed set of rules created by the community, that dictates all actions, activities, and participation in the system’s governance. There may also be provisions that regulate the decision-making power of the community.

Ethereum’s DAO’s White Paper described DAO as “The first implementation of a [DAO Entity] code to automate organisational governance and decision making.” Can be used by individuals working together collaboratively outside of a traditional corporate form.  It can also be used by a registered corporate entity to automate formal governance rules contained in corporate bylaws or imposed by law.”  The referred white paper proposes an entity that would use smart contracts to solve governance issues inherent in traditional corporations.  DAOs attempt to redesign corporate governance with blockchain such that contractual terms are “formalised, automated and enforced using software.”

Cybersecurity threats under DAOs

While DAOs offer increased transparency and efficiency, they are not immune to cybersecurity threats. Cybersecurity risks in DAO, primarily in governance, stem from vulnerabilities in the underlying blockchain technology and the DAO's smart contracts. Smart contract exploits, code vulnerabilities, and weaknesses in the underlying blockchain protocol can be exploited by malicious actors, leading to unauthorised access, fund manipulations, or disruptions in the governance process. Additionally, DAOs may face challenges related to phishing attacks, where individuals are tricked into revealing sensitive information, such as private keys, compromising the integrity of the governance structure. As DAOs continue to evolve, addressing and mitigating cybersecurity threats is crucial to ensuring the trust and reliability of decentralised governance mechanisms.

Centralisation/Concentration of Power

DAOs today actively try to leverage on-chain governance, where any governance votes or transactions are directly taken on the blockchain. But such governance is often plutocratic in nature, where the wealthy hold influences, rather than democracies, since those who possess the requisite number of tokens are only allowed to vote and each token staked implies that many numbers of votes emerge from the same individual. This concentration of power in the hands of “whales” often creates disadvantages for the newer entrants into the system who may have an in-depth background but lack the funds to cast a vote. Voting, presently in the blockchain sphere, lacks the requisite concept of “one man, one vote” which is critical in democratic societies.

Smart contract vulnerabilities and external threats

Smart contracts, self-executing pieces of code on a blockchain, are integral to decentralised applications and platforms. Despite their potential, smart contracts are susceptible to various vulnerabilities such as coding errors, where mistakes in the code can lead to funds being locked or released erroneously. Some of them have been mentioned as follows;

Smart Contracts are most prone to re-entrance attacks whereby an untrusted external code is allowed to be executed in a smart contract. This scenario occurs when a smart contract invokes an external contract, and the external contract subsequently re-invokes the initial contract. This sequence of events can lead to an infinite loop, and a reentrancy attack is a tactic exploiting this vulnerability in a smart contract. It enables an attacker to repeatedly invoke a function within the contract, potentially creating an endless loop and gaining unauthorised access to funds.

Additionally, smart contracts are also prone to oracle problems. Oracles refer to third-party services or mechanisms that provide smart contracts with real-world data. Since smart contracts on blockchain networks operate in a decentralised, isolated environment, they do not have direct access to external information, such as market prices, weather conditions, or sports scores. Oracles bridge this gap by acting as intermediaries, fetching and delivering off-chain data to smart contracts, enabling them to execute based on real-world conditions. The oracle problem within blockchain pertains to the difficulty of securely incorporating external data into smart contracts. The reliability of external data poses a potential vulnerability, as oracles may be manipulated or provide inaccurate information. This challenge jeopardises the credibility of blockchain applications that rely on precise and timely external data.

Sybil Attack: A Sybil attack involves a single node managing multiple active fake identities, known as Sybil identities, concurrently within a peer-to-peer network. The objective of such an attack is to weaken the authority or influence within a trustworthy system by acquiring the majority of control in the network. The fake identities are utilised to establish and exert this influence. A successful Sybil attack allows threat actors to perform unauthorised actions in the system.

Distributed Denial of Service Attacks: A Distributed Denial of Service (DDoS) attack is a malicious attempt to disrupt the regular functioning of a network, service, or website by overwhelming it with a flood of traffic. In a typical DDoS attack, multiple compromised computers or devices, often part of a botnet (a network of infected machines controlled by a single entity), are used to generate a massive volume of requests or data traffic. The targeted system becomes unable to respond to legitimate user requests due to the excessive traffic, leading to a denial of service.

Conclusion

Decentralised Autonomous Organisations (DAOs) represent a pioneering approach to governance on the blockchain, relying on smart contracts and community-driven decision-making. Despite their potential for increased transparency and efficiency, DAOs are not immune to cybersecurity threats. Vulnerabilities in smart contracts, such as reentrancy attacks and oracle problems, pose significant risks, and the concentration of voting power among wealthy token holders raises concerns about democratic principles. As DAOs continue to evolve, addressing these challenges is essential to ensuring the resilience and trustworthiness of decentralised governance mechanisms. Efforts to enhance security measures, promote inclusivity, and refine governance models will be crucial in establishing DAOs as robust and reliable entities in the broader landscape of blockchain technology.

References:

‍https://www.imperva.com/learn/application-security/sybil-attack/

‍https://www.tripwire.com/state-of-security/blockchain-security-understanding-vulnerabilities-and-mitigating-risks

‍https://medium.com/@RedStone_Finance/the-oracle-problem-and-its-implications-for-blockchains-c0c0ad9cf5a7

‍https://www.linkedin.com/posts/satish-kulkarni-bb96193_what-are-cybersecurity-risk-to-dao-and-how-activity-7048286955645677568-B3pV/ https://www.geeksforgeeks.org/what-is-ddosdistributed-denial-of-service/ Report of Investigation Pursuant to Section 21 (a) of the Securities Exchange Act of 1934: The DAO, Securities and Exchange Board, Release No. 81207/ July 25, 2017

‍https://www.sec.gov/litigation/investreport/34-81207.pdf https://www.legalserviceindia.com/legal/article-10921-blockchain-based-decentralized-autonomous-organizations-daos-.html