On April 15, 2026, the European Data Protection Board (EDPB) adopted guidelines on the processing of personal data for scientific research purposes.[1] The guidelines aim to clarify GDPR compliance requirements for scientific research involving personal data.

The concepts addressed by the EDPB are of particular relevance to companies active in life sciences, artificial intelligence (AI), and advanced technology R&D.

The guidelines are open for public consultation until June 25, 2026.

The most significant aspect of the guidelines is the EDPB’s clarification of what constitutes “genuine” scientific research. The guidelines set out six key-indicative factors to be considered alongside the nature, scope, context, and purposes of the processing. These factors appear to restrict the scope of processing that can be classified as scientific research, meaning that researchers may need to re-evaluate whether their activities genuinely qualify for the GDPR’s more flexible treatment of scientific research.

Six Factor Test to Define “Scientific Research” Under GDPR

The six key-indicative factors are as follows:[2]

1. Methodical and systematic approach: The research activities, including formulation and testing of a hypothesis, follow a methodical and systematic approach in the relevant field, for example in accordance with a comprehensive research plan.

• Adherence to ethical standards: The research activities adhere to ethical standards in the relevant field, including respect for human autonomy and consent, transparency, accountability, and (human) oversight.

• Verifiability and transparency: The research activities aim to achieve verifiable results, with hypotheses, methods, data and conclusions open to criticism (normally through peer review), and results shared with other parties, for example by publication.

• Autonomy and independence: The research activities are conducted autonomously and independently, with the research team having the freedom to define research questions, identify methods, choose scientific theories, and disseminate results. The researchers have academic or scientific qualifications in the relevant field.

• Objectives of the research: The research activities aim to contribute to the growth of society’s general knowledge and wellbeing. This does not exclude research that may also further commercial interests, but the EDPB does suggest in one of the examples included in the guidelines that research “solely concerned with furthering […] commercial interests” would not qualify.

• Potential to contribute to existing scientific knowledge or apply existing knowledge in novel ways: The research activities have the potential to contribute to existing scientific knowledge or apply existing knowledge in novel ways, and their scientific merits can be subject to assessment, review or approval by independent experts or committees.

If all six factors are met, the activities can be presumed to constitute scientific research. If not, the controller must justify and demonstrate why the activities should nonetheless qualify.

Anonymization and Pseudonymization in the Context of Scientific Research

The remainder of the guidelines address GDPR compliance more generally in the context of scientific research, including with respect to: data protection principles, lawfulness of processing, transparency, data subjects’ rights, attribution of responsibility, and appropriate safeguards.

While these sections largely restate existing principles (albeit with useful clarifications on “broad” and “dynamic” consent, including through specific examples on how organizations can navigate the tension with the principles of specificity and purpose limitation as part of their overall data protection governance structure), the EDPB’s views on data minimization merit highlighting.[3] The EDPB takes the view that, because personal data must be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed”[4], anonymization should be the default approach for scientific research. Once data is truly anonymized, it falls outside the scope of the GDPR entirely, although the anonymization process itself must still comply with GDPR requirements.[5] Where research aims cannot be achieved using anonymized data, personal data should be pseudonymized.[6] Processing data that can directly identify individuals should only occur where “strictly” necessary and proportionate to the research purpose.[7] Controllers will welcome the clarity provided by the guidelines, though ongoing compliance may require updates to internal processes. The full practical implications will become clearer once the dedicated guidance on anonymization and pseudonymization is published later this year.

Data subjects must be transparently informed about whether their data is processed in identifiable or pseudonymized form, and must not be misled into believing that their data is anonymized when it is not.[8]

Other Recent EDPB Updates

In addition to adopting these guidelines, the EDPB established a dedicated “sprint team” to finalize its upcoming and much anticipated guidelines on anonymization by summer 2026.[9] The questions of when personal data qualifies as “anonymous” under the GDPR and under what circumstances personal data (including sensitive personal data) can be used to train AI models, is currently also the subject of ongoing negotiations at EU level on the Digital Omnibus Package.[10]

Finally, the EDPB adopted two opinions approving two sets of Europrivacy certification criteria as a European Privacy Label, simplifying the data transfer process and enhancing accountability in high-risk sectors. The first approves an updated set of criteria whose scope now includes controllers and processors established outside Europe that are subject to Article 3(2) GDPR.[11] The second recognizes Europrivacy certification criteria as a European Data Protection Seal that can be used as a transfer mechanism under Articles 42 and 46 GDPR.[12] This will allow data importers outside Europe that are not subject to the GDPR to seek Europrivacy certification for transferred data they receive.

[1] EDPB Press Release, April 16, 2026, available here.

[2] EDPB Guidelines, section 2.1.

[3] EDPB Guidelines, section 8.3.

[4] GDPR Article 5(1)(c).

[5] EDPB Guidelines, para. 156.

[6] EDPB Guidelines, paras. 157-158.

[7] EDPB Guidelines, para. 159.

[8] EDPB Guidelines, para. 164.

[9] EDPB Press Release, April 16, 2026, available here.

[10] Cleary AI and Technology Insights, “Reset or rollback: Unpacking the EU’s Digital Omnibus Package”, November 21, 2025, available here.

[11] Opinion 14/2026 on the Europrivacy certification criteria regarding their approval by the Board as European Data Protection Seal pursuant to Article 42.5 GDP, adopted April 15, 2026, available here.

[12] Opinion 15/2026 on the Europrivacy certification criteria regarding their approval by the Board as European Data Protection Seal to be used as tool for transfers pursuant to Articles 42 and 46 GDPR, adopted April 15, 2026, available here.

