Security and access for embedded engineers

The security conversation about embedded engineering usually happens too late, in a rush, with a security team that was not consulted during procurement. Here is the version to have early.

The four rules

Least privilege by default. Grant what the work needs and nothing adjacent. This sounds obvious and the pressure runs the other way, because broad access removes friction and friction is visible while risk is not.

Repository access scoped to named repositories. Not organization-wide. Organization-wide gets used because it is one click and per-repository access is a conversation. Have the conversation: an embedded engagement often involves people you have not met, at a company you are still evaluating.

Grant to named individuals rather than a shared account, so the audit trail means something, and review the access list at a stated interval rather than at the end.

Production access as a named exception. Default to none. Where the work genuinely requires it, four properties: named individuals, a written reason, an audit trail of what was accessed, and an end date.

Revocation on the handover date. A contract term rather than a courtesy, and verified rather than assumed. Check the access list after the date. This is the step that gets skipped most often, because by then everybody has moved on and the vendor relationship was good.

What changes when a model writes the code

Most vendors in this market now generate code with a model. That does not make the arrangement less safe, and it moves where the safety comes from.

Generated code is not secure by default. The volume of change also rises, which means a review process that depended on a person reading every diff carefully stops working: attention does not scale with generation volume.

So the gate has to be mechanical. Checks derived from the specification, written before the code exists, and graded by something other than the model that produced the code. That is eval-driven development, and inside somebody else's production environment it is the difference between speed and liability.

What to ask a vendor. What share of delivered code is model-generated, what proves it correct, and who grades it. A vendor whose answer is that senior engineers review everything is describing a process that will not hold at volume.

The agent permission pattern worth copying

If a vendor runs agents inside your environment, and increasingly they will, there is a documented pattern worth insisting on.

Palantir's AI FDE documentation states that all operations respect existing user permissions, and that context starts minimal and expands as the user chooses, with complete authority and visibility over what the model can access.

The principle: an agent inherits the permissions of the person directing it rather than running on a broad service account. A service account with wide access is how a helpful agent becomes a breach, and it is the default configuration in most quick integrations because it is easier.

Ask: does any agent operating in our environment run under a named user's permissions or a service account, and what is that account's scope?

The paperwork that has to precede the access

Three clauses, covered fully on the contract page.

IP assignment, vesting on creation. An NDA covers secrecy and does not assign ownership of what the vendor creates. Two separate clauses, and you need both.

Subcontractor binding. Your agreement with a vendor does not bind a third party unless the vendor is required to flow the terms down. Ask who writes the code, by team and location, and who employs them.

Data handling, stated explicitly. What data leaves your environment, where it goes, and whether your data or code is used to train anything. Ask directly rather than relying on a general confidentiality clause.

What to do about regulated data

If the work touches regulated data, the constraint shapes the engagement rather than sitting beside it.

Decide early whether the data can leave. In many cases it cannot, which means the work happens inside your environment on your infrastructure, and that changes tooling, timelines and sometimes the vendor.

Agree the substitute if it cannot. Synthetic data, a masked subset, or a controlled environment. Agree it on day one, because discovering in week three that the substitute does not represent the real shape of the data wastes the weeks in between.

Involve your security and compliance people during procurement, not after. The most common cause of a production date slipping is a review nobody scheduled. Our compliance guides cover the sector-specific version: financial, healthcare, insurance and legal.

The pre-start checklist

Access list drafted and scoped to named repositories and named individuals. Production access decided, with an exception process if needed. IP assignment and subcontractor terms signed. Data handling agreed in writing, including training use. Agent permission model confirmed. Revocation date in the contract. Security review scheduled rather than assumed.

The thing not to do

Do not solve this by keeping the engineer at arm's length.

An embedded engineer without real access cannot do the job you are paying for: they will work from a description of your environment, and the description is wrong in the places that matter most. That produces a system that solves the described problem, which is the failure this whole model exists to prevent.

The answer is scoped access granted quickly, not broad access granted slowly and not narrow access defended forever. Least privilege is compatible with speed when somebody prepares the access list before day one, which is the customer-side work on this page.