Who Owns Code That AI Writes?

The wrong question, and the right one

Most owners ask whether their AI-written code is copyrightable. For a business, that is the wrong question. The right question is whether you can stop someone from copying your code or walking out the door with it, and copyright was never the protection that did that job. A competitor who copies your software hurts you whether or not you hold a registered copyright; what stops them is that they cannot get the code in the first place, and that you have a contract that says it is yours.

So reframe the goal. Your moat is secrecy plus contract: keep the code confidential, and write down who owns it. Copyright becomes a backstop that protects the genuine human contribution in your software, not the wall the whole business leans on. In my Minnesota business-law practice, the companies with durable protection are the ones that treat their code as confidential know-how with real access controls and clear ownership terms, not the ones waiting to see whether the Copyright Office will register their work. The rest of this guide takes the three protections in turn, copyright, trade secret, and contract, and shows where each one does and does not hold.

Vibe coding is a spectrum, not a yes-or-no

How much copyright you can claim in AI-written code depends on how much you steered the AI, and that runs along a spectrum rather than a single line. The term “vibe coding” was coined by Andrej Karpathy in February 2025 and named Collins English Dictionary’s Word of the Year for 2025. The developer Simon Willison drew the useful distinction: if you reviewed, tested, and understood the code, that is “using an LLM as a typing assistant,” not vibe coding. True vibe coding is defined by the absence of human review, accepting whatever the model produces without reading the diffs.

That distinction is also the legal dividing line. Picture a range. At one end is hands-off vibe coding, where you type a request and accept the output unread. At the other end is active steering, where you set the architecture, write and rewrite substantial parts of the code, and arrange the pieces into a finished whole. The more of the expression you actually author, the stronger your claim; merely choosing among finished outputs, by contrast, has not been enough. Steering an AI toward a result you have shaped is closer to the work of a painter or a graphic designer than to typing a number into a calculator and pressing equals. Pure hands-off generation is the genuine gap, because there the human did not shape the expression at all.

How you work with the AI	What the law treats as your contribution	Copyright in the result
Hands-off vibe coding (accept the output unread)	A prompt, nothing more	Weakest. A prompt alone does not make you the author, even over many iterations. The U.S. Copyright Office refused registration in Théâtre D’opéra Spatial and SURYAST on that basis.
Detailed prompting, then choosing among whole outputs	Selection among finished AI outputs	Still weak. Choosing or rejecting whole outputs, by itself, has not been treated as authorship.
Arranging and substantially editing AI-generated material into a new work	Creative selection, coordination, arrangement, and modification	Protectable in your human contribution. This is the pathway behind the American Cheese registration.
Writing and editing the code yourself, with AI as one tool	The expression itself	Ordinary copyright in the human-authored code, though still thin for functional code.

Copyright: what you can and cannot protect in AI-written code

The human-authorship rule

United States copyright protects only what a human creates. In Thaler v. Perlmutter, decided March 18, 2025, the U.S. Court of Appeals for the D.C. Circuit affirmed the Copyright Office’s refusal to register an image whose only listed author was an AI system, holding that “The Creativity Machine cannot be the recognized author of a copyrighted work because the Copyright Act of 1976 requires all eligible work to be authored in the first instance by a human being.” The same opinion was careful to preserve AI-assisted work: “the human authorship requirement does not prohibit copyrighting work that was made by or with the assistance of artificial intelligence.” The Supreme Court declined to review the decision in March 2026, leaving it in place. So the rule is not that AI involvement poisons a work; it is that something a human authored must be in there.

The Copyright Office line: a prompt alone is not enough

The U.S. Copyright Office addressed this directly in its January 2025 report, Copyright and Artificial Intelligence, Part 2: Copyrightability. Its position is narrower than the headlines suggest. The Office concluded that “The use of AI tools to assist rather than stand in for human creativity does not affect the availability of copyright protection for the output,” but that “Copyright does not extend to purely AI-generated material, or material where there is insufficient human control over the expressive elements.” On prompting specifically, the Office found that, “Based on the functioning of current generally available technology, prompts do not alone provide sufficient control,” and that “prompts alone do not provide sufficient human control to make users of an AI system the authors of the output.”

