Watch for custody and exit risk. If the model can only run in one managed environment and the raw weights are not exportable, the organisation gains operational control but reduces portability. That trade-off should be explicit in architecture reviews, vendor risk reviews, and incident response planning.
What changes when the model cannot leave the cloud platform?
The main change is that custody shifts from an artefact you can export and rehost to a managed capability you can operate but not freely relocate. That gives the platform provider more leverage over runtime, packaging, and lifecycle decisions. Security teams should treat that as an architecture constraint, not just a deployment preference, because it affects portability, evidence collection, and recovery options.
One practical way to read the situation is that the organisation owns the model outcome, but not necessarily the full model asset lifecycle. If raw weights are not exportable, teams need to confirm what can be backed up, what can be reconstituted, and what exact service dependencies must remain available for the model to continue functioning.
Why custody and exit risk matter in platform-bound models
Custody risk appears when the platform becomes the only place the model can run, be updated, or be recovered. Exit risk appears when the organisation cannot move the model, its weights, or its surrounding configuration to another environment without material loss. That matters because a control plane outage, contract change, region restriction, or service discontinuation can become a security and resilience problem, not just an operations issue.
Teams should also separate portability from reproducibility. A model that can be retrained elsewhere is not the same as a model whose current weights, prompts, guardrails, and evaluation baseline can be preserved and redeployed intact. In practice, the more unique the managed environment, the more the organisation depends on the provider’s continuity, forensic visibility, and incident handling.
What security teams should review before accepting the trade-off
Architecture review should confirm where the model asset actually lives, who can access it, and whether configuration drift can be detected if the platform changes behavior. Vendor risk review should check contractual and operational exit terms, including export rights, recovery time expectations, and whether service logs or model metadata are available if the relationship ends.
Incident response planning should assume the platform itself may be the recovery boundary. If a model cannot be exported, responders need an alternate path for containment, rollback, or replacement, because “restore from backup” may not mean “restore the exact same model artifact.” That is especially important when the model supports regulated workflows, customer-facing decisions, or automated actions.
How to judge whether the control is helping or hiding risk
A managed platform can improve consistency, patching, and operational control, but those benefits only hold if the team can still evidence what changed, when it changed, and how to recover. If the platform abstracts away weights, versions, or deployment settings so completely that teams cannot reconstruct the model state after an incident, control has become opacity.
Watch for signs that the environment is drifting toward lock-in: no usable export path, no documented rebuild process, limited telemetry outside the provider console, and no tested exit scenario. Those are the points where portability risk turns into governance risk, because the organisation may not be able to prove continuity or defend a migration decision under pressure.
Risk and Threat Considerations
Platform-bound model custody can become a concentration risk if a single provider controls execution, storage, rollback, and incident recovery for the model. The security issue is not only dependency on uptime, but also dependency on the provider’s support for investigation, evidence retention, and exit.
Failure mechanism: The organisation accepts a managed runtime without preserving an independent way to export, rehost, or reconstruct the model, so a provider-side outage, policy change, or contractual dispute can interrupt availability and recovery.
Impact: Loss of portability can extend incident duration, increase switching cost, complicate forensics, and leave the organisation unable to maintain service continuity on its own timeline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CP-10 — System Recovery and Reconstitution | Exit risk depends on the ability to restore or reconstitute the model service after a platform disruption. |
| SA-9 — External System Services | Managed single-platform models rely on a provider boundary that must be governed contractually and operationally. | |
| Recommendation — Define and test recovery paths for model services that cannot be exported intact. Set exit, continuity, and evidence requirements for the cloud provider service. | ||
| NIST CSF 2.0 | GV.SC-01 — Cybersecurity Supply Chain Risk Management Strategy | Platform lock-in is a third-party dependency and exit-planning issue that belongs in supplier risk governance. |
| RC.RP-01 — Recovery Plan is Executed | The model must remain recoverable if the managed environment fails or becomes unavailable. | |
| Recommendation — Document supplier dependency and exit assumptions for platform-bound model services. Validate that recovery procedures work without the original managed platform. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | The model’s dependence on one cloud platform makes supplier control and continuity central to the risk. |
| Recommendation — Include portability and exit obligations in supplier security requirements. | ||
Practitioner Guidance
What to verify: Confirm whether the model weights, version history, prompts, evaluation artefacts, and deployment settings can be exported in a form that is actually reusable elsewhere. If only a managed endpoint is available, treat that as a material exit constraint, not a minor convenience issue.
Decision rule: If the model can influence production decisions and cannot be rehosted without rebuilding its behavior, require an explicit exit design, a tested fallback path, and a vendor review before approving long-term reliance.
Practitioner takeaway: The key question is not whether the platform is secure enough to use, but whether the organisation can still recover the model, the service, and the evidence if the platform is no longer available.
Related resources from NHI Mgmt Group
- How should teams evaluate a data security platform that runs inside their cloud account?
- How should security teams enforce data policies in cloud data platforms where access decisions happen inside the platform?
- What do security teams get wrong about combining governance and cloud security in one platform?
- Who is accountable for securing AI models when AI security is embedded inside a broader cloud platform?