#FactCheck -Edited Jaishankar Video Falsely Links Him to ‘Cockroach Party’ Remarks; Fact Check Finds No Such Statement

Introduction

The Ministry of Electronics and Information Technology ( MeitY) through its Information Security Education & Awareness ( ISEA ) came up with an advisory regarding the growing cases of e-challan fraud. Cybercriminals are exploiting the beliefs of individuals by attracting them into clicking malicious links under the impression of paying traffic fines. Cybercriminals employ sending phishing messages and impersonating official e-challan notifications as a primary method. These messages are crafted in such a way that portrays a sense of urgency, provoking individuals to click on a link for spontaneous payment. For building trust, the messages are deviously created by scammers depicting official communication, which in actuality are fake messages targeting individuals for committing online financial fraud.

Unveiling the E-Challan Scam

Scammers send a text message to your phones that closely resembles e-challan alerts. The text appears from the traffic police, informing the netizens of a traffic violation that requires a fine payment. These messages contain a link and a text message urging the recipient to settle the fine by clicking on the links to make the payment.  Scammers have started trapping innocent individuals through such fake messages. These scammers are creating and sending fake messages that look like traffic challan alert messages. However, it is a completely deceptive and fake message. Such messages contain malicious links to fake website, leading users to visit the fake website and enter their bank account details, or make the payment which ultimately leads to financial loss to victims. Cyber scammers have meticulously copied the format used by the traffic authorities however a close examination can help us spot the trap. The modus operandi of such type of scam is to get the targeted individuals to click on a malicious link for payment of traffic e-challan. Once you click on such malicious payment link to pay for the e-challan the individuals unknowingly will end up paying the cyber criminals instead of the police in a bid to discharge the traffic e-challan.

How to spot a fake E-Challan?

• Verify the Vehicle Number: Make sure that the vehicle number mentioned in the message matches your vehicle’s number. Cross-check this information with your vehicle’s number plate or the smart card ( blue book) issued by the Regional Transport Office ( RTO).
• Verify the E-challan Number: Verify the validity of the e-challan number by logging into the official traffic police website or app. Legitimate e-challans will have a corresponding record that can be cross-checked for authenticity. The challan number can be verified by logging in to the official e-challan website. It is always advisable to Visit the official government website to check if you have actually been fined.
• Inspect the Message Content: Give attention to the language inculcated in the message. Hackers' messages may contain grammatical errors or unusual phrases. For example, cybercriminals might encourage victims to visit the RTO office in person. Trying to build up confidence among the victims. Also, it is important that you do not make such payments in haste. Vehicle owners must check such messages carefully before clicking on any link.

Best Practices to Stay Safe

• Be aware of unbidden messages: Be cautious when you receive unsolicited e- challan notifications. Abstain yourself by clicking on links or downloading attachments from unknown sources. 
• Always stick to legitimate or official websites: The scammers use links which look similar to the official link, and a casual glance can miss the difference. Hence it is strictly advisable to visit the official websites only. Also do note that government websites will always have the domain '.gov.in'.  The official website of Traffic Challan is https://echallan.parivahan.gov.in/ 
• Get it cross-checked through official channels: Always cross-check the authenticity of an e-challan by directly accessing official channels, such as the official traffic police website or application. 
• Connect with the RTO directly: If in doubt, independently connect with the Regional Transport Office ( RTO) using official contact details to verify the authenticity of the e-challan.  It is best not to solely rely on information received from suspicious messages. 
• Software update: Make sure that your device’s security software is up to date to protect against malware and phishing scams.

Conclusion:

Cybercriminals are exploiting the fear of traffic fines to trick individuals into clicking on malicious links and revealing their personal and financial information. These scams can lead to significant financial losses for the victims. To stay safe, it is important to be cautious of unsolicited messages, verify the authenticity of e-challans through official channels, and avoid clicking on links or downloading attachments from unknown sources. Awareness is the first line of defence in the evolving landscape of online threats. 

References:

• https://economictimes.indiatimes.com/news/new-updates/ahmedabad-residents-duped-out-of-lakhs-in-e-challan-scam-cops-arrest-jharkhand-man/articleshow/103528317.cms
• https://economictimes.indiatimes.com/wealth/save/new-traffic-e-challan-fraud-heres-how-to-identify-scam-messages-and-avoid-getting-duped/articleshow/104960817.cms
• https://www.ndtv.com/india-news/explained-the-new-e-challan-scam-how-we-can-escape-it-4342129

‍

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

On March 12, the Ministry of Corporate Affairs (MCA) proposed the Bill to curb anti-competitive practices of tech giants through ex-ante regulation. The Draft Digital Competition Bill is to apply to ‘Core Digital Services,’ with the Central Government having the authority to update the list periodically. The proposed list in the Bill encompasses online search engines, online social networking services, video-sharing platforms, interpersonal communications services, operating systems, web browsers, cloud services, advertising services, and online intermediation services. 

