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.

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 shape 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.

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.

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 gate 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 ships 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.

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 flow the terms down.

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 slips 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 carrying outcome risk.

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 space.