As states continue to grapple with establishing regulatory frameworks for the most powerful artificial intelligence (“AI”) systems, New York has joined California in targeting frontier AI models with the Responsible AI Safety and Education Act (the “RAISE Act” or the “Act”).[1] Signed into law on December 19, 2025 by Governor Hochul, the Act creates a comprehensive regulatory framework for developers of the most advanced AI systems, marking New York’s entry into the vanguard of state AI safety regulation.

The final version of the Act[2] is narrower than the version of the Act enacted by the legislature in June, reflecting negotiations that more closely align the Act with California’s SB 53 (the “TFAIA”), which took effect January 1. However, while the Act shares California’s focus on transparency and safety, it diverges in critical ways, particularly regarding enforcement mechanisms and reporting timelines. Additional chapter amendments (expected to be finalized in early 2026) will further align New York with California by substituting a $500 million revenue threshold for compute-cost triggers and adjusting reporting timelines, penalties and oversight mechanisms. Below, we discuss the RAISE Act’s requirements at a high level, while also flagging key distinctions from the TFAIA, and anticipated revisions before the law takes effect on January 1, 2027.

 Applicability Thresholds and Scope

As enacted, the RAISE Act applies to (1) frontier models with a certain compute intensity and cost and (2) large developers with aggregate compute spend.

Specifically, the RAISE Act currently defines “frontier model” as an AI model trained using greater than 10^26 computational operations with a compute cost exceeding $100 million, or a model produced through “knowledge distillation”[3], and applies to “large developers” meaning persons that have trained at least one frontier model (the compute cost of which exceeds $5 million) and spent over $100 million in aggregate compute costs training frontier models.[4]

However, significant changes are expected that will bring the RAISE Act in line with applicability thresholds set forth under TFAIA. While California’s TFAIA is likewise limited to “frontier models” using computing power greater than 10^26 operations, the TFAIA distinguishes “large frontier developers” using a revenue threshold where developers (together with affiliates) with annual gross revenues above $500 million in the preceding year face heightened obligations. The California regime thus layers a compute-based model definition with a revenue-based developer trigger, creating a narrower class of entities subject to more stringent transparency and governance documentation.

Although the RAISE Act, as signed, uses compute-cost thresholds to define covered entities, public reporting suggests that Governor Hochul has secured legislative agreement to replace those provisions with a revenue-based trigger that mirrors California’s approach. Specifically, New York policymakers have publicly signaled an intent to align the “large developer” trigger with California’s $500 million revenue threshold to materially harmonize coverage with the TFAIA, simplifying compliance for companies operating in both jurisdictions. The revisions would have the effect of narrowing applicability given that many emerging AI developers (particularly those attracting substantial venture capital to fund compute-intensive model development) may quickly exceed compute-cost thresholds while generating little or no revenue, and that international competitors operating at lower revenue levels could otherwise face disproportionate regulatory burdens under a compute-only framework.

Key Operative Requirements

The RAISE Act imposes three core obligations on large developers:

1. Safety and Security Protocols. Before deploying a frontier model, developers must implement a written safety and security protocol similar in nature to the frontier AI framework required under the TFAIA. Specifically, the protocol must consist of documented technical and organizational protocols that (a) specify reasonable protections to reduce the risk of “critical harm”[5], (b) describe reasonable cybersecurity protections against unauthorized access to or misuse of frontier models that could lead to “critical harm” and (c) outline detailed testing procedures and assessment measures to evaluate unreasonable risk of “critical harm” (including how the frontier model could be misused or modified, how it could evade control of the large developer or user, etc.), (d) state compliance requirements with specificity to allow for confirmation of adoption and otherwise describe how the developer will comply with the Act and (e) designate senior personnel responsible for ensuring compliance. The protocol must be conspicuously posted (though the posted version may be appropriately redacted) and transmitted to the NY Attorney General and Division of Homeland Security and Emergency Services (with redactions only where required by federal law) upon request. Frontier model developers must further annually review and, where applicable, modify and republish the protocol to account for changes in model capabilities and industry best practices. Finally, developers are further required to implement appropriate safeguards to prevent unreasonable risk of “critical harm” and are prohibited from deploying a frontier model if doing so would create an unreasonable risk of “critical harm” (although this last requirement is anticipated to be removed in the chapter amendments).
2. Safety Incident Reporting. The most significant operational difference between New York and California’s regimes lies in incident reporting timelines. Under the RAISE Act, large developers must disclose reportable safety incidents[6] to the Division of Homeland Security and Emergency Services within 72 hours of learning of the incident or within 72 hours of learning facts sufficient to establish a reasonable belief that a safety incident has occurred. California’s TFAIA, by contrast, requires frontier developers to report “critical safety incidents” within 15 days of discovery, with a shortened 24-hour window only for incidents posing imminent risk of death or serious physical injury. New York’s uniform 72-hour requirement thus represents a middle ground (i.e., stricter than California’s standard timeline but more flexible than the 24-hour emergency threshold).
3. Recordkeeping. Large developers must record and retain (a) copies of its unredacted safety and security protocol, including records and dates of any updates or revisions and (b) information on specific tests and test results with sufficient detail for third parties to replicate the testing procedure, in each case, for as long as the frontier model is deployed plus 5 years.

In addition, the Act confirms that large developers violate the Act where they “knowingly make false or materially misleading statements or omissions in or regarding documents produced” under the Act and, unless removed by the chapter amendments, requires annual, independent third party compliance audits with detailed reporting that must also be conspicuously published and provided to regulatory authorities.

Enforcement

In addition to oversight by an AI office to be established within the New York Department of Financial Services, the RAISE Act grants the Attorney General authority to bring civil actions for violations of the Act. Following anticipated chapter amendments, penalties will be capped at $1 million for initial violations and $3 million for repeat offenses (substantially reduced from the $10 million and $30 million figures in the originally signed statute). The Attorney General may also pursue injunctive or declaratory relief. Critically, the Act does not establish a private right of action.

