A fine-tuned model is a deployable artefact derived from your data, and platforms disagree about what kind of object that is. On one it is a model name a credential may or may not be allowed to reference; on another it is a cloud resource with an identity policy attached. The difference decides how much of your access control survives a migration.
What you are actually protecting
Three distinct things get called “access to the fine-tune” and they need separating before you can map anything. There is the right to invoke the tuned model at inference time. There is the right to manage it — list it, create new tuning jobs from it, delete it. And there is the right to reach the training data and the job metadata, which on most platforms is a separate storage object with its own permissions and frequently the most sensitive of the three, because it is a distilled extract of whatever corpus you tuned on.
Teams generally control the first well and the third badly. A tuning file uploaded to a platform’s file store is often readable by anything holding a credential in that account, long after the job finished. Migration is a good moment to notice that, because you are about to upload it again somewhere else.
Three ways platforms scope it
At the time of writing, three scoping models cover most of what you will meet. The names are platform-specific; the shapes are not.
- Tenant-and-project scoping. The artefact belongs to an organisation and, within it, to a project. Credentials are issued against a project, so “who can call this model” is answered by “who holds a key in the project that owns it”. OpenAI’s platform is organised this way, with fine-tuned model identifiers of the form
ft:<base-model>:<org>:<suffix>:<id>, which conveniently means the owner is visible in the model string you pass in a request. - Deployment scoping. The tuned weights are not callable until you create a named deployment, and access is granted against the deployment rather than the training artefact. This is the shape on Azure OpenAI, where the deployment lives in a resource and inherits Azure role assignments. It has a real consequence: existence and invocability are separate states, so a tuned model can be present and cost nothing and be unreachable, which is a different failure mode from “model not found”.
- Resource-and-IAM scoping. The tuned model is a first-class cloud resource with an identifier, and permission is a policy binding a principal to an action on that resource. Google Cloud’s Vertex AI and AWS Bedrock custom models both work this way. Access is expressed against roles and conditions rather than against credentials, which is more expressive and much harder to hand-map from a key-based model.
Platform capabilities in this area change often — new sharing primitives, new project-level grants, new resource types. Verify the current scoping model in each platform’s own documentation before you design against it; treat the three shapes above as categories to check against, not as a current feature list.
What does not survive the translation
The interesting part of any mapping is what has no counterpart, and here there are four.
Least privilege at the model level. Under key-based scoping, a credential that can call your tuned model can usually call every other model the project can reach. If your control was “the summarisation service can only invoke the summarisation fine-tune”, that control was enforced by your own code, not by the platform, and it will still be enforced by your own code afterwards. Under IAM scoping the same statement can be genuinely enforced by policy — which is an upgrade, but only if you write the policy rather than assuming the migration produced it.
Cross-boundary sharing. Sharing a tuned artefact with another tenant, subsidiary or customer account is expressed completely differently in each shape, and in some it does not exist. A multi-tenant product that gave each customer their own fine-tune has the hardest version of this problem, because the isolation guarantee it sells is implemented in whichever primitive it moved away from.
The audit trail. Who invoked the tuned model, from which credential, when. Under IAM scoping this tends to land in the cloud provider’s audit log; under key scoping it is whatever usage reporting the platform offers, keyed by credential. The two produce different fields at different granularity, so any dashboard or alert built on the old shape has to be rebuilt rather than repointed — which is the same problem, with different stakes, as reconciling usage records across the switch.
Deletion and retention. Deleting a tuned model does not necessarily delete the training file, the job record, or checkpoints. If your retention commitment says derived artefacts are destroyed within a stated window, that commitment now has to be satisfied by a different set of delete operations, and you should enumerate them on both sides before cutover rather than after.
Rebuilding the access story
Write down the current state as a matrix before touching the new platform: for each principal — service, team, individual, CI job — which of invoke, manage and read-training-data they hold today, and through what mechanism. Then express the same matrix in the target platform’s primitives, and mark every cell you cannot express. Those cells are the design work. Usually the answer for an inexpressible cell is an enforcement point of your own in front of the provider, which is where teams end up building a small internal gateway whether they meant to or not.
If invoke permission has to be narrower than the credential the provider issues, the enforcement point has to sit somewhere you control. That is one of the things a gateway is for: one upstream key per provider, per-service keys downstream, and a policy that says which service may reference which model string — including a tuned one. Multigrid does that centrally so the rule is not reimplemented, slightly differently, in each service that happens to call the model.
Evidence your auditor already has
The last step is the one that gets skipped. Access review evidence from the previous quarter describes principals and grants that no longer exist. Your offboarding runbook revokes a key in a console that is no longer authoritative. Any control statement that names the old platform’s vocabulary — projects, deployments, roles — is now inaccurate, and inaccurate control descriptions are found by auditors reliably.
Re-run the access review immediately after cutover rather than at the next scheduled date, and keep the old platform’s grants in the register, marked as revoked with a date, instead of deleting the rows. The register needs to show that access ended, not that it never existed, and that record is also what tells you whether the outgoing provider still holds a copy of your artefacts. This connects directly to the exit and data-portability questions raised in the vendor assessment.
Top comments (0)