How to protect source code and intellectual property when outsourcing

Establish the rights chain

With qualified counsel, distinguish background IP from work created for the project. Define ownership or license rights for code, designs, documentation, prompts, data transformations, test fixtures, evaluation sets, fine-tuned artifacts, and deployment configuration. Ensure employees and subcontractors are bound by terms compatible with the vendor’s promise to you.

Inventory third-party and open-source components. Record their licenses, versions, sources, and obligations. An assignment clause cannot transfer rights the provider never owned.

Keep operational control

Create repositories, cloud accounts, package registries, domains, signing keys, and production environments inside buyer-controlled organizations. Grant individual, least-privilege access with multi-factor authentication. Avoid shared accounts. Protect branches, require review, scan dependencies and secrets, and back up critical assets outside the vendor’s sole control.

Limit information by need

Provide the smallest production and customer-data access the work requires. Use synthetic or minimized data for development when feasible. Label confidential materials, restrict downloads, log administrative activity, and document approved tools—including AI coding or transcription services that may receive project content.

Make handover continuous

Require architecture decisions, setup instructions, dependency records, tests, runbooks, and deployment procedures as deliverables throughout the project. Periodically ask a person outside the provider team to build or operate the system from those materials.

At offboarding, revoke identities and tokens, rotate shared secrets, transfer accounts and work in progress, obtain required deletion evidence, and preserve relevant audit logs. Use the contract checklist to align these controls with the agreement.

Inventory what must be protected

Source code is only one asset. Create an inventory before access begins:

• repositories, branches, issues, review history, and release artifacts;
• architecture decisions, documentation, runbooks, and test suites;
• domains, cloud accounts, package registries, signing systems, and analytics;
• product designs, research, roadmaps, and trade secrets;
• customer, employee, operational, and evaluation data;
• prompts, retrieval collections, labeled examples, fine-tuning inputs, and model configurations;
• third-party libraries, datasets, models, fonts, images, and licenses;
• credentials, encryption keys, certificates, and recovery methods.

For each asset, name the owner, source of rights, approved location, authorized roles, backup, retention, and offboarding action. This turns “protect IP” into observable responsibilities.

Establish a complete rights chain

The supplier agreement should match the agreements with employees, contractors, and subcontractors who create the work. With counsel, verify that each contributor can grant the rights promised and that pre-existing materials remain clearly identified.

Separate:

1. Buyer materials: assets the buyer already owns or licenses.
2. Supplier background materials: reusable tools or methods brought to the project.
3. Project deliverables: work created for the engagement.
4. Third-party materials: open-source or commercial components neither party owns.
5. Operational data and feedback: records created while the system runs.

Define ownership or license scope, territory, duration, transfer, modification, sublicensing, source access, and payment conditions where relevant. Do not assume a payment invoice transfers rights automatically.

Govern open-source and third-party dependencies

Require a dependency record with component, version, source, license, purpose, modification, distribution method, and material obligations. Approve components according to the way the product will be used and distributed.

Automated scanning can identify known packages and licenses but does not replace review of copied code, model output, datasets, fonts, media, or incompatible obligations. Preserve provenance for important assets and resolve uncertainty before release.

Use buyer-controlled technical foundations

Create durable accounts inside buyer-controlled organizations and grant the provider individual scoped access. Protect branches, require review, use signed or attributable commits where appropriate, separate environments, and prevent production secrets from entering code or chat.

Restrict administrative access and log consequential changes. Back up critical repositories and configuration outside the provider’s sole control. Confirm that recovery methods and billing belong to the buyer, not a departing consultant’s personal account.

Control AI-assisted development

Document which coding assistants, model services, transcription tools, or other AI systems may receive project material. Review account settings, retention, training use, data location, access, and contract terms appropriate to the content.

Define what contributors may submit, what generated output must be reviewed, and how provenance or licensing concerns are handled. Do not place secrets, personal data, customer code, or protected materials into an unapproved service. AI output should receive the same review, testing, security, and dependency scrutiny as human-written work.

Limit access by task and environment

Use synthetic or minimized data for development where feasible. Grant only the repository, system, and environment access required for the assigned work. Use time-bounded elevation for unusual administrative tasks and remove dormant identities.

Keep an access ledger that connects each identity to a person, company, purpose, approver, systems, and expiration. Shared credentials destroy attribution and complicate offboarding.

Make review and provenance visible

Require pull requests or an equivalent review process for material changes. Preserve the requirement, decision, author, reviewer, test evidence, and release that connect a change to production. Protect the review process from the same supplier concentration when risk warrants independent oversight.

For generated artifacts, data transformations, or model behavior, preserve inputs, versions, evaluation evidence, and approved configuration needed to reproduce the result within practical limits.

Test continuity during delivery

Ask someone outside the primary supplier team to perform a controlled continuity exercise: clone and build the project, provision an environment, run the tests, release to a non-production target, restore a backup, or follow an incident runbook. Choose an exercise proportional to risk.

Record gaps and fix them as delivery work. A document that has never been used is an assertion, not handover evidence.

Run a complete offboarding

1. Freeze or transfer work in progress and preserve the relevant record.
2. Inventory code, artifacts, documentation, data, accounts, licenses, equipment, and open risks.
3. Transfer ownership and recovery methods for durable services.
4. Revoke identities, tokens, sessions, applications, and delegated access.
5. Rotate secrets that may have been shared or exposed.
6. Return or delete data and obtain required evidence.
7. Verify builds, environments, backups, and operational access.
8. Complete knowledge transfer and record unresolved limitations.
9. Preserve audit and contractual records for the appropriate period.

Do not delete evidence needed for an incident, dispute, legal hold, or required record. Coordinate offboarding across technical, legal, security, privacy, finance, and people owners as applicable.

