In most workplaces the company should own and run the app. That means a named business owner, source code and deployment in company-controlled accounts, and the departing person’s access removed. Whether the company holds legal title to the code is a separate question. It depends on the employee’s signed agreements, their job scope, the facts of how the app was built, and the jurisdiction. Nothing about the app being “vibe-coded” changes that analysis. The two questions have different answers and different urgency, so treat them separately: custody now, title by contract review.
This article describes general U.S. principles. Other countries differ, contracts vary, and a live dispute needs a lawyer who can read the actual documents.
As an Amazon Associate I earn from qualifying purchases.
Legal title and operational custody are different problems
When a developer leaves, two things need settling:
- Legal title: who holds the intellectual property rights in the code, and on what terms. This can be contested, and the answer turns on documents and facts.
- Operational custody: who can log in, deploy, pay the bills, rotate secrets, fix bugs and answer for the app. This is purely an organizational matter, and it is the part that breaks things on the employee’s last day.
A company can have a perfectly clear ownership claim and still be locked out of a database hosted under a personal account. It can also have unclear title and a well-run handover. Fix custody first, because it does not require anyone to win a legal argument.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesWhy “vibe-coded” is not an ownership category
No rule says AI-assisted apps belong to the prompter, the employer or the tool vendor. For the employment analysis, an app built with an AI builder is treated like other work product: was it created as part of the job, and what did the employee agree to? Microsoft’s guidance for AI-built apps makes a related point on responsibility, not ownership. In Microsoft Learn’s words, “The code your AI agent generates is code you ship, and you are accountable for everything in your app regardless of how it was written.” That is an operational accountability statement. It does not say who owns the intellectual property, but it does mean a company cannot treat an unreviewed AI-generated app as someone else’s problem once it is in use.
#1 Best Overall
Two claims to avoid in either direction: that every app made during employment automatically belongs to the employer, and that an employee personally owns an app because they wrote the prompts.
What decides legal title
| Question | What to check | Why it matters |
|---|---|---|
| Was the app part of the employee’s job? | Job description, manager instructions, tickets, project records, time and commit history | Central to both work-made-for-hire principles and most employee IP agreements. AI use alone tells you nothing here. |
| What did the employee sign? | Invention or IP assignment, confidentiality terms, AI acceptable-use policy | Agreements can allocate rights differently from the default rule, subject to state or national law. |
| What does the coding platform’s contract cover? | Customer-content, output, platform and third-party terms in force for that account type | These govern the vendor-to-customer relationship, not employer-to-employee rights. |
| Which parts are protectable at all? | Human-authored code, edits and design versus unmodified generated output | A contract can allocate rights, but it does not prove every generated element is copyrightable. |
| Whose resources and data were used? | Company accounts, credentials, data and time versus personal ones | Shapes how any side-project argument plays out and what the company can demonstrate. |
Work made for hire
Under U.S. copyright law, 17 U.S.C. § 201(b) provides that for a work made for hire, “the employer or other person for whom the work was prepared is considered the author,” and, unless the parties expressly agree otherwise in a signed writing, owns all of the rights comprised in the copyright. The statute is not a blanket rule that everything an employee makes belongs to the employer. It applies when the statutory conditions are met. The core case is a work prepared by an employee within the scope of employment, so the facts of the particular app carry the weight. An internal tool a developer was assigned to build is a strong fit. A weekend project in an unrelated field is not. Everything in between is where disputes arise.
Signed agreements
Most real answers come from the employee’s own paperwork. An invention or IP assignment clause, a confidentiality agreement, and any policy on AI tools can place ownership of work-related code with the company regardless of how it was written. Local law can limit what such clauses may claim, especially for work done outside the job. Read the actual signed documents rather than relying on a template or recollection.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallAI-platform terms are a different contract
The customer agreement for an AI app builder sits between the vendor and its customer. Replit’s enterprise terms, for example, say that as between Replit and the customer, the customer retains rights in input content and owns output content, while Replit keeps rights in its platform and AI features. They also warn that separate terms may apply to third-party services connected to an app. Two lessons follow. First, check the agreement for the specific plan and account the app was built on, since vendor terms can change and may differ by plan, region and date. Second, “the customer owns the output” does not tell you whether the customer is the employee or the company. That depends on whose account it was and what the employment documents say. An app built on an employee’s personal subscription is a custody and compliance problem even if the title analysis favors the company.
Copyrightability of AI output
“Who owns it?” and “what is protectable?” are related but distinct. The U.S. Copyright Office published Part 2 of its AI report, on the copyrightability of generative-AI outputs, on January 29, 2025. The practical consequence for a company is that an assignment clause can transfer whatever rights exist but cannot create rights that the law does not recognize in unmodified generated material. Human-authored code, substantive edits, architecture and documentation are easier to describe as authored work. Keep repository history and review records, since they show where humans made choices. The Copyright Office has said its August 2023 notice of inquiry drew over 10,000 comments by December 2023. That figure describes the consultation and says nothing about how common vibe coding or employee disputes are.
One contract model: GitHub’s Balanced Employee IP Agreement
Companies without a clear policy can look at published models. GitHub’s Balanced Employee IP Agreement is a reusable example, and its authors state that contributors are not lawyers and that it is not legal advice. It is not law and not a default rule. It does show how the problem can be divided into three cases:
| Case | Allocation in GitHub’s model |
|---|---|
| IP created within the scope of the job | Exclusive company control |
| Work unrelated to the company, created outside the job | Employee control |
| Certain outside work related to the company’s business | Employee ownership, with a non-exclusive, unlimited license to the company |
The model matters for vibe coding because AI builders have made side projects and internal tools easy to start in the same afternoon, often on the same laptop. A policy that spells out these three categories, and what happens to each at departure, removes most of the ambiguity. When comparing any such approach, look at clarity, enforceability where your employees live, the scope of the company’s license, the treatment of side projects, and whether it connects to a continuity and security plan.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Who should own it operationally
Regardless of how title resolves, the company should be the custodian. The practical standard:
Best Value
- A business owner who is accountable for the app’s purpose, users and risk, and who is not the departing person.
- A technical successor who can maintain and deploy it.
- Organization-controlled accounts for the repository, deployment, domain, cloud resources, billing, secrets and business data, with more than one authorized administrator.
This follows the shape of Cloud Security Alliance guidance, which calls for role reassignment and knowledge transfer on a role change or termination, and Microsoft’s recommendation to use identity lifecycle workflows for employee departures. The specific account inventory below is practical synthesis built on those principles, not a requirement quoted from either source.
If an app has no willing owner, that is itself a decision point: retire it, or accept it formally. Leaving an orphaned app running because nobody wants to touch it is the worst outcome, since it keeps handling data with nobody accountable.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Handover and offboarding checklist
Where possible, do steps 1 to 4 while the employee is still available. A tested handover is far more reliable than reconstruction afterward.
Recommended Free Tools
- Name the owners. Assign an internal business owner and a technical successor. Record the app’s purpose, users, dependencies, data flows, known defects and escalation path. This mirrors the CSA’s role-reassignment and knowledge-transfer guidance.
- Move or confirm control. Check that the source repository and deployment sit under organization accounts, not an individual’s sole personal account. Confirm at least two authorized administrators, and have the successor perform a real deployment or restore while the author can still answer questions.
- Inventory everything the app touches. Identity provider, code host, AI builder, cloud, domain and DNS, CI/CD, databases, analytics, billing, and third-party integrations. Third-party services may carry their own terms, so note who is the contracting party for each.
- Capture the prompts and context. In an AI-built app, the intent behind the code often lives in prompt history, project instructions and chat logs. Export or document what the successor will need.
- Remove access promptly. Disable the departing identity and revoke or update their accounts, API keys, tokens and permissions. CSA guidance calls for this on termination or role change, and Microsoft recommends lifecycle workflows for departures. Microsoft also recommends at least one Conditional Access policy targeting all resources to establish baseline access control, which helps ensure a leaver’s identity cannot slip through a gap.
- Rotate secrets. Rotate any shared credential, and any secret the employee could have seen or that may have been pasted into a prompt, config file or repository. Check provider-hosted environments, since AI builders often store environment variables and connections in the platform itself.
- Review prompts and logs for exposure. Microsoft advises against pasting credentials or customer data into AI tools and recommends following organizational rules for proprietary code. Look for personal data, secrets or confidential material that went to an external service, and escalate to security or privacy staff if you find any.
- Review the code before keeping it in production. Examine generated changes, dependencies, permissions, tests and maintainability. AI provenance is not a reason to skip ordinary review, and authorship claims are not a substitute for it.
- Preserve title evidence. Keep assignment terms, approvals, project tickets, repository history, the tool terms in force and records of who owns each resource or account.
What not to do
- Don’t log in to a former employee’s personal accounts or devices without lawful authorization. If the app lives there, ask the employee to transfer it, and involve counsel if they refuse.
- Don’t conclude the platform owns the app, or that it transfers employee IP. The vendor terms in the example above allocate rights between vendor and customer and say the customer owns output. They do not address the employer-employee split.
- Don’t assert that a named person owns the app without the facts. Scope of work, signed terms and jurisdiction all feed the answer.
- Don’t treat a hardware security key or other MFA device as a substitute for revocation. Phishing-resistant MFA (such as FIDO2 keys, where your identity provider supports them) strengthens sign-in for current staff. It conveys no ownership and does not remove a leaver’s access.
Preventing the problem next time
- Require that AI-built apps used for company work be created in company-owned accounts and repositories.
- Register each such app with an owner and successor before it handles real users or data.
- Put the three-category question (in scope, unrelated, related outside work) in your IP agreement and your AI acceptable-use policy, with local counsel confirming enforceability.
- Tie departure workflows to the same inventory, so tokens and integrations are reviewed and not just the employee’s main login.
When to involve a lawyer
Bring in qualified counsel if the departing employee claims the app is theirs, if the app was built substantially outside normal duties or on personal resources, if the employee works outside the U.S., if the app is to be sold or licensed, or if it relies on third-party terms you have not read. Hand over the signed agreements, job descriptions, repository history and the platform terms that applied at the time. The legal rules here differ by jurisdiction and contract, and this article is general information, not legal advice.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