By comparison, California’s TFAIA authorizes the California Attorney General to seek civil penalties up to $1 million per violation, scaled to the severity of the offense, and also contains provisions that empower whistleblowers to bring civil actions for injunctive relief and recovery of attorneys’ fees for violations of their rights.[7]

Key Takeaways

Most businesses, including the vast majority of AI developers, will be relieved that the RAISE Act has narrow applicability. With thresholds targeting only frontier models and anticipated chapter amendments further narrowing coverage, the Act is unlikely to materially impact most organization’ operations. However, compliance remains a moving target, and thus businesses must stay abreast of legislative developments (particularly in light of the recently issued Executive Order aimed at state AI law preemption)[8].

For the few businesses that may meet the RAISE Act’s applicability thresholds, the alignment between New York and California’s frameworks offers a welcome development what is already slated to be an otherwise fragmented regulatory environment. Just as state privacy laws have created a challenging patchwork of requirements that businesses have learned to navigate, the harmonization of New York’s revenue threshold with California’s TFAIA represents a step toward more coherent multi-state compliance. However, where requirements diverge (such as New York’s stricter 72-hour incident reporting window compared to California’s 15-day standard) covered entities should draw upon the strategies and infrastructure developed through their privacy compliance programs. The same disciplined approach to documentation, risk assessment and incident response that businesses have refined while managing obligations under state privacy laws and the GDPR can be effectively adapted to address the RAISE Act’s nuanced requirements. 

To prepare for compliance:

• Prepare for Threshold Alignment: Businesses should (a) anticipate January amendments replacing New York’s compute-cost thresholds with California’s $500 million revenue standard and (b) conduct threshold analyses to determine whether it will qualify as a large frontier developer under the harmonized framework.
• Implement Dual-Compliant Safety Protocols: While awaiting confirmation of New York’s amendments, covered entities should develop safety and security protocols that satisfy both states’ requirements, combining New York’s emphasis on pre-deployment implementation with California’s focus on annual public disclosure and risk assessment reporting.
• Prioritize Incident Response Capabilities: New York’s 72-hour reporting window demands robust incident detection and response systems. Covered entities operating in both jurisdictions should build compliance infrastructure around the stricter New York timeline to ensure dual compliance, including by revising contracts where relevant to revise reporting timelines by third party vendors.
• Account for Enforcement Risk: With penalties up to $3 million for repeat violations, New York’s RAISE Act presents potentially higher financial exposure than California’s framework. Risk management strategies should reflect this disparity, with particular attention to documentation practices and compliance verification to avoid repeat violations.

[1] A copy of the RAISE Act can be accessed here.

[2] This article reflects the RAISE Act as it will be implemented following expected chapter amendments that Governor Hochul and legislative leaders committed to enacting in January 2026, including substituting a $500 million revenue threshold for the compute-cost triggers in the enacted text, reducing enforcement penalties and establishing a Department of Financial Services oversight office.

[3] Defined in the Act as “any supervised learning technique that uses a larger artificial intelligence model or the output of a larger artificial intelligence model to train a smaller artificial intelligence model with similar or equivalent capabilities as the larger artificial intelligence model.”

[4] Notably, the Act applies to frontier models “developed, deployed or operating in whole or in part in New York State”, and exempts accredited colleges and universities conducting academic research or persons that subsequently transfer full intellectual property rights in its frontier model to a third party.

[5] The Act defines “critical harm” to mean the death or serious injury of at least 100 people or at least $1 billion of damages to rights in money or property caused or materially enabled by a large developer’s use, storage, or release of a frontier model, through either of the following: (a) the creation or use of a chemical, biological, radiological, or nuclear weapon; or (b) an AI model engaging in conduct that does both of the following: (i) acts with no meaningful human intervention; and (ii) would, if committed by a human, constitute a crime specified in the penal law that requires intent, recklessness, or gross negligence, or the solicitation or aiding and abetting of such a crime.

[6] The Act defines “safety incident” broadly to include known incidences of critical harm, autonomous model behavior, theft or unauthorized access to model weights, critical failure of technical controls or unauthorized use of a frontier model.

[7] Notably, RAISE Act does expressly (a) prohibit large developers, or their contractors or subcontractors, from preventing an employee from disclosing or attempting to disclose information to the large developer or the NY Attorney General, if the employee has reasonable cause to believe that the large developer’s activities pose an unreasonable or substantial risk of “critical harm”, regardless of the employer’s compliance with applicable law and (b) permit an employee to seek injunctive relief for any harms caused by such retaliation.

[8] For our Firm’s detailed analysis of the Executive Order, see here.

For more insights and analysis from Cleary lawyers on policy and regulatory developments from a legal perspective, visit What to Expect From a Second Trump Administration.

On December 11, 2025, President Donald Trump signed an executive order titled Establishing A National Policy Framework For Artificial Intelligence (the “Order”)[1]. The Order’s policy objective is to “enhance the United States’ global AI dominance through a minimally burdensome national policy framework for AI”[2] and comes after Congress considered but did not advance federal legislation that would have preempted state AI regulation earlier this year. The Order justifies federal intervention on three grounds:

1. The growing number of different state regulatory frameworks has created a fragmented and inconsistent compliance landscape, particularly for small and medium sized businesses.
2. Some state laws require AI developers to incorporate “ideological bias” into their model outputs. For example, the Order alleges that Colorado’s ban on algorithmic discrimination could pressure AI models to produce inaccurate results in order to avoid differential treatment or impact on protected groups.
3. Certain state laws may go beyond their proper authority by regulating conduct outside their borders, raising concerns about interference with interstate commerce.

