Who Owns the Code When AI Agents Work on Your Store Through an Agency?
When AI agents work on your store through an agency, the code is usually owned by whoever the contract says owns it, and the repository belongs to whoever holds the admin account. Agent-drafted changes don't change that. Put repo ownership, IP assignment, merge approval and the audit trail in writing before any agent opens a pull request.
The question comes up more often now because agencies are adding AI agents to client work, and many agencies still hold the repository on behalf of the store. That arrangement worked when only agency developers wrote code. When an AI agent starts drafting pull requests too, the merchant and the agency both need to know who owns what, who can approve it, and what happens to the history if the relationship changes.
- The contract decides who owns the code. AI-drafted changes are work product like any other.
- Whoever holds the repository admin account controls access, so the merchant should own the org or workspace.
- Name who reviews, who approves and who merges agent-drafted pull requests, and enforce it with branch protection.
- Keep the audit trail in systems the merchant controls so it survives a change of agency.
- Check IP and licensing wording with your own counsel. This article is not legal advice.
Who owns the code an AI agent writes for an agency client?
The contract between the merchant and the agency decides who owns the code, and an AI agent drafting part of it does not change that. Most agency agreements assign work product to the merchant once invoices are paid. Agent-drafted changes are work product produced under that agreement, so they normally follow the same clause.
The gap is that many agreements were written before AI-assisted work was common and say nothing about it. A short added line that names AI-assisted and agent-drafted changes as work product removes the ambiguity. Ownership and licensing law varies by jurisdiction, so a merchant should have its own counsel review the wording rather than relying on a template.
Why does owning the repository matter more than owning the code?
Owning the repository matters because the admin account controls access. Whoever holds the GitHub organization or Bitbucket workspace decides who can read the code, who can open pull requests, who can merge, and who gets removed. Contract ownership of the code is hard to exercise if the merchant cannot reach the repository that holds it.
The safest default is that the merchant owns the organization or workspace and invites the agency as a member with the access it needs. When an agency hosts the repository today, the merchant and agency can agree on a transfer or a mirror and set a date for it. The setup steps for connecting agents in that situation are covered in how to connect AI agents to GitHub when you don't own the repo; this article is about the ownership and governance decisions behind it.
Who should review and approve what an AI agent drafts?
A named person should review and approve every agent-drafted pull request before it merges. In an agency setup, that usually means an agency developer reviews the code and tests it on a preview, and a merchant approver signs off on changes that affect checkout, pricing, tracking or accessibility. Branch protection rules on the default branch can require that review, so nothing merges without it.
Noibu's Bug Resolution agent is built for this kind of review. It identifies top fixable issues, traces the root cause to the codebase and creates a pull request for a person to review. Nothing ships without approval, so the repository owner and the reviewers the merchant names keep control of what goes live. See how the Bug Resolution agent works.
What should an agency agreement say about AI-assisted work?
An agency agreement that covers AI-assisted work should answer the questions in the checklist below in plain language. The checklist is the part worth copying into a statement of work, because each row names the decision, what a healthy answer looks like and where the answer should be recorded.
| Question to settle | What good looks like | Where it lives |
|---|---|---|
| Who owns the repository? | The merchant owns the GitHub organization or Bitbucket workspace; the agency is a member with scoped access | Repository settings |
| Who owns the work product? | IP assignment to the merchant on payment, with AI-assisted work named explicitly | Master services agreement or SOW |
| Who reviews agent-drafted code? | A named agency developer, with required review enforced by branch protection | Branch protection rules |
| Who approves risky changes? | A named merchant approver for checkout, pricing, tracking and accessibility changes | SOW plus pull request template |
| Who can merge and deploy? | A short list of people, never a shared login, and never the agent itself | Repository roles and deploy settings |
| What happens if the agency relationship ends? | Access is revoked the same day; history, tickets and secrets stay with the merchant | Offboarding clause and access log |
The offboarding row is the one teams skip most often. If the agency relationship ends, the merchant should be able to revoke access the same day and keep the full pull request history, linked tickets and any deployment secrets. Writing that down while the relationship is healthy is much easier than negotiating it later.
What should the audit trail show for agent-drafted changes?
The audit trail for an agent-drafted change should show which issue it addressed, who or what drafted it, who reviewed it, who approved the merge and when it went live. Pull request history, a linked ticket and deploy logs together cover all five. A pull request template with fields for the issue, the reviewer and the merchant approver makes the record consistent across the team.
Keeping that record in systems the merchant controls is what makes it durable. When a merchant changes agencies or brings work in-house, the history of why each change was made stays with the store. For the merchant's side of the trust question, should you worry if your ecommerce agency uses AI? covers review, approval and preview before merge.
How does this fit an AI-native agency model?
Clear ownership is what lets an agency use AI agents without making the client nervous. In the model described in what is an AI-native ecommerce agency?, the agents find and draft, the agency reviews and ships, and the merchant approves. Each of those roles maps to a row in the checklist above, which is why settling ownership early speeds up the work rather than slowing it down.
For a merchant giving any AI agent access to a codebase for the first time, how to give an AI agent access to your codebase without losing control covers scoped permissions and review settings in more detail.
Frequently asked questions
Does code written by an AI agent belong to the merchant or the agency?
Ownership follows the contract, not the tool. Most agency agreements assign work product to the merchant once invoices are paid, and agent-drafted changes are work product like any other. If the agreement is silent on AI-assisted work, add a line that covers it, and confirm the wording with your own counsel.
Should the agency or the merchant own the GitHub or Bitbucket repository?
The safest default is that the merchant owns the organization or workspace that holds the repository and grants the agency access to it. If the agency hosts the repo today, agree on a transfer or mirroring plan and a date. Holding the admin account is what decides who can grant or revoke access later.
Who should approve and merge pull requests that an AI agent drafts?
A named person should approve every agent-drafted pull request before it merges. In an agency setup that is usually an agency developer who reviews the code plus a merchant approver for changes that affect checkout, pricing or tracking. Branch protection rules can enforce the review so nothing merges without it.
Does Noibu push code straight to my live store?
No. Noibu's Bug Resolution agent identifies top fixable issues, traces the root cause to your codebase and creates a pull request for you to review. Nothing ships without your approval, so the repository owner and the reviewers you set keep control of what merges.
What should an audit trail show for AI-assisted changes?
Each change should show which issue it addressed, who or what drafted it, who reviewed it, who approved the merge and when it went live. Pull request history, linked tickets and deploy logs together cover this. Keep the record in a system the merchant controls so it survives a change of agency.
Is this legal advice?
No. This article explains common ownership and governance practices for ecommerce teams working with agencies. Contract terms such as IP assignment, licensing and liability depend on your jurisdiction and your agreement, so review them with qualified counsel before you sign or change anything.
The short version
The contract decides who owns the code, the repository admin decides who controls it, and named reviewers decide what merges. Settle all three in writing, enforce review with branch protection, and keep the audit trail where the merchant can reach it. An agency that runs Noibu's agents this way gets agent-drafted pull requests its developers review and its clients approve. To see what the agents would find on a store first, start with the free website audit.
Noibu is AI for ecommerce operations, the always-on optimization system that keeps online stores running at their best. A team of supervised AI agents finds what's broken, slow, or leaking revenue, does the work, and hands results back for human approval. Trusted by retailers like Free People, Guess, Liquid I.V., and Ariat.