The same report names three ways your human work still earns copyright even when AI is in the loop: “Human authors are entitled to copyright in their works of authorship that are perceptible in AI-generated outputs, as well as the creative selection, coordination, or arrangement of material in the outputs, or creative modifications of the outputs.” Perceptible human-authored material, creative selection and arrangement, and creative modification: those three pathways are where AI-assisted authorship lives.

The Office also left the door open, and that is where the genuine disagreement sits. It acknowledged that “There may come a time when prompts can sufficiently control expressive elements in AI-generated outputs to reflect human authorship,” and that with more control, “a different conclusion may be called for.” My own view is that detailed direction, reviewing the output, and iterative refinement already look more like authorship than the Office currently allows, and I expect courts to give creative steering more credit over time. But the disagreement is narrow, confined to the pure prompt-to-output case, and I would not build a company’s protection on winning that argument today.

The master mind test, and where the line has fallen

This question runs through a photography case from 1884. In Burrow-Giles Lithographic Co. v. Sarony, the Supreme Court held that a photograph could be copyrighted because the photographer made creative choices, posing the subject and arranging the scene and lighting, and so was the “inventive or master mind” who “actually formed” the picture. The Copyright Office now turns that same master mind test against AI prompting. In its decision on the graphic novel Zarya of the Dawn, the Office found that “A person who provides text prompts to Midjourney does not ‘actually form’ the generated images and is not the ‘master mind’ behind them.”

The Office’s own decisions show where the line falls. It refused to register the image “Théâtre D’opéra Spatial” because, in the Copyright Review Board’s words, the applicant’s “sole contribution to the Midjourney Image was inputting the text prompt that produced it.” It refused another AI image, “SURYAST,” because “the expressive elements of pictorial authorship were not provided by” the human. But it granted a registration for an image titled “A Single Piece of American Cheese” (Reg. No. VAu001543942), produced through substantial iterative human editing, on the basis of the human “Selection, coordination, and arrangement of material generated by artificial intelligence,” with the raw AI components disclaimed. The pattern is consistent: describing what you want and accepting whole outputs does not make you the author, but arranging and substantially reworking the AI-generated material into a new work can.

How this plays out for prompt-plus-editing work is being tested now. In Allen v. Perlmutter, No. 1:24-cv-02665 (D. Colo.), the artist behind “Théâtre D’opéra Spatial” has challenged the Office’s refusal in federal court, and as of June 2026 the case is pending with no ruling. It is the first case to put the prompt-and-edit line in front of a judge, and worth watching.

Register the human part, disclaim the AI part

For AI-assisted software, the realistic copyright play is to register what your people authored and honestly disclaim what the AI generated. This is the Office’s required practice, not a loophole. The Office’s 2023 registration guidance imposes a “duty to disclose the inclusion of AI-generated content in a work submitted for registration” and provides that “AI-generated content that is more than de minimis should be explicitly excluded from the application,” meaning anything beyond a trivial AI contribution has to be carved out. (88 Fed. Reg. 16,190.) So document and register the human-authored portions, the architecture, the human-written and human-edited code, and the selection and arrangement, and disclaim the rest. A registration that quietly claims the AI’s work is worth less than an honest one, because an overclaim can undermine the registration when you need to enforce it.

Even hand-written code gets thin copyright

Here is the part owners miss. Even code a human writes entirely by hand carries weaker copyright than most creative works, because of a second subtraction that has nothing to do with AI. Under 17 U.S.C. § 102(b), copyright never protects “any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.” Software is built out of exactly those things. The merger doctrine (where an idea can be expressed in only one or a few ways) and scènes à faire (elements dictated by function or convention) strip out more. In Google LLC v. Oracle America, Inc., decided April 5, 2021, the Supreme Court assumed “for argument’s sake” that the copied code was copyrightable without deciding the question, and observed that functional declaring code is, “if copyrightable at all, further than are most computer programs (such as the implementing code) from the core of copyright” (the Court ultimately resolved the case on fair use). What survives those exclusions protects you mainly against close copying of whatever original expression remains. Subtract the AI-generated portions, then subtract the functional core, and what copyright actually guards in a typical codebase is narrow. That is the strongest practical reason not to rely on it.

Trade secret is the real moat