The primary highlight of the Digital Competition Law Report created by the Committee on Digital Competition Law presented to the Parliament in the 2nd week of March 2024 involves a recommendation to introduce new legislation called the ‘Digital Competition Act,’ intended to strike a balance between certainty and flexibility. The report identified ten anti-competitive practices relevant to digital enterprises in India. These are anti-steering, platform neutrality/self-preferencing, bundling and tying, data usage (use of non-public data), pricing/ deep discounting, exclusive tie-ups, search and ranking preferencing, restricting third-party applications and finally advertising Policies.

Key Take-Aways: Digital Competition Bill, 2024

1. Qualitative and quantitative criteria for identifying Systematically Significant Digital Enterprises, if it meets any of the specified thresholds. 

• Financial thresholds in each of the immediately preceding three financial years like turnover in India, global turnover, gross merchandise value in India, or global market capitalization.
• User thresholds in each of the immediately preceding 3 financial years in India like the core digital service provided by the enterprise has at least 1 crore end users, or it has at least 10,000 business users.
• The Commission may make the designation based on other factors such as the size and resources of an enterprise, number of business or end users, market structure and size, scale and scope of activities of an enterprise and any other relevant factor.

2. A period of 90 days is provided to notify the CCI of qualification as an SSDE. Additionally, the enterprise must also notify the Commission of other enterprises within the group that are directly or indirectly involved in the provision of Core Digital Services, as Associate Digital Enterprises (ADE) and the qualification shall be for 3 years.
3. It prescribes obligations for SSDEs and their ADEs upon designation. The enterprise must comply with certain obligations regarding Core Digital Services, and non-compliance with the same shall result in penalties. Enterprises must not directly or indirectly prevent or restrict business users or end users from raising any issue of non-compliance with the enterprise’s obligations under the Act. 
4. Avoidance of favouritism in product offerings by SSDE,  its related parties, or third parties for the manufacture and sale of products or provision of services over those offered by third-party business users on the Core Digital Service in any manner.
5. The Commission will be having the same powers as vested to a civil court under the Code of Civil Procedure, 1908 when trying a suit.
6. Penalty for non-compliance without reasonable cause may extend to Rs 1 lakh for each day during which such non-compliance occurs (max. of Rs 10 crore). It may extend to 3 years or with a fine, which may extend to Rs 25 crore or with both. The Commission may also pass an order imposing a penalty on an enterprise (not exceeding 1% of the global turnover) in case it provides incorrect, incomplete, misleading information or fails to provide information. 

Suggestions and Recommendations

• The ex-ante model of regulation needs to be examined for the Indian scenario and studies need to be conducted on it has worked previously in different jurisdictions like the EU. 
• The Bill should be aimed at prioritising the fostering of fair competition by preventing monopolistic practices in digital markets exclusively. A clear distinction from the already existing Competition Act, 2002 in its functioning needs to be created so that there is no overlap in the regulations and double jeopardy is not created for enterprises.
• Restrictions on tying and bundling and data usage have been shown to negatively impact MSMEs that rely significantly on big tech to reduce operational costs and enhance customer outreach.
• Clear definitions of "dominant position" and "anti-competitive behaviour" are essential for effective enforcement in terms of digital competition need to be defined. 
• Encouraging innovation while safeguarding consumer data privacy in consonance with the DPDP Act should be the aim. Promoting interoperability and transparency in algorithms can prevent discriminatory practices. 
• Regular reviews and stakeholder consultations will ensure the law adapts to rapidly evolving technologies. 
• Collaboration with global antitrust bodies which is aimed at enhancing cross-border regulatory coherence and effectiveness.

Conclusion

The need for a competition law that is focused exclusively on Digital Enterprises is the need of the hour and hence the Committee recommended enacting the Digital Competition Act to enable CCI to selectively regulate large digital enterprises. The proposed legislation should be restricted to regulate only those enterprises that have a significant presence and ability to influence the Indian digital market. The impact of the law needs to be restrictive to digital enterprises and it should not encroach upon matters not influenced by the digital arena. India's proposed Digital Competition Bill aims to promote competition and fairness in the digital market by addressing anti-competitive practices and dominant position abuses prevalent in the digital business space. The Ministry of Corporate Affairs has received 41-page public feedback on the draft which is expected to be tabled next year in front of the Parliament. 

References

1. https://www.medianama.com/wp-content/uploads/2024/03/DRAFT-DIGITAL-COMPETITION-BILL-2024.pdf
2. https://prsindia.org/files/policy/policy_committee_reports/Report_Summary-Digital_Competition_Law.pdf
3. https://economictimes.indiatimes.com/tech/startups/meity-meets-india-inc-to-hear-out-digital-competition-law-concerns/articleshow/111091837.cms?from=mdr
4. https://www.mca.gov.in/bin/dms/getdocument?mds=gzGtvSkE3zIVhAuBe2pbow%253D%253D&type=open
5. https://www.barandbench.com/law-firms/view-point/digital-competition-laws-beginning-of-a-new-era
6. https://www.linkedin.com/pulse/policy-explainer-digital-competition-bill-nimisha-srivastava-lhltc/
7. https://www.lexology.com/library/detail.aspx?g=5722a078-1839-4ece-aec9-49336ff53b6c

‍