# When an AI security scan becomes an exploit: US federal law

By Devekko · Published 2026-11-03

The CFAA asks about intent to access. It does not always ask about intent to damage.

A platform runs an AI agent to look for security flaws in the systems of its customers. The agent finds a flaw, uses it, and reaches production data. This guide explains how US federal law treats that event when nobody meant harm. It is for the people who run security, legal, and incident response at the platform.

**Limits of this guide.** This guide is research and not legal advice. It states the law as of November 3, 2026. We found no court or regulator decision on these exact facts, so each application to this scenario is our reading. Ask a US lawyer before you rely on it. The [US state guide](/services/cyber-compliance/articles/ai-security-scan-law-us-states) covers state law.

This guide uses three terms. The "operator" runs the platform and the scan. The "customer" is the tenant whose system the agent reaches. The "agent" is the AI system.

## See the rules and their time limits

The Computer Fraud and Abuse Act (CFAA) asks about intent to access. It does not always ask about intent to damage. We found no general federal breach law, so sector rules apply. Most of those clocks ignore motive, and the operator usually owes notice to its customer. Use this table to give each rule an owner.

| Rule | Who it binds | What starts it | Time limit | Record to prepare |
| --- | --- | --- | --- | --- |
| CFAA 18 U.S.C. 1030(a)(2) | Any person | Intentional access without authorization that obtains information | No notice clock. Civil action within 2 years | Customer consent that names the test |
| CFAA 1030(a)(5)(B) and (C) | Any person | Intentional access without authorization that causes damage, recklessly in (B) | No notice clock. Civil action within 2 years | Record of changes and service impact |
| HIPAA 45 CFR 164.410 | Business associate | Breach of unsecured protected health information | Without unreasonable delay, and no later than 60 days after discovery | Low-probability assessment |
| FTC Safeguards Rule 16 CFR 314.4 | FTC-regulated financial institution | Acquisition of unencrypted information on 500 or more consumers. Access is presumed to be acquisition | As soon as possible, and no later than 30 days after discovery, to the FTC | Customer notice contacts |
| OCC 12 CFR 53.4 | Bank service provider | A computer-security incident that materially disrupts or degrades covered services for 4 or more hours, or is reasonably likely to | As soon as possible | Prior test notices |
| SEC Regulation S-P 17 CFR 248.30 | Service provider, through customer oversight | Provider: breach that results in unauthorized access to a customer information system. Customer: unauthorized access to customer information | Provider 72 hours, and customer 30 days | Contract clause and notice text |
| SEC Form 8-K Item 1.05 | Public company | Material cybersecurity incident | 4 business days after the materiality decision | Materiality record |

## The CFAA separates intentional access from unintended damage