Trade secret law protects your code regardless of whether a human or an AI wrote it, as long as you keep it secret, which is why it is the protection that does not flinch at the authorship problem. Under the Minnesota Uniform Trade Secrets Act, Minn. Stat. § 325C.01, subd. 5, a “trade secret” is information that “derives independent economic value, actual or potential, from not being generally known to, and not being readily ascertainable by proper means by, other persons who can obtain economic value from its disclosure or use,” and that “is the subject of efforts that are reasonable under the circumstances to maintain its secrecy.” Nothing in that definition asks who, or what, created the information. Source code your competitors cannot see has value precisely because they cannot see it. The Minnesota Uniform Trade Secrets Act lets you pursue anyone who acquires or discloses that code by improper means, through injunctions (Minn. Stat. § 325C.02) and damages (Minn. Stat. § 325C.03), whatever its copyright status.

That is why the companies with the strongest software protection treat their code as confidential know-how: real access controls, confidentiality terms with every person who touches the code, and need-to-know limits. Copyright asks whether the work is original enough. Trade secret law asks only whether you kept it secret. For software built largely by prompting, the second question is far easier to answer in your favor.

Trade secret protection does have a ceiling worth understanding. It stops misappropriation, someone taking or disclosing your code by improper means, but it does not stop a competitor who independently develops the same thing or who lawfully reverse-engineers code you released, and it ends the moment the secret genuinely gets out, with no way to claw it back. That ceiling is the reason you pair secrecy with contract rather than rely on either alone, and it is why the protection is strongest for code your customers never receive, such as software that runs on your own servers.

The AI trap that destroys trade secrets

There is a way to forfeit this protection without realizing it: feeding your proprietary code into an AI tool whose terms let the vendor train on or retain your inputs. Reasonable secrecy is the whole requirement under Minn. Stat. § 325C.01, subd. 5, and pasting your code into a consumer chatbot that learns from what it receives can break that secrecy. The fix is to choose AI tools with enterprise terms that bar training on your data and limit retention. Anthropic’s commercial terms, for example, state that “Anthropic may not train models on Customer Content from Services.” A no-training, zero-retention commitment is not a procurement nicety; it is part of how you keep a trade secret secret. The same care belongs in your AI vendor contracts, and specifically in the clauses that limit how a tool uses your data.

Contract: engineer ownership instead of hoping

A contract can decide who owns code as between two parties even when copyright is uncertain, which is why ownership and assignment language belongs in every developer, contractor, and vendor agreement. This is the most reliable lever you control. The work-made-for-hire rule under 17 U.S.C. § 101 gives an employer ownership of what employees create within the scope of their employment, but it does not reach independent contractors automatically. A contractor’s work needs an express written assignment, or you do not own it. Put assignment clauses in every engagement and you have engineered ownership instead of hoping the Copyright Office agrees.

There is one thing a contract cannot do, and the AI vendors say so themselves: a contract cannot manufacture a copyright that does not exist. Read the output-ownership terms of the major tools and you find the same careful hedge.

• OpenAI’s terms assign to you “all our right, title, and interest, if any, in and to Output,” and warn that “output may not be unique and other users may receive similar output.” (OpenAI.)
• Anthropic’s commercial terms say the customer “owns its Outputs” and that “Anthropic hereby assigns to Customer its right, title and interest (if any) in and to Outputs.” (Anthropic.)
• Cursor’s terms assign “all of our right, title, and interest if any in and to any Suggestions,” and note that suggestions “may be similar to or the same as Suggestions provided to other customers.” (Cursor.)

The phrase “if any” is doing real work. Each vendor is transferring whatever rights it holds, which may be none, because under Thaler v. Perlmutter no one owns a copyright in purely AI-generated output. Ownership under a contract is not the same as a copyright, and it is not the same as exclusivity: another customer may receive output just like yours. Some vendors add an intellectual-property defense for paying customers (GitHub, for instance, extends a third-party-claim defense to outputs where the customer’s agreement provides for it), but that is insurance against an infringement claim, not a grant of ownership. Treat the contract as the tool that allocates rights and shifts risk between you and the people you work with, the counterpart to ownership of AI outputs under your contractual terms, not as a substitute for protectable rights.

One contract risk runs the other way. Code an AI tool reproduces from open-source training data can carry a license obligation into your codebase, and the live exposure there has been contractual rather than copyright-based. In Doe v. GitHub, the federal court in the Northern District of California dismissed the federal copyright-management-information claims (brought under the Digital Millennium Copyright Act, or DMCA) in 2024 and narrowed the case to open-source-license and breach-of-contract theories. Scan AI-generated code for open-source contamination the same way you would scan any third-party code.

