ai:engineers
How embedded AI engineers work inside enterprise teams.
By Loan Laux · November 12, 2026 · 9 min read
Embedded AI engineers are outside engineers who work inside your team for a defined piece of work: in your repository, your cloud account, your ticket queue and your review process, under the rules your own staff follow. Forward-deployed engineer is another name for the role. Your organisation decides each part of the arrangement, in this order: accounts, rules, review, pairing and the exit.
None of it needs inventing: an organisation that already runs contractor onboarding, security review and leaver processes reuses them. The sections below map the arrangement onto those decisions, naming the reference texts where they help.
What embedded AI engineers do inside an enterprise team.
Day to day, the engineer looks like a team member employed elsewhere: tickets in your queue, branches in your repositories, deploys through your pipeline, the same change rules as anyone else touching production. The engineer arrives to build a defined thing, for example the first workflow of an AI adoption plan, and leaves when it runs and your team can extend it.
Choosing that first workflow decides whether the embed earns its access; our guide on how to run an AI workflow audit covers scoring candidates on frequency, time cost, error tolerance and data sensitivity before anyone is granted anything.
The access pack before the first commit.
The principle throughout is least privilege: NIST SP 800-53 Rev. 5, control AC-6, describes allowing users only the accesses they need for their assigned tasks.
A guest identity in your directory. Microsoft's Entra B2B documentation (as of November 2026) describes guests signing in with their own work identity and appearing in your directory as guest users. Cross-tenant access settings can scope access to specific users, groups and applications, and can trust the partner tenant's multifactor authentication claims; both are settings you choose.
Repository access as an outside collaborator. GitHub's documentation (as of November 2026) defines an outside collaborator as a person who is not a member of your organization but has access to one or more of its repositories, with the access level set per collaborator, and notes they cannot be added to teams. If your organization requires two-factor authentication, outside collaborators must enable it before accepting an invitation; we recommend requiring it, our opinion rather than GitHub's rule.
A non-production environment with named data classes. The engineer builds against a lower environment first, and the data classes allowed into it are written down by the data owner before the environment is granted. The table below is our recommended pack: a starting list to cut to whatever your rules allow, not something a standard requires.
| Access item | Who grants it | When it ends |
|---|---|---|
| Guest identity in your directory | Identity admin | End of the engagement |
| Repository access as outside collaborator | Repository owner | End of the engagement |
| Non-production environment | Platform owner | The handover review |
| Data classes allowed in that environment | Data owner | The exit review, or a classification change |
| Ticket queue and team channel access | Delivery lead | The final workflow ships |
| Remote network access, where needed | Security lead | The exit review |
The supplier and security rules that already apply.
If your organisation has rules for external personnel, the embed sits inside them. NIST SP 800-53 Rev. 5, control PS-7 (External Personnel Security), shows what such rules contain: establish personnel security requirements, including security roles and responsibilities, for external providers; require providers to follow the organisation's personnel security policies; document the requirements; require notification of transfers or terminations of external personnel who hold organisational credentials, badges or system privileges, within a period the organisation defines; and check that providers meet them. Its discussion names contractors and providers of system development among external providers, and puts the requirements in acquisition documents.
Dubai's government entities have this in explicit form. The Dubai Electronic Security Center's Information Security Regulation sets minimum information security controls for Dubai Government Entities, and its stated scope includes consultants, contractors and visitors who are not government employees but are engaged with those entities. It was formalized under Executive Council Resolution No. 13 of 2012, whose Article 3(a)(3) applies its system to persons and entities whose activities require access to Government Entities' information systems; Article 13 requires them to follow the entity's information security instructions, and to refrain from copying or publishing Government Information without its prior written approval. The English text is a translation and the Arabic prevails; we describe the texts as written and leave their application to your counsel.
Where the code, models and data live.
From the first commit, the arrangement keeps three things in your estate: the code in your repository and your CI, the model endpoints in your own cloud account under your own provider agreement, and the data in stores you control. None of the three sits on a vendor tenant.
Microsoft and AWS publish statements about what model providers can see when you call models through your own cloud account. For models sold by Azure in Microsoft Foundry, Microsoft's data, privacy and security page (as of November 2026) states that prompts and completions are not available to OpenAI or other providers of models sold by Azure, and are not used by them to improve their models. In Amazon Bedrock (as of November 2026), model providers have no access to the model deployment accounts, so they have no access to Bedrock logs or to customer prompts and completions.
If residency limits where processing may happen, settle the processing location before the endpoint is created.
How the work moves through your review process.
Code from the embed is accepted the way your own code is: branches and pull requests reviewed by your engineers, your CI running your tests and scans, your change board for anything production-bound. An outside engineer whose commits bypass your reviewers is a configuration mistake.
As a reference for secure development, NIST's Secure Software Development Framework (SP 800-218, final February 2022) sets out core practices, and SP 800-218A, its Community Profile for generative AI and dual-use foundation models (final July 2024), adds AI-specific ones: the profile's scope includes incorporating and integrating AI models into other software, with deployment and operation out of scope. Its practices do not distinguish between human-written and AI-generated source code, because the profile assumes all source code should be evaluated for vulnerabilities and other issues before use.
Who pairs with the engineer on your side.
Name people before the engineer arrives: one or two of your engineers pair on the work, and one owner keeps the system once the engagement ends.
Team Topologies gives the shape a name: an enabling team helps a stream-aligned team overcome obstacles and detects missing capabilities; collaboration means working together for a defined period of time, and facilitation means one team helping and mentoring another. An embedded engineer is a temporary enabling capability, and the end state is your team running and extending the workflow. The people side beyond the build team has its own guide, on AI change management for large teams.
Handover, exit and access removal.
Agree the exit criteria when you agree the work: the workflow runs in production, the runbook exists and has been used by your team without the engineer in the room, and the pairing engineers have changed the code themselves. On the day the engagement ends, the accounts close.
Microsoft's Entra documentation (as of November 2026) describes access reviews: a decision maker, or the guests themselves, re-certifies each guest's access, and you can then remove access for guests who no longer need it; guest access reviews need a Microsoft Entra ID P2 or Microsoft Entra ID Governance license. Supplier rules following SP 800-53's PS-7 have the provider notify you when the engineer who holds your credentials or privileges transfers or leaves, within the period you define. AC-2, the account management control, closes it out: notify account managers when accounts are no longer required, and align account management with termination and transfer processes.
Do it yourself, or bring us in.
Everything above is a checklist your own platform, security and engineering leads can run without outside help. What an outside engineer adds is the build itself: someone who writes the code and stays until it runs. out:grow's forward-deployed engineers embed with your team on-site or remotely, work in your codebase and the tools you already use, build software that runs in your own environment, and pair with your team so they can run and extend it after we leave.
Frequently asked questions.
Do embedded AI engineers need security screening?
That is decided by your personnel and supplier security rules, the same ones that govern your contractors. Under a control like NIST SP 800-53's PS-7, you document those requirements and include them in the engagement's acquisition documents.
Who owns the code an embedded engineer writes?
The code sits in your repository from the first commit, in your CI and your version history. Ownership itself is a contract term: put it in the agreement and have counsel review it rather than inferring it from the commits.
Can an embedded engineer work remotely?
Yes. out:grow's engineers embed on-site or remotely, working in your codebase and your tools. Your security rules may say more about where the work happens than the engagement does.
How is this different from hiring a contractor through a staffing firm?
The difference is what the engagement is built around. In out:grow's method: a defined first workflow picked with your team, pairing with your engineers throughout, and an exit once it runs and your team can extend it. Any of those can be written into a staffing contract too; the question is whether they will be.
What does our team need to provide in week one?
The access pack from the table above, one or two engineers with time budgeted to pair, a named owner for the workflow, and the first tickets in your queue. Everything else already exists in your estate.