Below we summarize the key elements of the Order, followed by key takeaways for businesses to consider as they develop AI governance programs mapped to an ever-shifting regulatory framework.

Key Provisions of the Order

Building upon Executive Order 14179 of 23 January 2025 (Removing Barriers to American Leadership in Artificial Intelligence), which revoked the Biden Administration’s attempt to regulate the AI industry, the Order escalates federal efforts to prevent state-level AI regulation through forthcoming litigation, funding restrictions and agency preemption proceedings.

Specifically, the Order sets out a multi-pronged federal effort to challenge state AI laws and promote a single federal regime:

• AI Litigation Task Force: The Order directs the Attorney General to establish an AI Litigation Task Force within 30 days of the Order to challenge state AI laws that conflict with the spirit of the Order, such as laws that unconstitutionally regulate interstate commerce, are preempted by existing federal regulations or are otherwise unlawful (e.g., laws that compel disclosures by AI developers or deployers in violation of the First Amendment).

• State Law Evaluation: The Order requires the Secretary of Commerce to publish an evaluation of existing state AI laws, within 90 days of the Order, that identifies: (i) onerous laws conflicting with the Order’s main goals (e.g., laws that force AI systems to alter truthful outputs or compel disclosure in violation of the First Amendment), (ii) laws that should be referred to the AI Litigation Task Force, and (iii) laws that promote the development of AI consistent with the policy of the Order.

• Federal Funding Restrictions: Within 90 days of the Order, the Secretary of Commerce must issue a policy notice specifying the conditions under which States may be eligible for certain remaining federal funding. Specifically, states with onerous AI laws, as identified by the Secretary of Commerce, lose eligibility for certain non-deployment funds under the Broadband Equity Access and Deployment program to the maximum extent allowed by federal law. Executive agencies are also directed to consider conditioning discretionary grants on states not enacting conflicting AI laws or agreeing not to enforce existing ones during the funding period.

• Federal Preemption Standards: The Order also tasks key agencies with developing federal standards. Within 90 days of the Order, (i) the Federal Communications Commission is required to consider adopting a federal reporting and disclosure standard for AI models that preempts conflicting state laws and (ii) the Federal Trade Commission (“FTC”) is required to issue a policy statement on the application of the FTC Act’s prohibition on unfair and deceptive acts to AI models.  In particular, the Order directs the FTC guidance to explain the circumstances when state laws requiring “alterations to the truthful outputs of AI models” are preempted by the FTC Act’s prohibition on deceptive practices.

• Legislative Framework: The Order calls for the Special Advisor for AI and Crypto and the Assistant to the President for Science and Technology to prepare a legislative proposal to establish a uniform federal policy framework preempting conflicting state legislation (with limited carve-outs for child safety, AI compute and data center infrastructure, state government use of AI and other topics, as to be determined).

Key Takeaways

The Order marks the Trump Administration’s most substantial effort to date in shaping the federal approach to AI regulation, prioritizing industry flexibility over prescriptive requirements and potentially creating tension with state regulatory frameworks across various jurisdictions whilst leaving open questions about how AI safety, accountability and consumer protection will be addressed at the federal level.. With Congress deadlocked on comprehensive AI legislation and states determined to defend their regulatory authority, the resulting legal battles will likely determine the future of AI legislation in the United States for years to come. 

Given the ever-evolving legal landscape and in the absence of federal legislation, businesses should consider aligning their AI governance programs with industry standards, such as NIST’s AI Risk Management Framework and ISO 42001, which are likely to persist even as the regulatory environment continues to shift.  Businesses should also focus compliance efforts on ensuring transparency and truthfulness in their use and development of AI given the FTC’s recent focus on such principles as aligned with the Order’s directive.[3] Thoughtful AI governance aligned with NIST and ISO principles, coupled with transparent disclosures and documentation, will help businesses navigate the evolving AI compliance landscape.

[1] The text of the Order can be found here.

[2] See Section 2 of the Order.

[3] By directing the FTC to consider application of its deceptive practices prohibition to AI, the Order dovetails with the FTC’s recent enforcement efforts, which have largely focused on appropriate and sufficient disclosure of AI usage and businesses’ alleged misrepresentations of AI capabilities.

This article was authored by Daniel Ilan, Rahul Mukhi, Prudence Buckland, and Melissa Faragasso from Cleary Gottlieb, and Brian Lichter and Elijah Seymour from Stroz Friedberg, a LevelBlue company.

Recent disclosures by Anthropic and OpenAI highlight a pivotal shift in the cyber threat landscape: AI is no longer merely a tool that aids attackers, in some cases, it has become the attacker itself. Together, these incidents illustrate immediate implications for corporate governance, contracting and security programs as companies integrate AI with their business systems. Below, we explain how these attacks were orchestrated and what steps businesses should consider given the rising cyber risks associated with the adoption of AI.

Anthropic’s Disruption of an Autonomous, AI-Orchestrated Espionage Campaign

Just a few days ago, Anthropic’s “Threat Intelligence” team reported that it disrupted what it refers to as the “first documented case of a cyberattack largely executed without human intervention at scale”.[1] Specifically, in mid-September, Anthropic detected an attack that used agentic AI to autonomously target roughly 30 entities, including major technology corporations, financial institutions, chemical manufacturing companies and government agencies, and successfully execute end-to-end intrusions. The threat actor, determined with “high confidence” by Anthropic to be a Chinese state-sponsored group, manipulated Claude Code with structured prompts enabling AI to autonomously perform roughly 80–90% of the work across the attack lifecycle. That lifecycle included reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting, data analysis, and exfiltration operations, each occurring independently at rates that would be humanly impossible.

