An AI code policy has to settle two things in writing: what your business owns of the code it ships, and what that code must pass before it merges. On ownership, name the approved tools, keep a record of the human contribution (the prompts, the edits, the review) because that is what copyright attaches to, and understand that a vendor's terms assigning you the output cannot create copyright where there was no human authorship. On security, set a review threshold that says which changes a person reads line by line, require dependency and secret scanning on every AI-assisted branch, and treat licence contamination from training data as a real class of risk rather than a theoretical one. Everything else in the document is commentary. If a rule cannot be checked, either in review or in CI, it is not a rule.
Two questions, one short document
A policy that runs to fourteen pages is a policy nobody reads twice. The useful version fits on one side of A4 and answers two questions a developer has at the moment they are about to merge something an AI wrote: do we own this, and has it been checked?
Ownership and security look like separate departments, legal and engineering, and they are usually written up by separate people. In practice they fail together. The change nobody read is also the change with no record of who authored what, the dependency nobody scanned, and the snippet that arrived carrying an open-source licence obligation. One habit produces all four. So one document should address all four.
This piece is about what that document says. The legal groundwork behind the ownership half is covered separately in managing AI code ownership and security in a business, which goes into vendor terms and the copyright test in more detail; here the interest is in what you actually write down and how you make it stick.
The ownership clauses that do real work
Start from the part of the law that is settled. Copyright needs a human author. AI-assisted work can be protected, but only the human-authored portions of it, and applicants registering a work are expected to disclose the AI involvement. MBHB’s analysis of AI-generated code puts the threshold plainly: where a human developer supplies sufficient creative input through iterative prompting, editing and refining, copyright can attach to that person, and through an employment agreement to their employer.
The practical consequence is a documentation clause, and it is the clause most policies leave out. If your claim to a codebase rests on the human contribution being substantial, then the evidence of that contribution should exist somewhere other than memory. Prompt histories, commit messages that describe intent, review records, the design notes that shaped the change. None of that is exotic; most of it is a by-product of working carefully. The policy’s job is to say it must be kept rather than discarded when the branch is deleted.
The second clause is about vendor terms, and it needs one sentence of honesty. Platform terms of service commonly assign ownership of output to the user. That is a contract between you and the vendor. It does not manufacture a statutory copyright that never existed, and it does not bind a third party whose code the model reproduced. Both things can be true at once: the vendor gives you everything it can give, and what it can give is less than a copyright in a purely machine-written file.
The third clause is licence contamination. Assistants trained on public repositories can emit snippets that carry latent obligations from GPL, MIT or anything else in the training data. If you ship proprietary software, that is a supply-chain question, not a philosophical one, and it belongs alongside your existing open-source review. One widely repeated figure puts licensing irregularities at 35% of AI-generated code; I would not build a policy on it, because it traces back to a single secondary source rather than a published study. Treat the risk as established and the size of it as unmeasured.
Why the litigation matters even though it is not finished
The reason to write ownership rules now rather than after the case law lands is that the case law is moving and the exposure is per-violation. The Copilot class action was filed in November 2022 on behalf of open-source programmers against GitHub, Microsoft and OpenAI, alleging violations of open-source licences. Most of the copyright claims were dismissed in January 2024, but the contract and licence-breach claims went forward, with the court treating open-source licences as binding agreements.
What remains live is narrower and more awkward. BakerHostetler’s tracking of Doe v. GitHub follows the DMCA section 1202 question now before the Ninth Circuit: whether removing or altering copyright management information requires an identical copy. Statutory damages under that section run from $2,500 to $25,000 per violation, which is the sort of arithmetic that changes how a business feels about attribution stripping.
Alongside that, two dates are worth putting in a policy’s review calendar. The EU Product Liability Directive takes effect on 2 August 2026 and covers software and AI systems, which puts defective AI-assisted code inside a producer liability regime. California’s AB 316 removes the argument that the AI acted on its own. Neither changes what good engineering looks like. Both change who pays when it was not done.
The security half, and the numbers behind it
The strongest single benchmark is the Veracode 2025 GenAI Code Security Report, which tested code from more than 100 large language models across 80 real-world tasks. A large share of samples failed security tests, with certain languages and vulnerability classes, including defences against cross-site scripting, performing especially poorly. Veracode’s CTO named the workflow rather than the models as the cause: developers relying on AI to generate code without explicitly defining security requirements, leaving secure coding decisions to the model.
Academic work says something similar and adds a detail that matters more for policy design. Pearce and colleagues, in one of the first empirical studies of Copilot’s security, found approximately 40% of generated programs contained vulnerabilities, with C worse than Python. Perry and colleagues found that developers using AI assistants wrote significantly less secure code and, worse, rated their insecure solutions as secure. A systematic review across nineteen studies reported high-level agreement that these models do introduce vulnerabilities despite mitigations.
That second finding is the one to design around. A false sense of security is not fixed by asking people to be more careful. It is fixed by checks that do not depend on how confident the author feels.
The volume problem compounds it. Apiiro’s analysis across tens of thousands of repositories at large enterprises between December 2024 and June 2025 found AI-assisted developers committing at three to four times the rate of their non-AI peers, with monthly security findings rising tenfold over the same period, including a sharp increase in design-level flaws such as authentication bypass and a rise in exposed secrets. Faster code with the same review capacity is not a productivity gain, it is a queue. Which classes of flaw recur is set out in the security flaws to look for in AI-generated code.
Set the review threshold explicitly
The honest position is that nobody reads every line, so the policy should say which lines get read. My rule, argued at length in when vibe coding needs a line-by-line diff read, is that a human reads the diff wherever the harm is an absence rather than a behaviour: authorisation checks, handling of untrusted input, secrets and configuration, database migrations, destructive operations, new dependencies, and anything touching CI or infrastructure.
Everywhere else, the better question is what evidence exists that the change did what was asked and nothing more. Tests, a manual pass through the affected path, static analysis, secret scanning. Writing this down as a threshold rather than an aspiration is what separates a policy from a poster. It also makes the trade-off visible to whoever set the delivery date.
The governance gap here is wide. One 2026 compilation of AI coding security statistics reports that a majority of enterprises have no formal policy covering AI code use, and that developers frequently accept AI suggestions without modification. Those two findings explain each other.
Dependencies, and the packages that do not exist
Slopsquatting deserves its own line in the policy because the failure is silent. A model suggests a package name that does not exist, an attacker registers that name with malware in it, and the next developer to accept the suggestion installs it. Reported hallucination rates for package names vary by model, with commercial models generally faring better than open-source ones, which makes software composition analysis on every AI-assisted branch a baseline control rather than a nice-to-have.
The useful rule is short: no new dependency enters the repository without a human checking it exists, is the package intended, is maintained, and is licensed compatibly. That is thirty seconds of work and it closes an entire attack path.
Shadow AI is where the source code goes
A policy that only governs the approved tools governs the wrong half of the problem. A growing body of shadow AI research points to source code being one of the most common types of data developers paste into unapproved generative AI tools.
That is your codebase, pasted into whatever a developer had open, under terms your legal team has never read, with no record of the prompt and no claim to the output. It is an ownership failure and a confidentiality failure in the same action. The response is not a ban, which simply moves the behaviour off the corporate network. It is a short list of sanctioned tools with terms someone has actually checked, a plain statement of what may never be pasted into an unapproved one, and a route for asking about a new tool that gets an answer in days rather than never.
Make it checkable, or do not write it
Anything in the document that depends on goodwill will decay in a quarter. Anything wired into the pipeline will still be there next year. So sort each rule into one of two piles: things a person must judge, and things a machine must enforce.
- Secret scanning and dependency scanning on every branch, blocking on failure.
- Static analysis tuned so its output is small enough to read.
- A required human reviewer on paths matching the threshold above: auth, migrations, infrastructure, payment handling.
- Commit metadata or a template that records AI involvement, so the human-contribution evidence accumulates without anyone maintaining a spreadsheet.
- A scheduled review of the policy itself, because tool terms and liability rules are both moving.
The guardrails matter more than the wording. A prototype built quickly with AI assistance is a reasonable thing to want, and vibe coding for businesses is worth understanding rather than banning. What businesses get wrong is carrying a prototype’s review standard into production, then discovering the risks and limits at the point a customer finds them.
Written with AI assistance and reviewed under our editorial policy. Vibe coding changes quickly; details reflect sources current on 2026-09-06. Some passages are the author's opinion. Spotted an error? tell us.
Frequently asked questions
- Does our business own code an AI wrote for us?
- You own it in the sense that the vendor's terms commonly assign the output to you, but copyright itself needs a human author, so purely machine-written portions may not be protected. Where a developer prompts, edits and refines the code substantially, copyright can attach to that human work and, through an employment agreement, to the business. Keeping records of that human contribution is what makes the claim provable later.
- How long should an AI code policy be?
- Short enough that a developer can hold it in their head at the moment they open a pull request. One page covering approved tools, what may never be pasted into an unapproved tool, which changes require a line-by-line human read, and which scans block a merge will do more than a long document nobody consults.
- What is slopsquatting and why does it belong in a policy?
- Slopsquatting is when an AI suggests a package name that does not exist and an attacker registers that name with malicious code inside it. Because hallucinated package names are common enough to be predictable, the control is to require a human check on every new dependency and to run software composition analysis on AI-assisted branches.
- Is banning AI coding tools a reasonable response to the security data?
- A ban tends to move the behaviour rather than stop it, and the Verizon DBIR data on source code uploads to generative AI tools suggests it is already happening outside sanctioned channels. A list of approved tools with terms someone has read, plus enforced scanning and a clear review threshold, addresses the same risk without pushing the work into places you cannot see.