Suppose a client hires your agency to build an application. You use Cursor, Bolt or Lovable because the tools let you deliver in two weeks instead of two months. The product works, the client signs off, and the project closes.
Six months later, the database is compromised.
At that point, the client isn't going to call the AI tool vendor. The client hired you, and your contract and professional obligations will shape what happens next.
That's the liability question agencies need to address before delivery rather than after an incident.
Where responsibility usually lands
When a developer writes code by hand, the authorship and responsibility are clear. The developer wrote it, the developer is accountable for it, and professional liability follows established patterns.
When AI writes the code, the picture gets murkier. The developer prompted the tool, chose which output to accept, and delivered it to the client. The AI tool generated the actual code, including the vulnerability. The tool provider's terms of service almost certainly disclaim any liability for the output.
In practice, the liability lands on whoever delivered the product to the client. That's you. The client doesn't have a relationship with Cursor or Bolt. They have a relationship with you. Your contract (if you have one) governs who bears the risk. And if your contract doesn't explicitly address AI-generated code, security standards, or liability caps, you're operating with more exposure than you realize.
What the contracts usually say
Most freelance and small-agency contracts fall into one of three categories:
No contract at all. More common than anyone admits, especially for smaller engagements. Without a written agreement, liability defaults to local law, which generally means the person who delivered the work bears responsibility for defects.
A template contract that covers deliverables but not security. The agreement specifies what gets built and when, but says nothing about security standards, vulnerability remediation, or who's responsible if the application is compromised after delivery. The builder assumes the client is responsible for security once the project is handed over. The client assumes the application was built securely. Neither assumption is documented.
A detailed contract with a warranty clause. The agreement includes a warranty period during which the builder fixes bugs. But "bugs" and "security vulnerabilities" aren't the same thing. A warranty clause that covers functional defects may not cover architectural security gaps (like the absence of rate limiting or proper authorization) because the application works as specified. The vulnerability isn't that something is broken; it's that something was never built.
The "it was built to spec" defense
This is where most builders assume they're protected. "The client asked for a project management tool with user authentication and a dashboard. That's what I built. They didn't ask for rate limiting, input validation, or row-level security."
This defense has two problems.
First, courts and regulators increasingly view basic security measures as implied requirements, not optional extras. A reasonable person expects that an application handling their data implements standard protections. Arguing that the client didn't specifically request encryption or access controls is like arguing that a building contractor doesn't need to install fire exits unless the client specifically asks for them.
Second, if you're using AI tools to build faster and cheaper than you could by hand, the expectation from the client is that you're using your professional expertise to deliver a production-quality product. The speed is the benefit to you, not a reason to deliver less. The client isn't paying for an AI-generated prototype; they're paying for a finished application.
The regulated-industry multiplier
All of this gets much more serious when the client operates in a regulated industry. An application handling patient health information that lacks proper access controls isn't just a security issue. It's a HIPAA violation. An application processing financial transactions without audit logging may violate SOX or PCI requirements.
In regulated industries, it's not a question of whether someone will notice the vulnerability, but when the auditor or regulator finds it, and whether the fine and remediation cost falls on the client, on you, or on both.
If you're building for clients in healthcare, financial services, legal, or education, the compliance implications of AI-generated code aren't a hypothetical risk. They're a business-critical exposure that should be addressed before delivery.
What actually protects you
A contract that addresses AI-generated code explicitly. Your agreement should acknowledge the use of AI tools in development, specify the security standards the deliverable will meet, define the scope of your responsibility post-delivery, and cap your liability. This is about defining responsibility clearly so both parties understand what they're getting, not about avoiding responsibility.
A security review before delivery. Having a third party audit the code before you hand it to the client accomplishes two things. First, it finds and fixes the vulnerabilities that the AI tool introduced. Second, it creates a documented record that you took reasonable steps to deliver a secure product. If something goes wrong later, that audit report is your evidence of professional diligence.
Ongoing maintenance terms that include security. If your engagement includes post-delivery support, define whether that includes security patches, dependency updates, and vulnerability remediation. Many builders offer 30-day bug-fix periods that explicitly exclude security work, which leaves the client exposed and creates ambiguity about who's responsible for issues discovered later.
The business opportunity most builders miss
The counterintuitive part: addressing the liability question explicitly actually helps you win more business, not less.
When you tell a prospective client "we use AI tools to build faster, and every project goes through a third-party security audit before delivery," you're saying something almost no other builder or agency is saying. You're differentiating on trust and professionalism in a market that's increasingly commoditized on speed and price.
Making security review part of delivery also changes the value proposition. An agency that can document independent review is selling something more defensible than speed alone.
The audit can be shown as a separate project line item rather than absorbed as overhead. In our experience, clients understand the value because the report documents that security was treated as part of the delivery process.
What agencies should change
AI coding tools will keep getting faster and more capable. The professional obligation is to make sure that increased development speed doesn't remove the review steps clients assume are already part of a finished product.
Clear contracts, an independent security review and transparent communication about AI-assisted development are practical ways to manage that responsibility.