AI Cyber Risk: What Business Owners Should Review in Their Contracts
By Andrew Roy, business lawyer and founder of Roy Legal in Calgary, Alberta
AI is making it faster and cheaper for bad actors to find security weaknesses and work out how to exploit them. For business owners, that changes the risks involved in operating a website, handling customer information, and relying on technology suppliers. It should also change the contracts businesses are willing to sign. Liability limits, security commitments, indemnities, and exclusions of loss deserve closer attention when a weakness in someone else’s technology could expose your business to losses it cannot absorb. The October 2026 PHP and eMudhra security disclosures illustrate the problem. Both involve infrastructure that many businesses rely on without giving it much thought. Their consequences can extend far beyond the organizations responsible for the underlying technology. Why a supplier’s security problem can become your business problem A customer sees your business and your website. Behind that website may sit a hosting provider, a content management system, a programming language, digital certificates, and connections to databases and other services. Those dependencies can overlap. Two suppliers may appear independent while relying on the same underlying component. A weakness in that component can therefore affect several services at once. For an owner, the consequences are practical. An unavailable checkout can interrupt sales. A compromised customer database can require investigation and restoration. Staff may need to stop ordinary work to coordinate suppliers, answer customers, and manage the response. The contractual exposure can compound the operational problem. Your customer agreement may contain commitments about security, confidentiality, availability, and reimbursement. Your agreement with the supplier behind the service may offer much narrower protection. That difference deserves attention before an incident reveals how much risk the business has accepted. What the PHP and eMudhra disclosures mean for businesses PHP: a functioning website can still be compromised PHP is a programming language used beneath many websites and applications, including WordPress sites. On October 21, 2026, PHP released patches for critical vulnerabilities that could, under certain conditions, allow attackers to run code on affected servers. PHP Foundation’s announcement Researchers also demonstrated the ability to read sensitive information from server memory, including passwords, authentication tokens, and access keys. Those credentials can connect a website to databases and other business services, extending the potential exposure beyond the website itself. Wiz’s research A website might continue operating normally despite a compromise. An attacker able to execute code could potentially create a backdoor for later access. Applying an update would not necessarily remove that access, recover copied information, or make stolen credentials safe again. The UK’s National Cyber Security Centre specifically advised checking for evidence of compromise and attacker-installed backdoors where systems could not be updated or disabled promptly. NCSC guidance Older websites make this harder. A site may remain online after its developer has left or its maintenance arrangement has ended. Updating it may require repairs, testing, or migration. An available patch offers little practical protection if nobody is responsible for applying it. eMudhra: weaknesses in the systems that establish online trust Digital certificates help software establish that it is communicating with the intended website or service. Customers generally rely on that process without knowing which organizations provide the underlying assurance. The eMudhra disclosure concerned weak private keys associated with intermediate certificate authorities. The keys had been recoverable since April 2025, roughly eighteen months before public disclosure. Someone who recovered them could create certificates impersonating other institutions, including institutions that were not eMudhra customers. Researchers’ disclosure Against affected software, an attacker able to intercept or redirect a connection could potentially read or alter communications. Public certificate logs and checks enforced by major browsers provided protection against this particular attack, but other software did not necessarily have those protections. Whether attackers exploited that exposure before discovery remains unknown. Google’s advisory The broader business concern is trust. Online transactions depend on mechanisms customers cannot personally inspect, operated by organizations they may never have heard of. A weakness in one part of that system can expose businesses and customers that did nothing to cause it. How AI makes security weaknesses cheaper to exploit Bad actors can use AI to investigate weaknesses with substantially less time and effort than some of this work previously required. Reviewing code, testing possibilities, and troubleshooting unsuccessful attempts can become faster and cheaper. That changes which attacks are worth pursuing. A weakness that once looked too difficult or time-consuming to investigate may become an attractive opportunity. An attacker can explore more possibilities with the same resources, including older software, neglected websites, and obscure interactions between systems. AI can help with both finding a weakness and turning it into a usable attack. It can examine code, suggest where information might be exposed, generate tests, and help work through failed attempts. The PHP research demonstrates that capability. Researchers combined human expertise with AI to develop and adapt working exploits through repeated testing and debugging. Their findings show how AI can reduce the practical barriers to exploiting longstanding weaknesses. Wiz’s research Businesses still need people to investigate exposure, coordinate suppliers, test updates, and deploy fixes. That work takes time even as the cost of finding and exploiting a problem falls. Your technology may remain unchanged while the economics of attacking it become considerably more attractive. How business contracts should respond to changing cyber risk Keep liability caps meaningful A liability cap sets a contractual limit on the amount a party may owe for covered claims. Its usefulness depends on what falls within it. Businesses should be more cautious about accepting broad exceptions that leave confidentiality breaches, data breaches, or security indemnities outside the cap. Those exceptions can remove protection against precisely the losses that could threaten the business. Where greater exposure is justified, a higher but finite limit for defined security claims may be more appropriate than unlimited liability. The wording should explain how that limit interacts with the general cap and whether related claims share one aggregate limit. An owner should understand the maximum exposure the agreement is intended to create and the claims that remain outside it. Identify the losses being excluded or accepted Businesses should not assume that excluding “consequential loss” automatically excludes every claim for lost profits. Contractual wording and context matter. In Atos IT Solutions v. Sapient Canada Inc., the Ontario Court of Appeal upheld an interpretation under which the particular exclusion did not prevent recovery of profits lost on the subcontract itself. Atos, paragraphs 68–72 and 82–8. Where the intention is to exclude lost revenue, business interruption, or other particular losses, address those categories expressly. Investigation, data restoration, customer notification, and replacement services also need deliberate treatment. Decide which costs are recoverable, what triggers payment, and which limit applies. Customers need meaningful remedies, while suppliers need exposure they can realistically bear. Make indemnities fit the liability framework An indemnity can require one party to cover specified losses in defined circumstances. Its scope needs to work with the liability cap and exclusions. A carefully negotiated limit may offer little protection if a separate reimbursement provision requires payment of the same losses without those restrictions. The agreement should identify the events triggering payment, the losses covered, and the applicable limits. The customer’s own response costs and claims brought against it by other people also deserve separate consideration. Defence costs and control over settlements should be addressed where relevant. Make security promises the business can deliver An absolute promise that a system contains no vulnerabilities deserves considerable caution. Defined obligations to maintain controls, monitor dependencies, and respond to newly discovered weaknesses provide a more practical basis for accountability. Contracts should allocate responsibility for vulnerability notices, emergency patching, certificate replacement, customer cooperation, and temporary suspension. They should also address resulting costs and the options available if a serious problem continues. For critical services, consider a process for reviewing material changes in the threat, the controls required, and any resulting changes in cost or scope. The process can respond to the vulnerability and its impact without requiring proof that an attacker used AI. Who should approve cyber risk within the business? Significant cyber commitments should receive input from the people responsible for legal terms, technology, and finances. In a smaller business, that may mean the owner, external counsel, and the IT provider. Departures from standard liability limits should require documented approval at an appropriate senior level, with board involvement where the exposure warrants it. The decision should account for potential losses, available insurance, operational controls, and the business’s ability to absorb the remaining exposure. Critical systems also need accountable owners, funded maintenance, and a process for escalating unresolved vulnerabilities. This approach is consistent with the Canadian Cyber Centre’s guidance on assigning security responsibilities, approving risk, and reviewing controls as circumstances change. Canadian Cyber Centre guidance When walking away is the better business decision Winning a contract is valuable only if the return justifies the obligations accepted. Narrowing the service, improving controls, or negotiating different terms may bring the exposure within an acceptable range. Where those options are insufficient, declining the deal may be the better commercial decision. That assessment should include the business’s wider commitments. One underlying weakness could create exposure under several customer agreements. An owner needs to understand the combined risk, rather than reviewing each contract as though it exists alone. AI is changing how easily overlooked weaknesses can become practical threats. Business owners should revisit their dependencies, contractual promises, and liability limits before an incident tests them. Roy Legal helps business owners review commercial agreements and assess whether the risks they are accepting make sense for the business.
This article provides general information only and is not legal advice. Reading or relying on it does not create a solicitor-client relationship with Andrew Roy or Roy Legal. Laws and their interpretation may change, and their application depends on the circumstances. Obtain legal advice about your specific situation before acting on this information. © 2026 Andrew Roy. All rights reserved.

