Direct answer
The decision in brief
Secure forward deployment begins with client authority. The client approves environments, identities, data boundaries, model providers, tool permissions, release decisions, and risk acceptance. The engineering team receives only the access required for the agreed outcome, makes model and integration behavior observable, keeps delivered code and business artifacts client-owned, and removes temporary access at closeout. Security is an operating boundary throughout delivery, not a review added after the prototype.
Who this is for: Engineering, security, legal, data, and procurement leaders evaluating whether an embedded AI team can work safely inside company systems.
Decision framework
Client authority across the deployment boundary
The exact controls depend on the client and risk classification. This model establishes who must decide each boundary before access expands.
| Boundary | Client decision | Engineering evidence |
|---|---|---|
| Identity | Who may access what and for how long | Named, least-privileged, revocable access |
| Data | Permitted sources, uses, retention, and locations | Documented flows and handling controls |
| Models | Approved providers and processing terms | Disclosed provider, configuration, and limitations |
| Tools | Allowed actions and approval requirements | Scoped credentials, audit events, and human gates |
| Release | Who accepts risk and authorizes production | Evaluation, review, rollback, and sign-off evidence |
| Closeout | What remains and what is revoked | Transferred artifacts and access-removal record |
Deployment sequence
A controlled path from decision to evidence
- 01
Classify the workflow
Identify sensitive information, consequential actions, regulated boundaries, and the people authorized to accept risk.
- 02
Approve the architecture
Document environments, data paths, models, subprocessors, identities, integrations, retention, and logs.
- 03
Provision minimum access
Use named, time-bounded, least-privileged access and client-managed secrets wherever practical.
- 04
Build observable controls
Record relevant inputs, model and tool decisions, approvals, failures, and escalation without exposing protected data unnecessarily.
- 05
Verify before release
Review evaluation, security findings, known limitations, rollback, and ownership with the client release authority.
- 06
Close deliberately
Transfer approved artifacts, revoke temporary access, resolve retained data, and record remaining responsibilities.
Authority and ownership
Responsibilities must remain explicit
The client owns
- — Set security, privacy, legal, procurement, and risk requirements
- — Control identities, secrets, production access, and release approval
- — Approve providers, subprocessors, retention, and data use
Ten Mile Zone owns
- — Follow the approved boundary and disclose material dependencies
- — Build reviewable controls and report limitations or incidents
- — Deliver client-owned artifacts and complete access closeout
Common failure modes
Where otherwise credible programs break down
Shared or permanent credentials
Access cannot be attributed, constrained, or cleanly revoked when identities are shared or indefinite.
Undisclosed model data path
A team approves the application but never resolves where prompts, files, logs, or derived data travel.
Autonomy before authority
The system gains permission to act before evaluation, human review, and escalation boundaries are accepted.
Closeout by assumption
Repositories transfer while temporary accounts, copied data, tokens, or vendor access remain unresolved.
Fit boundary
When forward-deployed engineering is the wrong choice
- The buyer cannot identify a release or risk-acceptance authority
- Required data cannot be used lawfully or under approved terms
- The engagement requires access outside the agreed client boundary
- The requested assurance depends on a certification or control the parties do not possess
- The system cannot provide a safe human or deterministic fallback for material decisions
Client participation
Who must participate
- Security and identity owner
- Data owner or privacy representative
- Business workflow owner
- Engineering and architecture owner
- Legal or procurement owner where contractual controls are required
- Production release authority
Acceptance evidence
What proves the engagement worked
- Approved architecture and data-flow record
- Named identities and scoped permissions
- Model, tool, and subprocessor inventory
- Evaluation and human-authority rules
- Release and rollback approval
- Transferred artifacts and access-revocation record
Buyer checklist
Questions to resolve before proceeding
- Who owns each source of data?
- Which providers receive or retain information?
- Are credentials client-controlled and individually attributable?
- Which actions require a human decision?
- What information is logged and who may inspect it?
- How are incidents, provider failures, and unsafe outputs handled?
- What is deleted, transferred, or revoked at closeout?