[18 U.S.C. 1030](https://www.law.cornell.edu/uscode/text/18/1030) is the main statute:

- **(a)(2)** covers one who "intentionally accesses a computer without authorization or exceeds authorized access", and thereby obtains information.
- **(a)(5)(A)** covers one who knowingly transmits code and "intentionally causes damage without authorization".
- **(a)(5)(B)** covers intentional access without authorization that "recklessly causes damage".
- **(a)(5)(C)** covers intentional access without authorization that "causes damage and loss".

Damage means "any impairment to the integrity or availability" of data or a system. Loss includes the cost of response, damage assessment, and restoration, so the USD 5,000 civil factor is easy to meet. Section 1030(g) gives a civil action, and on that factor it gives economic damages only.

[*United States v. Morris*](https://law.resource.org/pub/us/case/reporter/F2/928/928.F2d.504.90-1336.774.html) is the strongest authority against a no-malice defense. The court held that the intent standard "applies only to the 'accesses' phrase" and not to damage. The same opinion says that Congress wanted to reach intentional access, and not acts that were "mistaken, inadvertent, or careless". *Morris* read an older version of the statute, so read the current text too.

Authorization turns on access limits:

- [*Van Buren*](https://www.supremecourt.gov/opinions/20pdf/19-783_k53l.pdf) uses a "gates-up-or-down inquiry". Footnote 8 leaves open whether contracts or policies can set the gates.
- [*Power Ventures*](https://cdn.ca9.uscourts.gov/datastore/opinions/2016/12/09/13-17102.pdf) holds that explicit revocation matters. It also says that Power needed authorization from both the users and Facebook.

**Our reading.** Two fact patterns divide the analysis. If the operator aimed the agent at the customer's system, access looks intentional. Lack of intent to damage then does not help under (a)(5)(B) or (C). If the agent left its scope and reached a system that nobody chose, the *Morris* passage on inadvertent acts helps. The operator holds authority over infrastructure, but the customer controls its application and data. One permission may not replace the other.

## "The agent did it" is not a complete answer

The Ninth Circuit decided [*Amazon v. Perplexity*](https://cdn.ca9.uscourts.gov/datastore/opinions/2026/08/04/26-1444.pdf) on August 4, 2026. It calls an AI agent "a tool, not a person for statutory purposes". On that record, it held that "It is the user who 'accesses' Amazon's computers". A key fact was that the vendor did not directly communicate with Amazon's servers.

The decision has limits. It is a preliminary injunction ruling, and it binds only in the Ninth Circuit. The court reserved whether a company may exercise control over an agent to gain entry. It also said: "We do not establish a new legal regime governing agentic AI".

This decision helps an operator less than it helped the vendor in that case. In your scan, no outside user directed the agent, and the traffic likely comes from your own systems. You configure the agent and run it for your own purpose, so you are the likely actor. No court has held this.

Commentators agree that the intent question is open. [Alston & Bird](https://www.alston.com/en/insights/publications/2026/07/autonomous-hacking-rogue-ai-agent-planning) says that "there are no cases addressing CFAA criminal liability arising from autonomous hacking by AI agents". [Ballard Spahr](https://www.ballardspahr.com/insights/alerts-and-articles/2026/08/ai-gone-rogue-what-recent-openai-and-anthropic-ai-incidents-could-mean-for-cfaa-liability) says that prosecutors could argue "reckless disregard of a known risk". [Vanderbilt Law](https://law.vanderbilt.edu/when-ai-hacks-back-how-the-openai-hugging-face-incident-exposed-the-cfaa/) says that the stronger claim may be ordinary negligence.

## DOJ policy and CISA 2015 give limited protection

Justice Manual 9-48.000 covers access "solely for purposes of good-faith testing", done "in a manner designed to avoid any harm". [DOJ announced this policy in 2022](https://www.justice.gov/archives/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act). It is charging policy, and it may "not be relied upon to create a right or benefit". It does not mention AI, and it does not bind state prosecutors or civil plaintiffs. The words "solely" and "avoid any harm" fit poorly with a commercial product that uses exploits on production.

[Executive Order 14409](https://www.govinfo.gov/content/pkg/DCPD-202600376/html/DCPD-202600376.htm) tells the Attorney General to prioritize enforcement against anyone "who utilizes AI to illegally access or damage a computer without authorization". It does not widen the crime.

The Cybersecurity Information Sharing Act of 2015 can override other law, but it [expires on December 11, 2026](https://www.cybersecuritydive.com/news/cisa-2015-reauthorization-congress-ndaa-letter-businesses/873591/) unless Congress acts. "Notwithstanding any other provision of law", a private entity may monitor another entity's system "upon the authorization and written consent" of that entity ([6 U.S.C. 1503](https://www.law.cornell.edu/uscode/text/6/1503)). [Section 1505](https://www.law.cornell.edu/uscode/text/6/1505) bars suits for monitoring done in accordance with the law. "Monitor" means "to acquire, identify, or scan" ([6 U.S.C. 650](https://www.law.cornell.edu/uscode/text/6/650)). That fits a vulnerability scan, and an exploit that writes data does not fit it naturally.

The [Wiretap Act](https://www.law.cornell.edu/uscode/text/18/2511) and [Stored Communications Act](https://www.law.cornell.edu/uscode/text/18/2701) are narrower risks. An exploit that reads a database does not usually fit "intercept". A host may not be the entity that provides the tenant's messaging service, so the provider exception may not fit. Customer content sent to a model API raises a separate question under [section 2702](https://www.law.cornell.edu/uscode/text/18/2702).

## Sector notice rules depend on your customers

The operator usually owes notice to its customer, and the customer owes notice to the regulator. Check each rule in the table against your customer list.

- **HIPAA.** [45 CFR 164.402](https://www.law.cornell.edu/cfr/text/45/164.402) excludes an unintentional access "made in good faith and within the scope of authority". An exploit that the customer did not permit is likely outside scope. The practical route is the four-factor assessment of low probability of compromise, and it depends on logs and purge evidence. Under [164.410](https://www.law.cornell.edu/cfr/text/45/164.410), knowledge of an employee or agent can count as discovery.
- **FTC Safeguards Rule.** [16 CFR 314.2](https://www.law.cornell.edu/cfr/text/16/314.2) looks at acquisition "without the authorization of the individual", and it presumes that unauthorized access is acquisition unless reliable evidence shows otherwise. A contract right to scan may help on the CFAA and still leave a notification event.
- **Banks.** [12 CFR 53.4](https://www.law.cornell.edu/cfr/text/12/53.4) does not apply to scheduled testing that was previously communicated. An advance notice helps, but it may not cover an actual disruption that you did not plan.
- **SEC.** A public operator and a public customer make separate materiality decisions under [Form 8-K Item 1.05](https://www.sec.gov/files/form8-k.pdf). We found no exception in the item for a self-caused event.
- **FTC deception authority.** The [GoDaddy order](https://www.ftc.gov/news-events/news/press-releases/2025/05/ftc-finalizes-order-godaddy-over-data-security-failures) shows that the FTC acts on hosting security claims. Statements such as "we never access your data" or "safe, read-only scans" can become deception issues after an event.
- **CIRCIA.** The [incident report rule](https://www.cisa.gov/topics/cyber-threats-and-advisories/information-sharing/cyber-incident-reporting-critical-infrastructure-act-2022-circia) was not final in our sources. Check its current status.

## Prepare these records before the first scan

Three facts decide most outcomes: written consent that names the test, agent actions after first proof, and the time when staff learned of the access.

1. Get written customer consent that names exploit tests. A clause that permits a "scan" may not clearly permit an exploit.
2. Treat a customer opt-out as a revocation, and enforce it in the agent's target list.
3. Stop the agent after first proof, and block each write action unless a person approves it.
4. Keep network logs outside the agent, and record the time when each person learned of the access.
5. Tag customers by sector, so that you can find each notice duty quickly.
6. Review your public claims about scans and data access.

Consent does not bind end users, other tenants, or regulators. Ask your counsel to review the consent text and the public claims.

The [Cyber compliance articles](/services/cyber-compliance/articles) give the same analysis for the EU, the UK, Australia, and US states. Devekko's [Cyber compliance service](/services/cyber-compliance) covers the technical controls and records. It does not give legal advice.