To achieve the attack, the group first selected targets and built an autonomous framework using Claude Code to conduct intrusions; the attackers then bypassed guardrails by “jailbreaking” the model with innocuous, role‑playing prompts[2] that concealed malicious intent. Accordingly, Claude rapidly mapped systems and high‑value databases, reported findings and then researched, wrote and executed exploit code to identify vulnerabilities, harvest credentials, escalate access and exfiltrate and categorize sensitive data while implanting backdoors. In the final phase, Claude generated comprehensive documentation (e.g., credential lists, system analyses and attack notes) to enable follow‑on operations with minimal human oversight. 

Three aspects of the attack stand out. First, while the attackers mostly used typical, off‑the‑shelf security tools, the attackers inventively stitched those tools together using standard interfaces like the Model Context Protocol (a common way for models and tools to interoperate) to perform actions that were previously in the sole domain of human operators. Second, the AI ran multi‑day campaigns, kept track of context, and generated organized reports—bringing the kind of scale and persistence typically reserved for well‑resourced human teams. Third, while the AI exhibited familiar model limitations (such as overstating findings and occasionally fabricating data during autonomous operations by claiming to have obtained credentials that did not work or identifying critical discoveries that proved to be publicly available information) these hallucinations did not preclude successful compromises, thus underscoring that hallucinations are a friction, not a barrier, to AI-enabled cyber attacks.

Anthropic responded by banning relevant accounts, improving detection tuned to AI‑driven attack patterns, building early‑warning tools, coordinating with industry and authorities and incorporating lessons learned into safeguards and policies. The bottom line: AI can now act as a largely independent intruder with relatively minimal human effort, and defenders should plan for adversaries using agentic capabilities at  scale.

OpenAI’s ShadowLeak: Vulnerability Could Lead to Zero-Click Indirect Prompt Injection and Service-Side Exfiltration

A separate proof of concept attack was first discovered by cybersecurity researchers at Radware, Ltd. (“Radware”), and later confirmed remediated by OpenAI.[3] “ShadowLeak” exposed a “zero‑click” indirect prompt injection path in ChatGPT’s Deep Research agent when connected to enterprise Gmail and browsing tools. To exploit this vulnerability in a social engineering attack, a threat actor would first embed hidden instructions inside normal‑looking emails; then, when the email user prompted the agent to summarize or analyze their inbox, the agent would, for example and unbeknownst to the user, ingest the hidden instructions and execute autonomous web requests directly from OpenAI’s cloud infrastructure, exfiltrating sensitive data, including personally identifiable information, to attacker‑controlled sites. Notably, this meant that in the case of a successful attack as demonstrated by Radware, once the Deep Research agent undertakes the actions as instructed by the prompt injected by the AI agent attacker (through the malicious email), sensitive data would be invisibly extracted without the victims ever viewing, opening or clicking the message.[4]

The governance significance is substantial. Because the data was exfiltrated from the impacted organization’s side, such organization’s own network never saw the exfiltration. This means that traditional controls (e.g., awareness training, link inspection, outbound filtering, and gateway data loss prevention) offered limited visibility or deterrence. Thus, the risk now centers on “what the agent does,” not just “what the model says,” and the threat extends beyond email to any AI agent connected to SaaS apps, CRMs, HR systems or other enterprise tools via protocols that standardize agent actions and inter-agent collaboration.

Recommended mitigations to prevent or detect such attacks may include treating agent assistants like privileged users with carefully separated permissions, sanitizing inbound HTML and simplifying inputs prior to model ingestion, instrumenting agent actions with audit‑quality logs and detecting natural‑language prompt attacks. From a contracting perspective, organizations should consider requiring that their vendors test their solutions for prompt injection, commit to input sanitization, gate autonomy based on maturity and risk and red‑team the full chain of agents and tools before broad rollout.

Strategic Implications for AI Adoption in the Enterprise

Taken together, these incidents transform what was once considered a distant, theoretical concern into present-day reality. Agentic AI can now largely independently execute complex offensive campaigns using standard tools at nation-state scale, and enterprise assistants, once granted access and operational autonomy, can trigger actions from the provider’s infrastructure that circumvent traditional enterprise controls. In practice, this means:

• Identity and authority for AI systems are fluid and spread across tools. An agent’s “scope” is not fixed; it changes based on connected tools, protocols and hidden instructions inside content.
• Controls focused on what the model writes are not enough. The priority is controlling and monitoring actions (i.e., calls to tools, APIs, browsers and other agents) with logs that capture who did what, when and why.
• Traditional training and perimeter defenses cannot fully address actions taken on the provider’s side. Organizations should negotiate provider‑side security commitments and build detection and response based on agent activity data, not just model outputs.
• AI mistakes (hallucinations or fabrication) may slow attackers or cause errors, but defenders should not rely on them as protection. The baseline capability  for AI‑driven offense is already high and increasing.
• Traditional defenses may be effective against AI-driven attacks, but the volume of attacks may increase. The incidents Anthropic discusses appear to be commoditized attacks that relied on commercially-available tools rather than novel tactics, techniques and procedures. Thus, traditional defenses should be successful against such attacks. Instead what is more interesting is the speed and volume of the attacks, which far exceeded what humans could do on their own, reinforcing the need for faster and AI-based defensive strategies that are able to respond at scale.

Key Takeaways for Integrating AI

When considering integrating AI into everyday workflows and products, and to meet obligations under applicable data protection, cybersecurity and digital regulations, entities should:

