August 8, 2026 / custom-software, ai, security, utah-business
AI Generated Code Security: What Business Owners Should Ask
AI now writes roughly half of committed code, and the 2026 security data has not improved. Here is what to verify before you approve software built for your business.
Half the code, and no new checking
If you commissioned software in the past year, a model wrote some of it. That is not a scandal and it is not a secret. It is how the work is done now, at nearly every shop, including ours.
What has not kept pace is the checking. Veracode's 2026 GenAI Code Security Report, published July 28, put the average security pass rate across the models it tested at 56 percent, essentially flat against the prior year while the volume of AI written code climbed. Roughly 44 percent of code generation tasks introduced a vulnerability the graders considered risky.
Read that as a buyer rather than as a developer. It does not mean the software you paid for is broken. It means the first draft of it roughly flips a coin on security, and the value of your engagement now sits almost entirely in what happened after the first draft.
This post is narrower than our piece on AI transparency, which is about understanding AI systems your business runs, and narrower than our post on AI and liability, which is about insurance and exposure. This one is only about the code itself: who wrote it, who checked it, and what you are entitled to ask.
The failures are not where you would guess
The instinct is to assume AI gets the dramatic things wrong. The data says close to the opposite.
In the same report, models handled the famous categories well. SQL injection passed at 83 percent. Weak cryptographic algorithms passed at 87 percent. Those are the textbook vulnerabilities, heavily represented in everything the models trained on, and they have largely been learned.
Then the floor drops out. Cross site scripting passed at 15 percent. Log injection passed at 12 percent.
Both of those are context problems rather than knowledge problems. A model writing one function cannot see where that output eventually lands, and where it lands is precisely what decides whether it is safe. Cross site scripting is what lets an attacker get working code into a page your customer loads. Log injection lets someone write whatever they like into the record you would go read after an incident, which is a quiet way of saying your audit trail becomes negotiable at the worst possible moment.
"Our developers review everything" means less than it did
The honest follow up is whether human review catches the rest. The people doing that reviewing have become notably candid that it is harder than it looks.
Stack Overflow's 2025 developer survey, published at the end of December and covering more than 49,000 developers, found trust in the accuracy of AI tools had fallen to 29 percent, down from 40 percent the year before. The most cited frustration, named by 45 percent of respondents, was AI output that is almost right, but not quite.
Almost right is exactly the failure mode that survives a review. Code that is obviously wrong gets deleted in seconds. Code that reads well, runs clean, passes the path everyone tests, and mishandles one class of input is the code that ships.
So "we review everything" is not a bad answer. It is an incomplete one. The useful follow up is what the review consists of, and whether anything automated runs alongside it that never gets tired or busy.
Utah puts the obligation on you, not on your developer
This is the part most owners have never been told, and it is specific to where you operate.
Utah has a statute worth knowing about: the Cybersecurity Affirmative Defense Act. Under Utah Code 78B-4-702, a business that creates, maintains, and reasonably complies with a written cybersecurity program has an affirmative defense against a claim that it failed to implement reasonable information security controls when a breach happens. It is a shield rather than a mandate, it is entirely optional, and it only exists if the program was in place before the breach.
The components are spelled out in 78B-4-703. The program has to reasonably conform to a recognized framework, and the statute names them: NIST special publication 800-171, NIST 800-53 and 800-53a, the FedRAMP security assessment framework, the CIS Critical Security Controls, or the ISO/IEC 27000 family. It can also qualify by reasonably complying with the regime that already governs your data, which is the route most small businesses actually take. HIPAA covers health information, Gramm-Leach-Bliley covers financial, and the PCI data security standard covers cards.
Now read one clause slowly. To count as a reasonable security program, the statute requires risk assessments on, among other things, the network and software design for the person claiming the defense. Not the vendor's design. Yours. The software you commissioned sits inside the scope of the protection you would want to claim on the worst day of your year.
That reframes the whole conversation. Asking your developer how AI generated code gets checked is not being difficult or technical. It is the diligence your own affirmative defense quietly assumes you already did.
Five things to ask before you approve a build
None of these require you to read a line of code.
- What runs automatically on every change? You want named tooling, not a philosophy. Dependency scanning and static analysis are cheap now, and the entire point of them is that they do not have off days.
- Which parts of this touch personal information, and what validates input there? Ask for the list of screens and endpoints. If nobody can produce it within a day, that is itself the finding.
- How is output escaped everywhere user content gets displayed back? That is the cross site scripting question in plain language, and it is the category the models fail hardest at.
- What goes into the logs, and who can write to them? If the log is your evidence after an incident, it has to be evidence you can trust.
- Can I take all of it and leave? Repository, database export, environment variables documented. Ownership is a security control, because you cannot fix what you cannot reach.
If the software handles health, financial, or client data, add one more. Ask which of the frameworks named in 78B-4-703 you are aiming at, and get that answer in writing rather than in a meeting.
What this looks like in practice
We are building a healthcare analytics dashboard for a residential treatment provider, and the first release deliberately did nothing but read and display. No writes, no edits, no destructive paths at all. That was a scoping decision, and it was equally a security decision: the smallest possible surface while the data model was still settling.
The same instinct governs where AI fits in the work. Generated code is fine for the parts that look like every other codebase, the form handling, the layout, the routine transform between two shapes of data. It gets treated as a draft anywhere a decision is made about who may see what. Boundaries are where context lives, and context is the one thing the model does not have.
That is the same judgment behind our buy vs build framing and the way we scope replacements for spreadsheets that quietly became systems. The value is in the decisions at the edges, not the volume of code in the middle.
The wrong conclusion to draw
Do not go looking for a developer who refuses to use AI. You would pay more for slower work and have no evidence you were getting anything safer, because hand written code never had a clean record either.
The right conclusion is narrower and more useful. The generation step got cheap, so the checking step is now the product. A shop that can tell you exactly what runs on every commit, which parts of the system touch personal data, and how you would get everything out tomorrow is doing the work. A shop that answers those three questions with enthusiasm about velocity is not.
Frequently asked questions
Should I ask whether AI wrote my software? Ask, but do not make the answer the deciding factor. Nearly everyone is using it, and the people who deny it most confidently are sometimes just least aware of what their own tooling does. The review process is the better question and it gets you a more honest answer.
Does using AI void my cyber insurance? Read your policy rather than assuming either way. Carriers have been rewriting terms around AI, which we covered in our post on AI and liability. The broad pattern is that policies care about controls and disclosures, not about which tool typed the characters.
Our software was built two years ago. Does any of this apply? The Utah affirmative defense depends on a program being in place at the time of a breach, so it works forward from whenever you set it up rather than backward. Older code is still worth a single focused review, especially anywhere it accepts input from the public.
Is a small business really a target for this? The relevant question is not whether anyone is hunting you specifically. Most of what reaches small businesses is automated and indiscriminate, which is exactly what generic, widely shared vulnerability classes expose you to.
If you have software being built right now and you are not sure what to ask, send us the scope and we will tell you which of the five questions above your current arrangement already answers. Start with our custom software team and we will work through it in an initial consultation.