The contract for an embedded engagement

This is the checklist for the paperwork. It is not legal advice, and every item here is something to raise with whoever writes your contracts.

One: IP assignment, vesting on creation

The most common gap, and the one with the worst failure mode.

An NDA covers secrecy: what the vendor learns, they will not disclose. It does not say who owns what the vendor creates. Without a separate assignment clause, ownership of work product can be unclear, and the time you discover that is when you want to move to a different vendor or sell the company.

What to ask for: assignment of all work product to you, vesting automatically on creation rather than on payment or on a later act. Assignment on payment sounds equivalent and creates a window where a payment dispute becomes an ownership dispute.

A worked example of why the timing matters. Say a vendor delivers a working system in month three, you raise a billing dispute over a change order in month four, and the vendor stops work. If the clause assigns on payment and the disputed invoice is unpaid, the code sitting in your repository may not legally be yours yet. You now have two disputes instead of one: the billing disagreement, and whether you can keep operating your own system while it is unresolved. Assignment on creation removes the second dispute entirely. Whatever you owe or do not owe, the code is already yours.

The nuance worth negotiating honestly. A vendor who works this way has reusable components, and asking them to assign those to you exclusively is asking them to give up their platform. The workable arrangement is that you own the deliverable and anything specific to your business, and the vendor keeps ownership of pre-existing and general-purpose components while granting you a broad, perpetual, irrevocable licence to use them in the delivered system. Get the licence scope right and this is fine. Leave it vague and you have a dependency you cannot replace.

How to tell the two apart in a real contract. Ask the vendor to list, by name, which files, libraries or modules in the delivered system are pre-existing components under licence rather than newly assigned work product. A vendor who can produce that list in a sentence understands their own codebase. A vendor who says "it is all integrated, so the distinction does not apply" is telling you the licence will be argued over later, when you have the least leverage to argue it.

Two: scoped repository access

Access to the repositories the work touches, not to your organization.

This gets skipped because organization-wide access is one click and per-repository access is a conversation. The conversation is worth having: an embedded engagement often involves people you have not met, at a company you are evaluating, and least privilege is the entire defence.

What to ask for: named individuals rather than a shared account, access limited to named repositories, and a review of that list at a stated interval.

Why a shared account defeats the point of the clause. If three vendor engineers log in as one service identity, your audit log records that "the vendor" did something, not which person did it. When something goes wrong, or when you need to know who touched a file six weeks ago, a shared account gives you no answer. Named individuals cost the vendor nothing extra to set up and cost you nothing to require. There is no honest reason for a vendor to resist this.

What "the repositories the work touches" means in practice. Write the list by name at signature, not as a general description like "the relevant codebase." If the scope grows during the engagement, which it often does, add the new repository to the list at that point rather than assuming an earlier grant covers it. A list that grows by exception, in writing, is worth more than a broad grant that was never examined.

Three: production access as a named exception

Default to no production access. Where the work genuinely requires it, make it an exception with four properties: named individuals, a stated reason, an audit trail of what was accessed, and an end date.

This matters more when a model is writing the code. Generated code is not secure by default, so the review step before anything reaches production carries more weight rather than less. Worth noting how Palantir handles it for its own agent: the AI FDE documentation states that all operations respect existing user permissions and that context starts minimal and expands deliberately. Inheriting a person's permissions rather than running on a broad service account is the right pattern for humans and agents alike.

Security and access for embedded engineers covers the operational side.

Four: the production date

A date on which the defined system is running in production for real users. Not a design delivery date, not a pilot date, not a go-live target in a slide.

This is the outcome most embedded engagements should be priced against, because it is observable and neither party can reinterpret it. Outcome-based pricing covers how to write it, including the customer-side obligations that have to accompany it.

Five: the handover date and artefact

A separate, later date on which the vendor stops operating the system, plus a definition of what handover means.

Specify the artefact. A runbook covering deployment, rollback, alerts and credential rotation. A test suite the inheriting team can run. The current specification. A written list of known compromises. Access transferred and verified before the vendor's access is revoked.

Specify the test. The strongest version, and the one worth insisting on: the customer's own engineer releases a real change to production unaided, through the real release path, before the vendor leaves. Make that a milestone with money attached and it will happen.

AWS named customer self-sufficiency after the engagement as a design goal of its own programme. A vendor unwilling to put a handover date in writing has told you what they are selling. Handover and exit covers the mechanics.

Why the handover date is the clause vendors resist most. A production date is easy for a vendor to agree to, because reaching production and then continuing to be paid to operate the system is the most comfortable outcome for them. A handover date sets an end to that comfort. Watch for a vendor who negotiates hard on the production date and goes vague on the handover date: that asymmetry tells you which date they actually plan to honour.

What happens without this clause. The engagement drifts into an open-ended arrangement, billed by the month, where the vendor's accumulated knowledge of your system becomes the reason you keep paying them rather than a reason to end the contract. That is not a hypothetical failure mode. It is the default outcome of a contract that names a production date and leaves handover as "something we will figure out."

Six: subcontractor binding

If the vendor passes any of the work to another party, that party must be bound by the same confidentiality, IP assignment and access terms.

This is routine in an integrator engagement, where a custom development line may be delivered by a subcontractor or an offshore delivery centre. It is not automatic: your agreement with the vendor does not bind a third party unless the vendor is required to pass the terms on.

Ask directly: who writes the code, by team and location, who employs them, and are they bound by these terms. FDE vs systems integrator covers where this risk concentrates.

Three more worth adding

Data handling. What data leaves your environment, if any, and where it goes. For an AI engagement, whether your data or code is used to train anything, stated explicitly rather than left to a general confidentiality clause.

Personnel continuity. The named engineers, and what happens if the vendor replaces them. Continuity matters more here than in most engagements because so much of the value is accumulated context.

What happens if the date moves for a customer-side reason. The honest version is that the date moves by the delay. Agreeing that in advance is cheaper than negotiating it under pressure, and it is the term that makes a vendor comfortable taking on outcome risk.

A fourth worth naming: dispute resolution before either side reaches for a lawyer. A short, cheap first step, such as an executive-level conversation within a stated number of days, resolves most disagreements about scope or delay faster than a formal dispute process. Reserve the formal process for the disagreements that survive that first conversation.

Reading a vendor's standard agreement against this list

Most vendors arrive with their own template rather than yours, and their template was written to protect them, not you. Read it against the six clauses above in this order, because that is the order in which a gap actually costs you money.

Check the IP clause first, word by word. Look for the word "payment" or "invoice" anywhere near the word "assign." If it is there, ask for "creation" instead, and expect some resistance, since it is the clause vendors most often try to keep as written.

Check whether "access" is defined anywhere. A template that never lists specific repositories or specific individuals is a template written for a vendor who wants the flexibility to add people without asking. Flexibility for the vendor here is risk for you.

Check for a handover section at all. Its absence is the loudest signal on the page. A vendor whose standard agreement has never needed a handover clause is a vendor whose engagements have never ended, and that should change how you weigh everything else they tell you about their track record.

Redline rather than accept. Every clause above is a normal, expected negotiation in this market. A vendor who treats a redline on IP assignment or handover as an insult, rather than as Tuesday, is telling you something about how they expect the relationship to go once you have signed.

The short version

If you read one thing: an NDA is not an IP assignment, organization-wide access is not least privilege, and a production date without a handover date is a subscription. Those three sentences cover most of the damage done by contracts in this market.