Collaborators are moving off resource manifests and permissions off virtual account manifests, so a resource is no longer coupled to its authorization.
If you manage access from the TrueFoundry UI: no action is required. Existing access is preserved and can be managed from Access Control.
If you manage resources through GitOps or keep resource YAML in Git: update those manifests during the transition period.
Action is only required if you manage resources through GitOps, or keep resource YAML in Git. See GitOps and YAML for what to change and by when. The migration command requires TrueFoundry CLI >= 0.17.4.
We are in the process of removing collaborators from each resource. This is our effort to decouple a resource from its authorization.Until now, access to a resource—for example, who can use a model provider account—was stored inside the resource itself. Similarly, what a virtual account could access was stored inside the virtual account. This coupled each resource configuration to its access list.From v0.172.0, access is described separately from the resource. You grant a role on a resource to a subject — a user, team, virtual account, or agent — from the Access Control screen, or with a standalone role-binding manifest. A single grant is just the sentence “this subject has this role on this resource”.
No access is lost. Every existing grant is preserved. Removing these fields from a form or a YAML file does not, by itself, take anyone’s access away.
The change is visible on three surfaces: resource forms, virtual accounts, and generated YAML.
The Collaborators section is removed from resources that supported it, including model provider accounts, clusters, ML repos, secret groups, MCP servers, agents, and workspaces. In its place, the form points to Access Control.The examples below use provider accounts from environments running before and after this change.
Before: access was managed from the provider account form
The access list now has its own screen. On the resource list, click the three dots at the end of the row and choose Access Control.
Model provider account → three dots → Access Control
Access Control lists everyone who has access, grouped by role, with a Grant Access button for adding someone new.
Access Control for nm-gemini2: existing grants are preserved and grouped by role
When you save a provider account that still contains collaborators, TrueFoundry shows the removal in the confirmation diff first. The block leaves the configuration; the access it described is kept under Access Control.
Saving nm-gemini2: collaborators leave the configuration, existing access is retained
This is also recorded in your activity log—see what audit logs will show so the entry does not look alarming.
The Permissions section is gone from the virtual account form. A virtual account is now treated like any other subject: you give it access the same way you would a user or a team.
Before: the form carried role selection and per-resource-type permissions
On the Virtual Accounts list, click the three dots at the end of the row and choose Manage Permissions. This is the same screen the form’s notice links to.
Virtual Accounts list → three dots at the end of the row → Manage Permissions
From there you can assign organisation roles to the virtual account and add resource-specific permissions to it. As with resources, removing permissions from a virtual account is recorded in your activity log — see what audit logs will show.
YAML that TrueFoundry generates for you — including the Apply using YAML drawer — no longer includes collaborators or virtual account permissions. If you copy a manifest out of the dashboard and notice the access list missing, that is expected.
Before: the generated manifest included collaborators
After: the manifest describes only the provider account
If you manage access from the TrueFoundry UI, no action is required. Continue using Access Control for resources and Manage Permissions for virtual accounts.
This is the only part of the change that asks something of you, and it applies if you keep resource YAML in Git — through GitOps, tfy apply, Terraform, or your own API client.
Your existing manifests keep applying successfully. A manifest that still sets collaborators is accepted for two months (collaborators will retire on 15th November 2026). Nothing fails on release day, and no pipeline needs an emergency fix.
You can also start submitting manifests without these fields right away — that will not change who already has access. Here is exactly how each field is treated while both models are accepted:
If the field is…
What happens
Omitted entirely
Existing access is left untouched
A non-empty list
Those grants replace the previous legacy grants for that field
collaborators: []
Legacy collaborator grants on that resource are cleared
permissions: [] on a virtual account
Rejected — delete the virtual account instead if it should have no access
The safe way to adopt the new model is to stop sending the field rather than sending an empty list. An omitted field is a no-op; an empty collaborators list is a deliberate instruction to revoke.
The CLI rewrites your manifests for you (TrueFoundry CLI >= 0.17.4). It converts collaborators, virtual-account permissions, and non-model authorized_subjects into role-binding documents placed next to the resource they belong to, in the same file.
1
Commit your current state
Make sure your working tree is clean, so the rewrite shows up as a reviewable diff.
2
Rewrite your manifests
tfy migrate-gitops -d truefoundry
This prints the planned changes, then updates the files on disk: grant fields are removed and the generated role-binding documents are appended to the same file. There is no dry-run flag — generated binding names include a random suffix, so a preview would not match what a later write produces. If any manifest cannot be converted, nothing is written. Review the git diff before continuing.
A virtual account with permissions. These work the other way round — the grants sit on the subject and name the resources — so they collapse into a single binding called va-<account name>. Before:
A few things worth knowing when you hand-write these:
subjects[].type is one of user, team, virtualaccount, or agent. For user, name is the email address; for the rest it is the resource name.
resourceFqn identifies the resource receiving the grant. The CLI generates it during migration. If you write a binding by hand, copy the exact FQN from the resource page. In the example above, replace tfy-tenant with your tenant FQN.
Each binding must be either one subject with many permissions or many subjects with one permission — not both many at once. Splitting per role, as above, always satisfies this.
name is your own identifier for the binding, 3–64 lowercase characters. The CLI generates names for you; if you write bindings by hand, pick something you will recognize in a diff.
What will I see in audit logs when collaborators or permissions are removed?
Applying a resource is recorded with its usual action — Apply Provider Account, Apply Workspace, Apply Mcp Server, and so on — and the summary lists Collaborators among the updated fields.
Updating nm-gemini2: the summary reports Collaborators among the changed fields
Opening the entry shows the diff: the collaborators block leaves the document. This records authorization being lifted out of the resource — it does not mean anyone lost access. The grants themselves live on as role bindings.
The collaborators block leaves the provider account document; the grant it described lives on as a role binding
The same applies to a virtual account: removing permissions is recorded against the virtual account, and the grants it described are preserved.
What do audit logs look like when access is granted or revoked from the dashboard?
Granting or removing access is recorded as Create Access Grants or Revoke Grant, naming the resource and the role involved.
Grants created and revoked, each naming the resource, its type, and the role
What do audit logs look like when role bindings are applied from YAML?
Applying a role-binding manifest is recorded as Apply Role Binding, naming the binding and how many subjects it covers. This is what you will see after running the migration and applying.
Role bindings applied from YAML, each naming the binding and its subject count
See Audit Logging for how to filter and search these entries.
Will anyone lose access when collaborators disappear from the form or YAML?
No. Every existing grant is preserved and is visible under Access Control on the resource.
I don't use GitOps. Do I need to do anything?
No. Grant and review access from Access Control exactly as you do today.
How do I give someone access to a resource now?
Open the resource list, click the three dots on the row, and choose Access Control. Click Grant Access, then pick the subject (user, team, virtual account, or agent) and the role to give them.
How do I give a virtual account access to resources?
Treat it like any other subject: grant it a role from the resource’s Access Control screen, or add permissions to it from Manage Permissions on the virtual account. Do not add permissions to virtual account YAML going forward.
Can I keep using my old manifests until the removal date?
Yes. They continue to apply successfully during the transition window. We recommend migrating early so the change lands on your schedule rather than on the deadline.
Can I roll back if the migration output looks wrong?
Yes. tfy migrate-gitops only edits local files, so git checkout restores them. Nothing reaches the platform until you run tfy apply.