1. Treat AI assistants and agents like privileged system users. As noted above, organizations should consider separating “read‑only” from “action” permissions, using distinct service accounts and requiring auditable controls for tool use, browsing and API calls.
2. Contract for upstream safeguards. Require vendors to (a) sanitize inputs (including stripping risky HTML), (b) validate systems against prompt injection and natural language attack vectors (i.e., by implementing advanced controls such as judge LLM evaluation, spotlighting, and security-focused prompt-engineering patterns) and (c) provide action logs you can audit and use in incidents.
3. Build telemetry that captures agent behavior. Insist on provider‑side logs that record who did what, when and why for every agent action, and align those logs to your incident response and  reporting needs.
4. Update governance artifacts. Revise security questionnaires, data protection addendums and incident response plans to address provider‑side data leaks, risks from inter‑agent protocols and the move from output safety to action safety.
5. Prioritize secure AI development. Exercise due diligence when integrating components sourced from third parties, including free and open-source elements, to ensure they do not compromise the security of proprietary assets or operational environments. Verify security protocols and, where applicable, conformity with mandatory cybersecurity requirements (e.g., under the EU Cyber Resilience Act).
6. Consider interplay with mandatory cybersecurity rules. Stay abreast of evolving developments, particularly as cybersecurity is no longer a matter of best practice. Horizontal and sector-specific rules in the EU impose mandatory cybersecurity requirements on certain AI systems and products with digital elements (both hardware and software) available on the EU market and used to connect to a device or network. Cybersecurity and vulnerability handling measures should account for agentic AI attack surfaces and threats.

This article was republished by Law360.

[1] Anthropic’s full report on this incident can be accessed here: https://assets.anthropic.com/m/ec212e6566a0d47/original/Disrupting-the-first-reported-AI-orchestrated-cyber-espionage-campaign.pdf.

[2] Notably, in addition to breaking down the attacks into small, seemingly innocent tasks that Claude would execute without being provided the full context of their malicious purpose, the attackers also told Claude that it was an employee of a legitimate cybersecurity firm, and was being used in defensive testing. This role-play, according to Anthropic, was key to the success of the attack.

[3] See Radware’s description of the vulnerability here: https://www.radware.com/blog/threat-intelligence/shadowleak/.

[4] Importantly, , Radware disclosed the bug to OpenAI in June 18 through a vulnerability reporting platform. In August, OpenAI said the vulnerability was fixed and the company later marked it as resolved on September 3.

On September 29, 2025, Governor Gavin Newsom signed the Transparency in Frontier Artificial Intelligence Act (TFAIA, SB 53 or the Act)[1], establishing a comprehensive framework for transparency, safety and accountability in the development and deployment of the most advanced artificial intelligence models. Building upon existing California laws targeting AI such as AB 2013[2], the Act, which takes effect January 1, 2026 and imposes penalties up to $1 million per violation, creates immediate compliance obligations for AI developers of the most powerful frontier models.

The path to TFAIA was paved by failure. TFAIA’s predecessor SB 1047[3] overwhelmingly passed the legislature last year, but was ultimately blocked at the Governor’s desk. In his veto statement, Governor Newsom called for an approach to frontier model regulation “informed by an empirical trajectory analysis of AI systems and capabilities,” criticizing SB 1047 for applying stringent standards to even the most basic functions[4]. TFAIA thus represents a strategic pivot to regulation focused only on the most impactful AI models, which eliminates the kill switch requirement (which would mandate full shutdown capabilities for noncompliant systems), rigid testing and auditing regime and aggressive 72-hour timeline for incident reporting that doomed its predecessor.

TFAIA serves as California’s attempt to strike the balance of advancing AI innovation and competition while underscoring accountability for responsible AI development. The Act aims to bolster public trust and increase awareness of AI-specific risks by requiring developers to think critically about frontier AI capabilities.

Scope and Thresholds

Scoped narrowly to target the most powerful models capable of significant and catastrophic impact, TFAIA imposes certain requirements on “frontier models,” defined as foundation models (or general purpose models that are trained on broad data sets) trained using or intending to use a quantity of computing power greater than 10^26 integer or floating-point operations.[5]  In particular, all “frontier developers” (or persons that “trained or initiated the training” of frontier models) face baseline transparency requirements, with more burdensome obligations imposed on “large frontier developers” (namely, frontier developers that, together with affiliates, had annual gross revenues above $500 million in the preceding year).

Tailoring its scope even further, TFAIA focuses many of its requirements on prevention of “catastrophic risk”, defined as a foreseeable and material risk that a frontier model could (1) materially contribute to the death or serious injury of 50 or more people or (2) cause at least $1 billion in damages to property, in either case, arising from a single incident involving a frontier model, doing any of the following: (a) providing expert-level assistance in creating or releasing a chemical, biological, radiological, or nuclear weapon; (b) engaging in criminal conduct (conduct that would constitute murder, assault, extortion or theft) or a cyberattack, without meaningful human intervention; or (c) evading the control of its frontier developer or user.

Key Compliance Provisions

TFAIA imposes certain requirements on all frontier models, with heightened obligations on large frontier model developers:

1. Transparency Reports. At or before the time of deploying a frontier model (or a substantially modified version of an existing frontier model), frontier model developers must implement and publish a transparency report on their website. Reports, which can under the Act be embedded in model or system cards, must include (a) the website of the frontier developer, (b) model details (e.g., release date, languages supported, intended uses, modalities, restrictions) and (c) mechanisms by which a person can communicate with the frontier developer.[6]
   Large frontier developers must further (x) include summaries of assessments of catastrophic risks resulting from use of the frontier model, the results of such assessments, the role of any third-party evaluators and the steps taken to fulfill the requirements of the frontier AI framework (see below) and (y) transmit to the Office of Emergency Services reports of any assessments of catastrophic risk resulting from internal use of their frontier models every three months or pursuant to another reasonable schedule specified by the developer.  The Act tasks the Office of Emergency Services with establishing a mechanism by which large frontier developers can confidentially submit such assessment reports of catastrophic risk.