Build a jurisdiction and contributor rights schedule

Do not rely on one global sentence when people, companies, and work cross jurisdictions. With qualified counsel, list every contributing entity and person, their relationship, work location, contracting path, relevant agreement, background materials, project deliverables, and the rights or licenses required for the buyer’s intended use.

The schedule should answer:

• who created or supplied each material asset;
• whether the contributor was an employee, contractor, subcontractor, licensor, customer, or other source;
• which agreement and governing terms apply;
• what pre-existing material is embedded and how it may be used;
• whether assignment, license, moral-rights treatment, attribution, consent, or further documentation is required;
• whether payment, acceptance, or another condition affects transfer;
• which restrictions survive termination;
• who owns enforcement and can provide supporting evidence.

This is not a substitute for legal analysis. It makes the facts reviewable before a product is distributed, financed, sold, or transferred. Update it when the team, scope, toolchain, dataset, model, or delivery country changes.

Protect trade secrets through actual secrecy controls

Calling everything confidential can make controls less usable. Classify the information that derives value from secrecy, identify who needs it, and show how access, disclosure, copying, storage, discussion, return, and destruction are controlled. WIPO’s trade-secret material emphasizes that protection depends on secrecy and reasonable steps, not a label alone.

Use scoped repositories and data rooms, individual access, multi-factor authentication, download restrictions where proportionate, visible markings, approved communication tools, recipient and purpose records, and prompt revocation. Avoid copying architecture, credentials, customer records, roadmaps, or proprietary datasets into personal accounts, unmanaged devices, public issue trackers, or unapproved AI services.

At meetings and handoffs, disclose only what the decision requires. Record particularly sensitive disclosures and the receiving entity. When a provider needs production-like context, use minimized, synthetic, redacted, or isolated material where it can still support the work.

Periodically review access against current assignments. An agreement signed years ago does not justify continued access after a person moves to another project.

Create a release provenance passport

Bind each material release to the exact source and evidence from which it was produced. The passport can be lightweight, but should connect:

• repository and immutable source identifier;
• authors and reviewers;
• requirement or decision record;
• build process and environment;
• dependency and license inventory;
• generated-code or model-assisted contribution review where relevant;
• tests, security checks, exceptions, and accepted limitations;
• artifacts, signatures or checksums where used;
• deployment owner, destination, and time;
• rollback point and supporting runbook.

For models or data products, add dataset origin and permission, transformation lineage, model and configuration version, evaluation set, results, human approval, and monitoring boundary. For designs or media, add editable source, font, stock, icon, image, and other license records.

The passport does not prove ownership by itself. It lets legal, technical, security, and transaction reviewers trace what needs proof instead of rebuilding the history from chat and invoices.

Respond to suspected misuse without destroying evidence

Define the response before a conflict. If source, credentials, data, or confidential material may have been exposed or used outside authority, preserve relevant logs and records, restrict access proportionately, rotate affected secrets, identify copies and recipients, and involve the appropriate legal, security, privacy, people, and business owners.

Do not immediately delete every account or device if doing so would destroy evidence or interrupt a critical service without a recovery plan. Do not make public accusations from an incomplete technical signal. Separate containment, investigation, contractual communication, legal decisions, customer or regulator notice, and service recovery.

Require providers to notify the buyer promptly with facts about the material, people, systems, time, actions, copies, downstream recipients, containment, and next update. The buyer should retain authority over its legal positions and external communications.

After closure, update the rights schedule, access model, monitoring, training, contract, or technical design that allowed the uncertainty. A response that retrieves one copy but leaves the same uncontrolled path open is incomplete.

Verify the exit rather than accepting a certificate alone

A return-or-destruction statement is one piece of evidence. Reconcile repositories, forks, local clones, build systems, artifacts, package registries, cloud storage, tickets, backups, collaboration tools, model services, support systems, devices, and subprocessors according to the actual agreement and applicable retention duties.

Record what was returned, transferred, retained, deleted, or preserved; by whom; from which system; under which authority; on what date; and with what verification. Distinguish buyer data from provider records the provider is required or entitled to retain. Restrict retained material and name its final disposition trigger.

Test the buyer’s received package: build it, inspect licenses, restore configuration, access the accounts, exercise a recovery path, and have a qualified replacement perform the next change. An archive that cannot be used is weak continuity evidence even if it is complete in bytes.

Frequently asked questions

Does paying for code mean we own it?

Not necessarily. Rights depend on applicable law, agreements, contributor relationships, and third-party material. Use qualified counsel and a clear rights chain.

Should the vendor host the repository?

The buyer should usually control the durable repository for buyer-owned work. A vendor may operate in it through scoped access. If another model is necessary, preserve continuous access, export, backup, and transition rights.

Can open-source software be used in proprietary work?

Often, subject to each license and the way the component is used or distributed. Inventory dependencies and review obligations; “open source” is not one license.

How do we protect prompts and evaluation data?

Treat them as inventoried assets. Define rights, access, permitted services, retention, versioning, backup, and handover just as you would for code or product data.

Is a deletion certificate enough at exit?

It can be one piece of evidence. Also revoke access, rotate secrets, transfer accounts, verify returned assets, inspect logs where appropriate, and follow any legal retention or hold requirements.

Can an NDA protect source code by itself?

No. Confidentiality terms can support protection, but the buyer also needs a complete rights chain, appropriate access controls, provenance, review, buyer-controlled custody, backups, and a tested exit. The actual facts and applicable law determine the result.

Who should approve an AI coding assistant?

The buyer should assign technical, security, privacy, legal, and data owners proportionate to the material the service may receive and the product’s risk. Approval should bind the exact service, account, settings, data boundary, use, review method, and change triggers—not the generic category “AI.”