Patent and the edges

A patent can protect a genuinely novel and non-obvious technical invention, but it is rarely the right tool for ordinary application code. Patents protect inventions rather than expression, so a patent does not care who or what typed the code. The obstacle is subject matter. Under 35 U.S.C. § 101, as the Supreme Court applied it in Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), an abstract idea does not become patent-eligible merely because it is implemented on a generic computer. Most business and application software runs into that wall. Where your team has built a real technical improvement, a new method that solves a concrete technical problem, a patent may be worth evaluating. For the typical codebase, it is not the play, and it is slow and expensive besides.

Which law protects what

The four protections do different jobs, and the practical strategy is to layer them rather than pick one. The table below is the short version of everything above.

Protection	What it protects	Strength for vibe-coded software	What you must do
Copyright	Original human expression: architecture, selection and arrangement, human-written and human-edited code	Weak to moderate; nothing for purely AI-generated portions	Document human authorship, register the human contribution, and disclaim the AI
Trade secret (Minn. UTSA)	Any code kept secret that has economic value from its secrecy, regardless of who or what wrote it	Strong, as long as you keep it confidential	Access controls, confidentiality terms, and AI tools with no-training and limited-retention terms
Contract	Whatever the agreement assigns or licenses, as between the parties	Strong for allocating rights and risk; cannot create a copyright that does not exist	Ownership and assignment clauses in every developer, contractor, and vendor agreement
Patent	A novel, non-obvious technical invention or method	Rare for ordinary application code	Evaluate only for a genuine technical invention; expect Section 101 abstract-idea hurdles

Do not overlook your skill files

There is one category of your AI work that is often your most clearly human-authored and most valuable intellectual property, and owners routinely ignore it: the skill files. These are the prompts, rules, configuration files, and reusable instruction sets your developers write to steer the AI, the .cursorrules, the prompt libraries, the agent workflows. Unlike the AI’s raw output, your team wrote these by hand, so the human-authorship problem that weakens copyright in AI-generated code largely disappears, and their value as confidential know-how is high. They also raise a distinct question that AI-written code usually does not: when an employee builds a personal library of skill files, does the employer or the employee own it? That question turns on employment scope, your assignment agreements, and how the files were developed, and it warrants its own analysis. I cover who owns AI skill files, employer or employee, in a companion guide.

What this means for your business, and what to do now

Two business realities follow from all of this. First, code that no one can claim to own is, for competitive purposes, close to public: a competitor who lawfully obtains uncopyrightable, unsecured code may be free to use it. Second, this question now shows up in diligence. Buyers and investors increasingly ask how much of a company’s code it can actually claim to own and protect, and a codebase built largely by prompting, with no trade-secret hygiene and no assignment clauses, is a finding that can move a deal. The fix is not exotic. It is layered protection, put in place before you need it.

Here is the practical checklist:

1. Document the human steering. Keep the architecture decisions, the prompt history, and the human edits in version control. That record is your evidence of protectable human authorship.
2. Register the human-authored portions, and disclaim the AI. Follow the Copyright Office’s disclosure rule rather than overclaiming, so the registration holds up if you ever enforce it.
3. Run trade-secret hygiene. Access controls, confidentiality terms with everyone who touches the code, and need-to-know limits, so the code meets the reasonable-secrecy standard of the Minnesota Uniform Trade Secrets Act.
4. Choose AI tools with the right terms. Enterprise agreements that bar training on your inputs and limit retention, so using the tool does not destroy your secret.
5. Put ownership and assignment clauses in every agreement. Developers, contractors, and vendors, with express assignment from contractors, who are not covered by work-made-for-hire automatically.
6. Scan for open-source contamination. Treat AI-generated code like any third-party code that may carry a license obligation.

The throughline is the one I started with: for software built largely by prompting an AI, the moat is secrecy and contract, and copyright is the backstop that protects genuine human contribution. If you want to make sure your business actually owns and protects the code it is building with AI, email [email protected]. For the broader picture, see my related guidance on who owns the copyright to AI-generated images and how I approach copyright and intellectual property work.