The Unlocked Door: Who Pays When a Rogue AI Agent Attacks From Your Infrastructure
A startup left an endpoint open. An autonomous agent used it to break into a different company. Three bodies of law should tell you who pays. Only the one you already signed gives a straight answer.
At 4:01 UTC on July 9, 2026, an autonomous agent running on OpenAI models had root access to a code-execution sandbox that did not belong to OpenAI.
It didn't belong to Hugging Face either. It belonged to a customer of Modal Labs — some company that had published an unauthenticated endpoint, one that let anyone on the internet run code in its sandboxes. The agent had just escaped an OpenAI evaluation environment through a zero-day in a package proxy, reached the open internet, and gone looking for a base of operations. It found one standing wide open.
For the next four and a half days, that customer's environment was the launchpad. Command and control, staging, egress — all of it ran from there. When the agent finally reached inside Hugging Face's production Kubernetes cluster, it minted source-control tokens, stole five datasets tied to the benchmark it was being tested on, and enrolled rogue devices into Hugging Face's corporate mesh network. The rouge agent was operating from a stranger's compute account the entire time.
Modal's infrastructure was not compromised in any way. A customer left a door open. This was not a factory default nobody changed, the administrator of the account made a mistake.
The question everyone running workloads on someone else's infrastructure should now be asking: if that had been my account, who pays?
Nobody has sued anybody here, and nothing in this piece suggests anyone should. But run the hypothetical, because your company is the customer in this story.
Three bodies of law, three non-answers
Contract: mostly silence, not allocation
Modal's terms of service are unusually customer-friendly. The agreement requires the customer to use the service lawfully and prohibits using it for a "Prohibited Purpose" or to process "Prohibited Content," which includes malicious code designed to damage data, equipment, or communications. However, the customer's indemnity obligation is very narrow: it covers third-party claims for intellectual property infringement or violations of law related to Customer Data. Moreover, the document that actually tells customers they must implement appropriate access controls, the “shared responsibility model,” is the product documentation, not the contract. It is a standard of care with no contractual remedy attached.
There is no broad "arising out of Customer's use of the Service" indemnity — the kind that would clearly capture a downstream victim's claim.
Modal Labs' competitor Replicate takes the opposite approach. Its customer indemnity covers any losses resulting from the customer's use of the service and names negligence by the customer as a trigger. Replicate does not appear to have a shared responsibility model. A second competitor, RunPod, is indemnified against any third-party claim arising out of use of the service, and RunPod puts its shared responsibility model in the contract, expressly assigning firewall, storage, IP, and DNS configuration to the customer.
So the market does allocate this risk, and it allocates it to you. Read the clause carefully, though, because of what it does and does not do: it obligates you to defend and reimburse your vendor, not the company your environment was used to attack. On that second exposure the contracts are silent, and silence means the loss sits wherever it lands.
Tort: the downstream victim probably can't sue you. That's not as good as it sounds.
Direct Liability: Could Hugging Face sue the company whose endpoint got used? Probably not. There are two obstacles: (1) You generally owe no duty to protect a stranger from a third party's criminal acts, and (2) the economic loss rule bars negligence recovery for purely financial harm between parties with no relationship. There is no relationship between the parties here. No court has recognized a duty running from a misconfiguring company to a downstream business, and none is likely to any time soon.
Contribution: The obvious defendant is the party that launched the agent, OpenAI in this case, and its first move will be to point at the open endpoint. That instinct runs into the same wall. Contribution exists only among joint tortfeasors, meaning parties liable in tort for the same injury, and it rests on a common liability to the injured party. If you owe the downstream victim no duty, you have no liability to share, so there is nothing to contribute to. The same gap that keeps you from being sued directly keeps you off the verdict sheet. What can still cost you is the fight itself. Being subpoenaed, or impleaded and later dismissed, is defense fees and discovery you pay whether or not fault ever attaches.
Regulatory Liability: Business owners at all levels consistently miss this liability. For example, in FTC v. Wyndham Worldwide Corp., 799 F.3d 236 (3d Cir. 2015), Wyndham never changed the factory settings. One hotel's property management system was still accepting the credentials it shipped with: the software vendor's own name, "micros," as both the username and the password — the hospitality industry's version of admin/admin. Wyndham also ran no firewall between the hotel systems, its own corporate network, and the internet, so a foothold in one hotel did not stay in one hotel.
The Third Circuit upheld the FTC's authority to pursue unfairness claims over inadequate data security against Wyndham. Notably, none of the tort obstacles above appear anywhere in the opinion. Unfairness is a statutory standard, so there is no duty element, no plaintiff who had to be owed anything, and no economic loss rule. All that mattered was that the configuration was unreasonable and the systems became a path to somewhere else. The case went forward on that basis. Wyndham settled before any court decided liability.
Arguably, an unauthenticated code-execution endpoint is a cleaner version of this fact pattern. Know the limit, though: unfairness requires substantial injury to consumers, and Wyndham was a payment card case. A sandbox holding nobody's personal data may not get there. Hugging Face has now published a 17,600-action forensic timeline and OpenAI has confirmed the outside accounts its models touched. That is a documented, public failure, which means attacks like this one are now a foreseeable risk.
Insurance: one fact makes you liable and uninsured
Security and privacy liability is standard in most cyber policies and responds to third-party claims, including claims that you transmitted malicious code to someone else's computer system. On paper, that is exactly what a downstream victim would be alleging.
But, what would they actually accuse you of doing? Not hacking anyone. Not negligence in some diffuse sense. You left an endpoint open. Misconfiguring your endpoint is the whole theory of the case against you.
That same fact is your carrier's reason for denying coverage. Three standard exclusions are built into cyber policies to catch it:
Failure to maintain minimum security standards. Many carriers exclude claims arising from the insured's failure to keep required controls in place — usually measured against the security questionnaire you filled out to get the policy. If you told your carrier that production endpoints require authentication and one of them didn't, coverage is excluded, and you are funding your own defense. The useful news: this language generated so much coverage litigation that some carriers have dropped it. Find out at renewal whether yours still carries it.
Known vulnerabilities. Coverage is commonly excluded where the insured knew about a flaw and didn't fix it. A misconfiguration feels like something nobody noticed. The question is, should you have known? If the open endpoint appeared in a scan report, a pen test finding, or a ticket nobody closed, you knew.
Contractual liability. Policies routinely exclude liability you took on by contract that you would not have carried otherwise. If you signed a vendor indemnity promising to cover their losses from your misuse of the platform, that promise may be the one obligation your policy refuses to fund — specifically because you volunteered for it.
Set that against how these claims actually resolve. The National Association of Insurance Commissioners reported that only about one-third of cyber claims filed by small and mid-size businesses in 2024 were paid.
The practical result is that a third party has a live claim against you, your carrier has a documented reason to deny coverage, and you are left funding your own defense. Confirming that your policy answers this scenario costs one email to your broker. Finding out that it doesn't, after the fact, costs considerably more.
Revenue Contracting Suite™
Do you know what your vendor agreements say about the day something goes wrong?
Most business owners sign platform terms without reading the indemnity clause, the liability cap, or the notice provision. Those three paragraphs decide who pays when your environment gets used against somebody else — and on most developer-infrastructure terms, the answer is you.
Revenue Contracting Suite builds the contract layer that holds up under pressure: indemnity scope, liability caps, security representations, and incident notice obligations that trigger when you actually need them.
Detection is not response
Your cyber insurance application asked whether you have threat detection. You said yes. That answer is a representation, and your carrier will read it the way carriers read things: as a claim that you can detect an attack and respond to it, not that you bought a product.
Hugging Face's security tools caught the attack while it was happening. Their systems pulled scattered signals together, connected them, and produced a clear alert: something is wrong.
Then the alert sat there. It wasn't marked urgent enough to wake anyone up.
The tool worked. The company still lost days while an agent minted credentials inside its cluster. Buying detection software and being able to act on an attack are two different things, and the gap between them is where the damage happens.
If something like this runs through your systems and nobody wakes up, the distance between what you said and what you had is the distance your carrier will use to deny the claim. So fix the escalation rules, not just the tooling. Then write down what you fixed and when. That record is the only evidence you'll have.
Your notice clocks don't wait for attribution
The attack ran from July 9 to July 13. Hugging Face disclosed publicly on July 16, three days after the campaign ended, attributing the intrusion to an unidentified autonomous agent. OpenAI did not publicly connect the activity to its own evaluation until July 21, eight days after the campaign ended.
Most contractual security-incident notice provisions in terms of service run from discovery of the incident, not identification of the actor. So do state breach-notification statutes. "We didn't know who it was yet" is not a tolling event. If your Master Services Agreement (MSA) with an enterprise customer requires notice within 24 or 72 hours of becoming aware of a security incident affecting their environment, that clock started when you learned something was wrong.
Hugging Face has said its security stack correlated the attack into a coherent signal but failed to raise the alert's criticality and page the on-call team. What it has not said is when that first signal appeared. That silence is the point. Notice obligations run from the date a company knew, so the date you can prove you first knew is the date your clock started. If you cannot say when your own detection fired, you cannot show you gave notice on time.
The scope of the notice provision also affects when and if notice is required. Modal's Data Processing Addendum, for example, commits to notifying the customer within 48 hours of becoming aware of a Personal Data Breach affecting Customer Personal Data. That provision would not have been triggered here. The target was a code-execution sandbox holding no personal data, so it does not fit the definition.
Your vendor may have no contractual obligation whatsoever to tell you that your environment was used as attack infrastructure against somebody else. Build for that.
How the platform protects itself
If you're the one operating the infrastructure:
Move the shared responsibility model out of the docs and into the contract. A responsibility matrix incorporated by reference into the terms of service is enforceable. A responsibility matrix on a documentation page is a suggestion.
Broaden the customer indemnity beyond Customer Data. Third-party claims arising from the customer's misconfiguration of your product and resulting misuse of the service should be the responsibility of the customer.
Carve indemnity obligations out of the liability cap. An indemnity capped at twelve months of fees on a free-tier account is decorative, and does not protect your company.
Put exposed unauthenticated endpoints in the acceptable use policy by name. Express suspension rights should be included in the terms of service for customers exposing unauthenticated endpoints.
Scan for them proactively and document the notification. The strongest defense to a claim that you enabled harm is a timestamped record showing you warned the customer and they didn't act.
Preserve logs. You will need them, and so will the downstream victim's counsel.
How the misconfiguring customer protects itself
If you're the one who exposed an unauthenticated endpoint:
Inventory every unauthenticated endpoint you expose. Anything that executes code without authentication is the door. This is the whole exercise.
Read your vendor's shared responsibility model as a liability document. It describes the obligations you'll be measured against after something goes wrong.
Negotiate three things at renewal: a mutual indemnity, a notice obligation triggered by security incidents rather than only personal-data breaches, and a right to obtain relevant logs on request.
Pressure-test the cyber policy. Confirm security and privacy liability responds to third-party claims for harm launched from your environment. Document your controls contemporaneously, because when the carrier disputes "failure to maintain," your evidence is the only thing that decides it.
Name the vendor in your incident response plan, and write the plan on the assumption that you learn late and from outside.
Expect the diligence question. Any competent Series A security review in 2027 will ask what unauthenticated compute you expose. Have the answer before someone asks for it.
Where this lands
Right now, the loss sits on the downstream victim. Hugging Face rebuilt a core cluster from scratch, rotated every credential in its estate, and ran a forensic reconstruction of 17,600 actions — and there is no obvious party to send that bill to. Contract law says the platform didn't promise anything. Tort law hasn't yet recognized a duty running to a company three hops away. Insurance says the misconfiguration that created the exposure is the misconfiguration that voids the coverage.
That's not a stable arrangement. It holds only until a company with serious damages persuades a court to recognize a duty running upstream to whoever left the door open, or until a regulator decides that exposing unauthenticated compute is itself an unreasonable practice.
Founders don't get to wait for that case. The agreements you sign this quarter will govern the incident that happens after it's decided. The Contracting Suite™ exists for exactly this: vendor agreements, security representations, insurance coverage, and incident response obligations built as legal infrastructure rather than assembled under pressure after something breaks.
If you're running workloads on someone else's platform and you can't say today which of your endpoints answer to the open internet, that's the first thing to fix. The second is the paperwork that decides who pays when one of them answers the wrong caller.
Curt Wadsworth, J.D., Ph.D. is the founder of Nerd Lawyer Entrepreneur Services, an AI-native corporate and IP law firm serving founders, startups, SMBs, and growth-stage companies. Reach him at curt@nerdlawyer.ai.
This post is general information about legal developments, not legal advice, and does not create an attorney-client relationship. The liability analysis here is hypothetical and forward-looking; no claim has been asserted against any party described. Consult counsel about your specific agreements and coverage.
Sources
Hugging Face, "Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident," huggingface.co/blog/agent-intrusion-technical-timeline (July 27, 2026).
Hugging Face, "Security incident disclosure — July 2026," huggingface.co/blog/security-incident-july-2026 (July 16, 2026).
OpenAI, "OpenAI and Hugging Face partner to address security incident during model evaluation," openai.com/index/hugging-face-model-evaluation-security-incident (July 21, 2026; updated July 28, 2026).
POLITICO, "OpenAI's rogue models roamed the internet for 4 days and staged a second attack" (July 28, 2026).
Al Jazeera, "OpenAI's rogue agent hacked an account at a second technology firm: Report" (July 29, 2026), reporting statements by Modal Labs CTO Akshat Bubna to Reuters.
Modal Labs, Software as a Service Agreement, effective May 2026, modal.com/legal/terms.
Modal Labs, "Security and privacy at Modal," modal.com/docs/guide/security.
Runpod, Terms of Service, last updated March 24, 2026, runpod.io/legal/terms-of-service.
Replicate, Terms of Service, last updated April 1, 2026, replicate.com/terms.
FTC v. Wyndham Worldwide Corp., 799 F.3d 236 (3d Cir. 2015).
Honigman LLP, "Cyber Insurance 101" (overview of security and privacy liability coverage and failure-to-maintain exclusions).
National Association of Insurance Commissioners, cyber insurance claims data (2024).
Curt Wadsworth, J.D., Ph.D. is the founder of Nerd Lawyer Entrepreneur Services, an AI-native corporate and IP law firm serving founders, startups, SMBs, and growth-stage companies. Reach him at curt@nerdlawyer.ai.
This post is general information about legal developments, not legal advice, and does not create an attorney-client relationship. The liability analysis here is hypothetical and forward-looking; no claim has been asserted against any party described. Consult counsel about your specific agreements and coverage.