2. Critical Safety Incident Reporting. Frontier developers are required to report “critical safety incidents”[7] to the Office of Emergency Services within 15 days of discovery.  To the extent a critical safety incident poses imminent risk of death or serious physical injury, the reporting window is shortened to 24 hours, with disclosure required to an appropriate authority based on the nature of the incident and as required by law.  Note, critical safety incidents pertaining to foundation models that do not qualify as frontier models are not required to be reported.  Importantly, TFAIA exempts the following reports from disclosure under the California Public Records Act: reports regarding critical safety incidents, reports of assessments of catastrophic risk and covered employee reports made pursuant to the whistleblower protections described below. 
3. Frontier AI Frameworks for Large Frontier Developers. In addition to the above, large frontier developers must publish an annual (or, upon making a material modification to its framework, within 30 days of such modification) frontier AI framework describing the technical and organizational protocols relied upon to manage and assess how catastrophic risks are identified, mitigated, and governed. The framework must include documentation of a developer’s alignment with national/international standards, governance structures, thresholds used to identify and assess the frontier model’s capabilities to pose a catastrophic risk, mitigation processes (including independent review of potential for catastrophic risks and effectiveness of mitigation processes) and cybersecurity practices and processes for identifying and responding to critical safety incidents.  Large frontier developers are prohibited from making false or misleading claims about catastrophic risks from their frontier models or their compliance with their published frontier AI framework.  Additionally, these developers are permitted to redact information necessary to protect trade secrets, cybersecurity, public safety or national security or as required by law as long as they maintain records of unredacted versions for a period of at least five years.

Other Notable Provisions

In addition to the requirements imposed on frontier models, TFAIA resurrects CalCompute—a consortium tasked with development of a framework for the creation of a public cloud computing cluster first envisioned under SB 1047—which provides for access to advanced computing capabilities to support safe, equitable and sustainable AI development and deployment in the public interest. 

TFAIA also enhances protections for whistleblowers by (1) prohibiting frontier developers from adopting rules that would prevent employees from reporting catastrophic risks or retaliating against employees who report such risks, (2) requiring frontier developers to provide notice to their employees once a year of their rights as whistleblowers and (3) requiring large frontier developers to implement and maintain anonymous internal reporting channels. Notably, whistleblowers are empowered to bring civil actions for injunctive relief (as well as recovery of attorneys’ fees) against frontier developers for violations of their rights under the Act.

Enforcement and Rulemaking

Large frontier developers that fail to publish TFAIA-compliant reports or other documentation, make a false statement about catastrophic risk or their compliance with their frontier AI framework, fail to report a critical safety incident or fail to comply with their frontier AI framework could face penalties up to $1 million per violation, scaled to the severity of the offense. Such penalties can only be recovered by the Attorney General bringing a civil action. 

To ensure that the applicability of the TFAIA reflects technological change, the Act empowers the California Department of Technology—as opposed to the Attorney General as envisioned under SB 1047—to assess technological developments, research and international standards and recommend updates to key statutory definitions (of “frontier model,” “frontier developer” and “large frontier developer”) on or before January 1, 2027 and annually thereafter. 

Key Takeaways

With TFAIA, California provides a blueprint for regulations focused on the most impactful and powerful AI technology, establishing transparency, disclosure, and governance requirements for frontier model developers.  A similar bill, the Responsible AI Safety and Education (RAISE) Act, regulating frontier models awaits the signature of Governor Hochul in New York.  Although TFAIA and RAISE have similar applicability and frameworks,[8] RAISE imposes stricter requirements (72-hour window for reporting safety incidents) and higher penalties (up to $10 million for a first violation and $30 million for subsequent ones), similar to the failed SB 1047.  TFAIA’s success in navigating gubernatorial approval—where SB 1047 failed—demonstrates the effectiveness of a transparency-first approach over prescriptive mandates (as TFAIA largely focuses on disclosure requirements for covered models whereas RAISE does not require transparency reporting to the same extent nor include whistleblower protections, instead focusing on enforcement by imposing strict liability and strictly prohibiting models that create unreasonable risk of critical harms), suggesting the RAISE Act may be subject to further narrowing, or even a veto, by Governor Hochul. 

Most businesses, including the vast majority of AI developers, will be relieved that TFAIA has such narrow applicability.  For the few businesses that might meet TFAIA’s applicability thresholds, the law represents both immediate compliance obligations and a preview of the regulatory landscape to come. These businesses should:

1. Conduct a threshold analysis to determine frontier developer or large frontier developer status
2. Review existing AI safety practices against TFAIA requirements, particularly focusing on safety framework documentation and incident reporting capabilities
3. Develop comprehensive frontier AI frameworks addressing the law’s required elements, including governance structures, risk assessment thresholds and cybersecurity practices
4. Implement robust documentation systems to support transparency reporting requirements for model releases and modifications
5. Create incident response procedures to identify and report critical safety incidents within required timelines (15-day standard, 24-hour emergency)
6. Update whistleblower reporting mechanisms and ensure employees receive notice of their rights under the law
7. Develop scalable compliance frameworks accommodating varying state requirements as other states, including New York, consider similar AI safety laws
8. Consider voluntary adoption of TFAIA-style frameworks as industry best practices, even for companies below current thresholds

[1] The text of the Act can be found here.

[2] AB 2013 requires developers of generative AI systems to post documentation on their website describing the dataset(s) used for system training.

[3] The text of SB 1047 can be found here.

