{"slug": "what-ten-state-ai-bills-mean-for-security-research-when-it-s-assisted-by-a-model", "title": "What Ten State AI Bills Mean for Security Research When it's \"Assisted By a Foundation Model\"", "summary": "Ten state frontier-AI bills across seven states regulate developers of large foundation models, not security researchers, and none includes a safe harbor for good-faith, authorized security research that uses a frontier model, according to an analysis by Disclose.io. The bills, including Michigan HB 4668 and Illinois HB 3506, use language like 'conducted by or assisted by a foundation model' to define critical risks, which could chill security research by giving developers a legal rationale to deny ambiguous requests. Four measures are now law in California, Illinois, New York, and Connecticut, with thresholds like $500 million in annual revenue in New York and Massachusetts.", "body_md": "# What Ten State AI Bills Mean for Security Research When it's \"Assisted By a Foundation Model\"\n\nTen state frontier-AI bills regulate developers, not researchers, and none has a safe harbor for AI-assisted security research. Here is where the chilling effect comes from.\n\n\"A cyberattack conducted by or assisted by a foundation model.\"\n\nThat line is from [Michigan HB 4668](https://www.legislature.mi.gov/documents/2025-2026/billintroduced/House/pdf/2025-HIB-4668.pdf?ref=blog.disclose.io). It is one of the four kinds of incident the bill tells large AI developers to treat as a \"critical risk,\" and it tells the developer what to plan for, not the researcher what to do. Read it as a legislator and it is obviously about a model helping someone take down a power grid. Read it as a security researcher who uses a frontier model to triage a scan of a system they are authorized to test, and you notice that nothing in the sentence asks who authorized the access, or why.\n\nWe went through the current crop of state frontier-AI measures with that question in mind: ten bills across seven states (counting companion bills and chamber versions once), four of them now law in California, Illinois, New York and Connecticut, plus a Pennsylvania sponsorship memo with no text yet, plus the NIST draft guidance that describes what developers are likely to do about all of it. The short version first, then the parts that matter.\n\n## The short version\n\nNone of these measures regulates a security researcher. They regulate large developers of frontier models: publish a safety framework, assess catastrophic risks, mitigate them, report incidents, and in some states get audited. \"Large\" is a small club. New York and Massachusetts draw the line at $500 million in annual revenue, so the filters this post is about are set by a handful of providers who are also the chokepoint for everyone else. None of the bills creates a new offense for researchers, and none makes a researcher liable for anything. Equally, none contains a safe harbor for good-faith, authorized security research that happens to use a frontier model.\n\nThe risk to research is therefore indirect, and we want to label it as an inference rather than a statutory command. A developer facing a documented duty to mitigate \"cyberattack\" risk has one more reason to resolve an ambiguous, security-shaped request against the user, and most of these bills give it no reason to check for authorization first. The labs already refused offensive-cyber requests before any of this was drafted. The bills do not create the filter; they give it a legal rationale and a board-level audience.\n\n## Two drafting families, one of them worse\n\nMichigan HB 4668 and [Illinois HB 3506](https://www.ilga.gov/documents/legislation/104/HB/PDF/10400HB3506ham001.pdf?ref=blog.disclose.io) use \"conducted by or assisted by a foundation model.\" Any model assistance is in frame, and nothing in either bill distinguishes an attacker from a penetration tester with a signed scope when it describes the risk the developer must plan for. Michigan carves developing and \"evaluating the foundation model\" out of \"deploy,\" which protects a lab testing its own model and says nothing about a researcher using that model to test someone else's system. (HB 3506 has sat in the Illinois House Rules Committee [since April 2025](https://www.ilga.gov/Legislation/BillStatus?DocNum=3506&DocTypeID=HB&GAID=18&LegId=162191&SessionID=114&ref=blog.disclose.io); Illinois instead enacted the narrower SB 315, below.)\n\n[California SB 53](https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260SB53&ref=blog.disclose.io), [Illinois SB 315, now Public Act 104-0538](https://www.ilga.gov/documents/legislation/PublicActs/104/104-0538.htm?ref=blog.disclose.io), [New York's RAISE Act](https://www.nysenate.gov/legislation/bills/2025/S8828?ref=blog.disclose.io), [Connecticut Public Act 26-15](https://www.cga.ct.gov/2026/ACT/PA/PDF/2026PA-00015-R00SB-00005-PA.PDF?ref=blog.disclose.io) and the Senate version of the Massachusetts economic development bill ([S 3228](https://malegislature.gov/Bills/194/S3228.pdf?ref=blog.disclose.io), still in conference with [H 5576](https://malegislature.gov/Bills/194/H5576?ref=blog.disclose.io)) use a different formula, which we will call the California family: a frontier model \"engaging in conduct with no meaningful human oversight, intervention, or supervision that is either a cyberattack\" or something that would be murder, assault, extortion or theft if a human did it. That is better. A human-directed engagement is plainly outside it. It has its own hole, though: an agentic scanner running an authorized engagement has no meaningful human oversight in the moment, so autonomy on its own does not keep authorized testing out of the definition. Only the threshold does, and we come to that next.\n\nConnecticut gets one thing right that nobody else does. It defines \"cyberattack\" as access to a computer, system or network \"without authorization or in a manner that exceeds granted authorization\" that impairs the integrity or availability of data or a system. Authorization is inside the definition, so an authorized test is, by the statute's own terms, not a cyberattack. That is the model we would point drafters at. It is still a definition rather than a safe harbor: a definition keeps an authorized test out of the risk category the developer must plan for, while a safe harbor would tell the developer it may not treat that test as misuse. Connecticut has the first. Nobody has the second.\n\nTwo more for completeness. [New Jersey A 5275 / S 4446](https://pub.njleg.gov/Bills/2026/S4500/4446_I1.HTM?ref=blog.disclose.io) builds its catastrophic-harm definition around weapons, autonomous criminal conduct and control evasion, never names cyberattacks, and sets its threshold at 25 deaths. The [Pennsylvania memo](https://www.palegis.us/house/co-sponsorship/memo?memoID=49104&ref=blog.disclose.io) opens with an AI-enabled cyberattack and promises a safety framework, incident reporting, whistleblower protection and audits, and there is no bill text yet to read.\n\n## How a mass-casualty threshold reaches your API key\n\nThe obvious objection to all of this is the threshold. Michigan and Illinois HB 3506 require more than 100 deaths or serious injuries, or more than $1 billion in damage; the California family requires more than 50 deaths or serious injuries, or more than $1 billion. No authorized engagement comes within orders of magnitude of either. Read literally, the bills have nothing to say about ordinary vulnerability research, and that reading is correct.\n\nThe problem is that compliance does not operate at the threshold. It operates on the capability that could in theory reach it. The chain runs like this: the statute requires a written safety framework; the framework has to name offensive cyber capability as a tracked catastrophic risk, because the statute lists it; tracked risks get mitigations; and the mitigations are blunt, because the activity cannot be told apart from misuse at the point of use. Every link in that chain is in the statutes that name cyberattacks, or in NIST's own text. Only the last step, that state law tightens those mitigations beyond where they already sit, is inference.\n\nNIST said the blunt part out loud. [NIST AI 800-1, second public draft](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.800-1.ipd2.pdf?ref=blog.disclose.io) (January 2025, voluntary guidance, not law) spends Appendix E on cyber misuse. It notes that using a model \"to write software, draft emails, and even to actively probe systems may not be easily distinguished between beneficial activities like security research and threat actor misuse without additional context,\" which presents \"challenges for designing and implementing mitigations such as refusals, request filtering, and user account-level interventions.\" Its suggested mitigations are refusal training, request filters, user accounts with usage monitoring (which it admits \"may still face similar challenges in differentiating cyber misuse from legitimate use cases such as security research\"), and staged releases that give \"verified organizations and developers\" access to vulnerability-discovery capability before unverified users get it. The last two land on an independent researcher first, because an independent researcher is the unverified user with the security-shaped prompt.\n\nThe filter is already in place, and none of these bills put it there. When [Hugging Face](https://huggingface.co/blog/security-incident-july-2026?ref=blog.disclose.io) investigated the July intrusion that turned out to be OpenAI's own evaluation agent, its responders ended up running the forensic analysis on an open-weight model on their own infrastructure, because their first attempts through commercial frontier APIs \"were blocked by the providers' safety guardrails.\" That happened before most of these measures existed. What the bills add is a reason never to loosen it.\n\n## The verification tilt\n\nThere is a quieter pattern worth naming, as a trend in vocabulary rather than a mechanism. New York's RAISE Act [exempts accredited colleges and universities](https://nyassembly.gov/leg/?default_fld=&leg_video=&bn=S08828&term=2025&Text=Y&ref=blog.disclose.io) doing academic AI research from developer duties; independents get no equivalent. New York [S 10373](https://www.nysenate.gov/legislation/bills/2025/S10373?ref=blog.disclose.io) would require large developers to retain third-party verifiers with access to unredacted materials, state-accredited from 2029, and its sibling [S 10456](https://www.nysenate.gov/legislation/bills/2025/S10456?ref=blog.disclose.io) would let a regulator set minimum standards for developer frameworks. The Massachusetts Senate text requires an independent evaluation of each catastrophic-risk category at least every 120 days. None of these allocates model access to anyone; they are about verifying developer compliance. Put them next to NIST's \"verified organizations\" and the same word keeps turning up: institutional. The person who found your bug from a laptop in Adelaide does not have letterhead.\n\n## The qualifications, plainly\n\n- The thresholds are real. Ordinary vulnerability research is not a covered catastrophic risk anywhere in this set.\n- These are developer obligations. Any claim that the bills make researchers liable is wrong.\n- Several bills use \"good faith,\" for developer statements or for employee whistleblowing. None of those clauses reaches independent testing.\n- \"Evaluating the model\" is not security research. Every exclusion for making a model available to develop or evaluate that model covers the lab's own testing, and none covers using the model against a third party's system.\n- The chilling effect is an inference from developer liability plus NIST's mitigation menu. No statute orders a prompt filter.\n- NIST AI 800-1 and the AI Risk Management Framework are voluntary and create no legal protection either way.\n\n## The federal backstop is a charging policy\n\nResearchers sometimes assume federal law already covers this, and it covers less than it looks. The DOJ's [CFAA charging policy](https://www.justice.gov/jm/jm-9-48000-computer-fraud?ref=blog.disclose.io) says prosecutors \"should decline prosecution\" where the conduct was good-faith security research, and the same page says the policy is \"not intended to, do not, and may not be relied upon to create a right or benefit, substantive or procedural, enforceable at law.\" The DMCA rule at [37 C.F.R. 201.40(b)(18)](https://www.copyright.gov/title37/201/37cfr201-40.html?ref=blog.disclose.io) exempts good-faith security research from the anti-circumvention ban and says explicitly that it \"is not a safe harbor from, or defense to, liability under other applicable laws,\" the CFAA included. None of the state measures expands either protection to AI-enabled research.\n\n## What we would ask for\n\nThree things, none of which weakens what the bills are for.\n\nFirst, drafters should copy Connecticut's authorization element into the cyberattack definition. Access \"without authorization or in a manner that exceeds granted authorization\" is the line that separates an attacker from a tester, and it belongs in the definition rather than in a lab's discretion.\n\nSecond, one sentence in each bill: nothing in this act requires a frontier developer to restrict, refuse or monitor use of a model for good-faith security research on systems the user is authorized to test. A staffer will say the act already does not require that, and they are right. The sentence still changes behaviour, because it gives the developer's counsel a line to cite when the framework is audited and someone asks why security-shaped requests are allowed through. The clause would not indemnify the lab against third parties, and authorization for the underlying engagement stays the researcher's problem, exactly as it is today.\n\nThird, developers should publish a research-access policy, the same way disclose.io has spent years asking organizations to publish a disclosure policy. NIST's own Practice 6.4 already recommends a vulnerability disclosure policy plus a safe harbor for external safety researchers who act in good faith, and \"support and accommodations for vetted external researchers.\" Several labs run programs of that kind voluntarily today. The ask is to write down what \"vetted\" means so that someone without an institution behind them can qualify.\n\nWe will draft model language for the first two and add it to the [Policymaker](https://policymaker.disclose.io/?ref=blog.disclose.io) toolkit.\n\n## Where to push, and by when\n\nMost of these measures are still open somewhere, and the earlier in the process a definition gets fixed, the cheaper the fix. Dates are as of August 24, 2026.\n\n**September 28, 2026: comments on the DMCA security-research exemption renewal.** The Copyright Office's[tenth triennial rulemaking](https://www.copyright.gov/1201/2027/?ref=blog.disclose.io)is the only federal proceeding this year that directly decides the good-faith security research exemption at 201.40(b)(18). Petitions closed on August 24;[written comments on renewal petitions are due September 28](https://www.copyright.gov/newsnet/2026/1088.html?ref=blog.disclose.io), docket COLC-2026-0100 on regulations.gov. disclose.io will be on the record in that proceeding. If your research uses a frontier model, the record needs to say so, because the Register decides on the record and nothing else.**Michigan HB 4668: in the House Communications and Technology Committee.** The bill was[re-referred there on March 19, 2026](https://www.legislature.mi.gov/Bills/Bill?ObjectName=2025-HB-4668&ref=blog.disclose.io)after a discharge motion, so it is moving. Written testimony to the committee, or to the sponsor, Rep. Sarah Lightner, asking for Connecticut's authorization language in the \"critical risk\" definition is the single highest-value fix on this list.**Illinois HB 3506: in House Rules since April 2025, with a co-sponsor added in January 2026.** Not dead. The same authorization fix, addressed to Reps. Didech and Hanson, would bring the bill in line with the SB 315 the state already enacted.**Massachusetts H 5576 / S 3228: in conference since July 30, 2026.** The House and Senate named[conferees](https://malegislature.gov/Bills/194/H5576?ref=blog.disclose.io)(Michlewitz, Fiola and Soter for the House; Finegold, Rodrigues and Durant for the Senate). If the Senate's frontier-AI sections survive conference, this is the last point at which the cyberattack definition can be tightened.**New York S 10373 and S 10456: in the Senate Internet and Technology Committee.** Both are Sen. Gounardes' bills. S 10456 directs the regulator to consult \"academia, researchers\" when it writes minimum standards for developer frameworks; that consultation should include independent researchers, and the accreditation regime in S 10373 should not become the only door to model access. The 2025-2026 session closes at the end of this year.**Pennsylvania: a co-sponsorship memo, not yet a bill.** Reps. Shusterman and Scott[circulated the memo on August 13, 2026](https://www.palegis.us/house/co-sponsorship/memo?memoID=49104&ref=blog.disclose.io). A definition borrowed from Connecticut rather than Michigan costs nothing at this stage and a great deal later.**Congress: the FRONTIER Act, H.R. 9925.** Introduced July 23, 2026 and referred to Energy and Commerce and Science, Space and Technology, with no hearing scheduled. Its text says[no state \"may adopt or enforce\" a law imposing new substantive obligations on AI developers in a covered subject area](https://www.govinfo.gov/bulkdata/BILLS/119/2/hr/BILLS-119hr9925ih.xml?ref=blog.disclose.io), so it would decide whether any of the state definitions above survive. It contains no security-research provision either. Whatever the outcome on preemption, the authorization element belongs in the federal text too.**Already in force, watch the frameworks.** California SB 53 has applied since January 1, 2026, and its Section 22757.13 requires Cal OES to run a mechanism that \"a frontier developer or a member of the public\" can use to report a critical safety incident. Connecticut's frontier-developer sections take effect October 1, 2026; New York's RAISE Act and Illinois SB 315 on January 1, 2027. Each requires developers to publish a safety framework. When those frameworks appear, read the cyber section and check whether it says anything about authorized research. If it does not, that is the next thing to ask for, and it does not need a legislature.**NIST AI 800-1: no open window.** The second draft's comment period closed in March 2025 and there is no final version. When the next draft lands, Appendix E is the passage to comment on, and we will.\n\nIf you are a researcher who has already hit one of these filters on an authorized engagement, or a staffer working on one of these bills, we would like to hear from you at [hello@disclose.io](mailto:hello@disclose.io).", "url": "https://wpnews.pro/news/what-ten-state-ai-bills-mean-for-security-research-when-it-s-assisted-by-a-model", "canonical_source": "https://blog.disclose.io/state-ai-bills-security-research/", "published_at": "2026-08-24 21:29:54+00:00", "updated_at": "2026-08-24 21:45:39.587130+00:00", "lang": "en", "topics": ["ai-policy", "ai-safety", "ai-ethics"], "entities": ["Disclose.io", "Michigan HB 4668", "Illinois HB 3506", "California SB 53", "Illinois SB 315", "New York RAISE Act", "Connecticut Public Act 26-15", "NIST"], "alternates": {"html": "https://wpnews.pro/news/what-ten-state-ai-bills-mean-for-security-research-when-it-s-assisted-by-a-model", "markdown": "https://wpnews.pro/news/what-ten-state-ai-bills-mean-for-security-research-when-it-s-assisted-by-a-model.md", "text": "https://wpnews.pro/news/what-ten-state-ai-bills-mean-for-security-research-when-it-s-assisted-by-a-model.txt", "jsonld": "https://wpnews.pro/news/what-ten-state-ai-bills-mean-for-security-research-when-it-s-assisted-by-a-model.jsonld"}}