How should an AI company govern FDE access to customer data and production?

Scope

Use this checklist for FDEs who need customer data, systems, source repositories, model endpoints, cloud accounts, or production operations. It covers the vendor-customer boundary and applies whether work is remote, embedded, or customer-hosted.

Why it happens

FDE work moves quickly and often begins before standard product interfaces exist. A customer shares a dataset through an improvised channel, grants a broad cloud role, or asks the field engineer to fix production directly. Temporary access becomes permanent because the prototype works.

AI projects add sensitive inputs, prompts, outputs, evaluation data, and model-provider boundaries. Data copied for debugging can persist in laptops, traces, chat, notebooks, caches, and support systems long after the engagement.

Diagnosis

Map data and access flows from customer source to every vendor or third-party processor. For each path, identify owner, purpose, data class, legal/contractual basis, environment, identity, operation, retention, and deletion. Compare actual access logs with the approved matrix.

Test offboarding: remove one FDE from an engagement and verify identities, local copies, secrets, shared accounts, dashboards, notebooks, caches, CI systems, and third-party access. If revocation depends on the individual remembering every copy, the lifecycle is incomplete.

Solution

Prefer customer-controlled environments and federated identity. Separate development, evaluation, staging, and production. Use named individual and workload identities; prohibit shared accounts. Issue just-in-time, short-lived roles bound to resources and operations, with customer approval for production changes.

Minimize data and create an approved path for necessary extracts. Encrypt, classify, log access, limit local persistence, and define retention/deletion. Keep prompts, outputs, and telemetry within the same data agreement.

Establish change, incident, emergency-access, and evidence procedures before launch. At handoff, transfer runbooks and authority, revoke field access, verify cleanup, and record any continuing support exception with expiry.

Artifact

Use this checklist per environment:

Control area	Required decision/evidence
Authority	Customer owner, vendor owner, contract/policy, and approval path
Identity	Named human/workload identities, MFA, federation, and no shared accounts
Scope	Exact tenant, environment, resources, operations, and network path
Lifetime	Request, issue, review, auto-expire, revoke, and emergency extension
Data	Classification, minimization, transfer, processing, provider, retention, deletion
Development	Synthetic/redacted data, repository, dependency, CI, artifact, and secret controls
Production change	Proposal digest, target version, approval, idempotency, verification, rollback
Monitoring/audit	Reads, exports, denials, changes, effects, alerts, and access to records
Incident	Customer/vendor roles, notification, containment, evidence, and recovery
Exit	Ownership transfer, credential revocation, copy deletion, proof, and exceptions

Common mistakes

• Granting broad standing access because field work is unpredictable.
• Using one account across customer, test, and production environments.
• Moving customer data into general notebooks, prompts, or telemetry.
• Treating a customer’s chat approval as durable production authorization.
• Completing handoff without verified revocation and data cleanup.