Forward-Deployed Engineering06
Nothing leaves your perimeter:not a record, not a prompt,and every action is logged.
We deploy the system inside the boundary your regulator and your security team already accept, with egress blocked at the network edge and every action attributed in your log store. Scoped per environment.
- 10:42 · egress attempt · blocked · telemetry
- 10:43 · egress attempt · blocked · prompts
- 10:47 · egress attempt · blocked · records
- Environments
- Your cloud, your premises, air-gapped
- Egress
- Zero, blocked at the edge
- Audit
- Every action, attributed, in your log store
- Our access after handover
- None
FDE / 01Three environments
Your cloud, your premises, no network.
Three places the system can run. The rules are the same in each; what changes is what has to be carried in.
Your cloud
Your account, your region, your identity provider. Models reached through private endpoints inside the provider's network, or self-hosted in your account. Egress blocked at the network edge; logs in your log store.
Your premises
Your hardware, your network, your operations team. Open-weight models self-hosted on your GPUs; the gateway, the vector store and the audit log on machines you own. Updates arrive through the path your change control already uses.
No network
An air-gapped enclave. Models, weights, dependencies and updates carried in on approved media; nothing carried out. The audit log is the only record that leaves, and only by your procedure.
The same rules in each
Zero data egress, enforced at the edge and tested; every action attributed to a person; secrets in your vault; no standing access for us after handover. The environment changes; the rules do not.
FDE / 02Compared
Three environments, compared.
Each is the right call for a different constraint. The table says what each gives and what it costs, so the choice is made on the row that matters to you.
| Criterion | Your cloud | On-premises | Air-gapped |
|---|---|---|---|
| Zero data egress | yes | yes | yes |
| Every action in your audit log | yes | yes | yes |
| Provider models through private endpoints | yes | no | no |
| Open-weight models self-hosted | yes | yes | yes |
| Updates arrive over the network | yes | yes | no |
| Runs on hardware you already own | no | yes | yes |
| Starts within weeks | yes | partial | no |
FDE / 03What you keep
6 ITEMS
The security manifest.
Six things your security team signs before real records enter the system.
- The egress policy
What may leave the perimeter, which is nothing but the audit log, written down, enforced at the network edge, with the test that proves it.
- Identity and access
The system acts through your identity provider as the person it works for; each role, scope and revocation path documented.
- The audit trail
Every model call, retrieval and write attributed, timestamped and stored in your log store, with the retention you set.
- The secrets
Credentials and keys in your vault, rotated by a procedure in the runbook, never in code or configuration.
- The model gateway
One path to any model, inside the perimeter, that logs each call, strips what must not be sent and blocks what must not leave.
- The threat model and review
The threat model, your security team's findings, how each was closed, and the sign-off, dated.
FDE / 04Specified
10 FIELDS
Deployment, specified.
The terms as they stand before the first call. The environment moves the detail; it does not move the rules.
- Scope
- Per environment; scoped after a read of your security policy and your network
- Start
- A scoping call with your security lead in the room, then a written environment plan
- Engineer
- One named senior engineer who has run production systems inside regulated perimeters; your security team reviews every step
- Models
- Provider models through private endpoints where your policy allows; open-weight models self-hosted where it does not
- Egress
- Blocked at the network edge; tested by attempting it and recording the block
- Identity
- Your identity provider; the system acts as the person it works for
- Audit
- Every action attributed and logged to your log store, retained as your policy sets
- Secrets
- In your vault; rotation in the runbook; no credential in code
- Our access
- Scoped for the engagement, through your identity provider, revoked at handover
- Evidence
- The manifest, the egress test, the review record and an audit sample, in a form your auditor can read
FDE / 05Fit
Whether to call us
Call us when
- A regulator, a customer contract or your own policy forbids data leaving your perimeter
- Your security team has blocked a pilot for want of a review it can sign
- The system must run on premises or without a network
- You need an audit trail an auditor can read, not a vendor's dashboard
- You want provider models, but only through a path inside your network
Do not call us when
- Your policy permits a standard cloud deployment; the environment is then part of the build, not a separate engagement
- The workflow has not been chosen or scoped yet
- There is no security team or owner to review and sign
- The hardware for an on-premises deployment does not exist and has no budget
- You need a certification for the organisation rather than a system deployed inside it
FDE / 06Proof
2 ROWS
Case studies
Illustrative engagements written end to end, chapter by chapter.
FDE / 07Questions
6 QUESTIONS
Asked about the perimeter.
What does zero egress mean in practice?
No record, prompt, embedding or telemetry leaves the boundary. The block is enforced at the network edge, not by a setting in code, and it is tested by attempting egress and recording the block. The audit log is the only thing that leaves, and only by your procedure.
Can we still use models from the large providers?
Inside your cloud, yes, where your policy allows: through the provider's private endpoints, with the gateway logging every call and stripping what must not be sent. On premises or air-gapped, models are open-weight and self-hosted on your hardware.
How does an air-gapped deployment get updates?
Through the procedure you already use for approved media. Weights, dependencies and code are packaged, signed and carried in; the runbook describes the steps and your team performs them. Nothing is carried out except the audit log.
Who reviews the security work?
Your security team, at each step, and they sign the manifest before real records enter the system. We write the threat model and close the findings; the sign-off is theirs.
What access do you hold?
Scoped access for the engagement, through your identity provider, visible in your audit log like anyone else's. It is revoked at handover, and the manifest records the revocation.
How does this fit with connecting our systems?
Integration & Data Onboarding scopes the connectors and the data model; this engagement scopes the perimeter they run inside. The two are usually run together, and Managed Operations can keep the environment running afterwards.
FDE / ENDStart
Inside your perimeter,with an audit trail to show for it.
Book a scoping call with your security lead in the room; you leave knowing which environment fits and what it takes.