[4] https://www.gov.ca.gov/wp-content/uploads/2024/09/SB-1047-Veto-Message.pdf.

[5] The computing power minimum includes computing from both initial training and subsequent fine-tuning or modifications.

[6] Notably, frontier developers can redact portions of their transparency reports to protect trade secrets and guard against cybersecurity or public safety threats; however, any such redactions must be justified within the repot which must be maintained for 5 years.

[7] The Act defines a “critical safety incident” to mean any of the following: (1) unauthorized access to, modification of, or exfiltration of, the model weights of a frontier model that results in death or bodily injury; (2) harm resulting from the materialization of a catastrophic risk; (3) loss of control of a frontier model causing death or bodily injury; or (4) a frontier model that uses deceptive techniques against the frontier developer to subvert the controls or monitoring of its frontier developer outside the context of an evaluation designed to elicit this behavior and in a manner that demonstrates materially increased catastrophic risk.

[8] Unlike TFAIA, RAISE instead applies only to “large developers” defined as persons that  have (1) trained  at  least  one frontier model and (2) spent over $100 million in aggregate compute costs in training frontier models.

Last week, the New York Department of Financial Services (“DFS”) issued guidance addressed to executives and information security personnel of entities regulated by DFS to assist them in understanding and assessing cybersecurity risks associated with the use of artificial intelligence (“AI”), and implementing appropriate controls to mitigate such risks (the “Guidance”).[1] In particular, and to address inquiries received by DFS regarding AI’s impact on cyber risk, the Guidance is intended is to explain how the framework set forth in DFS’ Cybersecurity Regulation (23 NYCRR Part 500) should be used to assess and address such risks.

Below, we provide a high-level overview of the cyber risks identified by DFS related to the use of AI as well as the mitigating controls DFS recommends covered entities adopt to minimize the likelihood and impact of such risks.  Even for entities that are not regulated by DFS, the Guidance provides a roadmap for how other regulators may view AI-related cyber risks. 

Cybersecurity Risks Related to the Use of AI.  The Guidance identifies two categories of risks specific to cybersecurity posed by an organization’s deployment of AI:

• Risks caused by threat actors’ use of AI (e.g., AI-enabled social engineering and AI-enhanced cybersecurity attacks):

AI has enabled threat actors to create highly personalized and sophisticated social engineering attacks that are more convincing, and therefore more successful. In particular, threat actors are using AI to create audio, video and text “deepfakes” that target specific individuals, convincing employees to disclose sensitive information about themselves and their employers or share credentials enabling access to their organization’s information systems and nonpublic information. Deepfakes have also been used to mimic an individual’s appearance or voice to circumvent IT verification procedures as well as biometric verification technology.

AI has also allowed threat actors to amplify the “potency, scale, and speed of existing types of cyberattacks.” For example, AI can be used to more efficiently identify and exploit security vulnerabilities, allowing broader access to protected information and systems at a faster rate. It can also accelerate the development of new malware variants and enhance ransomware such that it can bypass defensive security controls, evading detection. Even threat actors who are not technically skilled may now be able to launch attacks using AI products and services, resulting in a potential increase in the number and severity of cyberattacks.

• Risks caused by a covered entity’s use or reliance upon AI.

Products that use AI require the collection and processing of substantial amounts of data, including non-public information (“NPI”). Covered entities that develop or deploy AI are at risk because threat actors have a greater incentive to target these entities to extract NPI for malicious purposes and/or financial gain. AI tools that require storage of biometric data, like facial and fingerprint recognition, pose a great risk as stolen biometric data can be used to generate deepfakes, imitate authorized users, bypass multi-factor authentication (“MFA”) and gain access to NPI.

Working with third party vendors in gathering data for AI-powered tools exposes organizations to additional vulnerabilities. For example, if a covered entities’ vendors or suppliers are compromised in a cybersecurity incident, its NPI could be exposed and become a gateway for broader attacks on its network.

Measures to Mitigate AI-related Threats

Using its Cybersecurity Regulation as a framework, DFS suggests a number of controls and measures to help entities combat the aforementioned AI-related cybersecurity risks. Such controls include:

• Designing cybersecurity risk assessments that account for AI-related risks in the use of AI by the covered entity and its vendors and suppliers;

• Applying robust access controls to combat deepfakes and other AI-enhanced social engineering attacks;[2]

• Maintaining defensive cybersecurity programs to protect against deepfakes and other AI threats;

• Implementing third party vendor and supplier policies and management procedures that include due diligence on threats facing such vendors and suppliers from the use of AI and how such threats, if exploited, could impact the covered entity;

• Enforcing data minimization policies to limit NPI a threat actor can access in case MFA fails; and

• Training AI development personnel on securing and defending AI systems as well as other personnel on drafting queries to avoid disclosing NPI.

Conclusion

As AI continues to evolve, so too will AI-related cybersecurity risks, meaning it is of critical importance that all companies are proactive in identifying, assessing and mitigating the risks applicable to its business. To ensure speedy detection of, and response to, such threats, and attempt to avoid regulatory scrutiny or enforcement, covered entities should review, and where necessary update, its existing cybersecurity policies and procedures and implement mitigating controls using the Cybersecurity Regulation as a framework in line with DFS’ Guidance.

[1] A copy of the DFS Guidance can be found here.

[2] Notably, DFS encourages entities to consider using authentication factors that can withstand AI-manipulated deepfakes, and other AI-enhanced attacks by avoiding authentication via SMS text, voice or video, and using forms of authentication that AI deepfakes cannot impersonate, such as digital-based certificates and physical security keys. Additionally, DFS recommends using technology with liveness detection or texture analysis, or requiring authentication via more than one biometric modality at the same time to protect against AI impersonation.