> ## Documentation Index
> Fetch the complete documentation index at: https://www.truefoundry.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Removing collaborators from resources

> We are removing collaborators from per-resource manifests so a resource is no longer tied to its authorization.

<Warning>
  **Applicable to:** Anyone who still puts **`collaborators`** on a resource YAML, or **`permissions`** on a virtual account YAML — including GitOps, Terraform, and API clients. If you only use the TrueFoundry UI, **no action is required**.
</Warning>

We are in the process of **removing collaborators from each resource**. This is our effort to **decouple a resource from its authorization**.

Access no longer lives inside the resource (or virtual account) configuration. You assign a **role** on a **resource** to a **subject** (a user, team, virtual account, or agent) from **Access Control**, or with a separate role-binding manifest.

Existing access is kept. Removing these fields from a form or YAML does **not** by itself take access away.

## Who needs to act

| How you manage TrueFoundry                                                                             | What you should do                                                                              |
| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------- |
| UI only                                                                                                | Nothing. Keep using **Access Control** on the resource or on the user / team / virtual account. |
| GitOps, `tfy apply`, or any YAML/API that still sends `collaborators` or virtual-account `permissions` | Move those grants to role bindings before the removal date below.                               |

## What is changing

* **`collaborators`** is leaving resource manifests (workspaces, clusters, model accounts, MCP servers, agents, secret groups, and other resources that used this field).
* **`permissions`** is leaving virtual account manifests. Virtual account access is managed from **Access Control** on the virtual account, the same way as other subjects.
* TrueFoundry-generated YAML (including **Apply using YAML**) no longer includes these fields. That is expected.

Older manifests that still include the fields **continue to work during the transition**. You can submit a resource without `collaborators`, and a virtual account without `permissions`, without changing who already has access.

| If the field is…                       | What happens                                                      |
| -------------------------------------- | ----------------------------------------------------------------- |
| Omitted                                | Existing access is left as-is                                     |
| 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 if it should have no access |

## How to migrate (GitOps)

1. Back up or commit your current manifests.
2. Convert `collaborators` (and non-model `authorized_subjects`) into role-binding documents:

```bash theme={"dark"}
tfy migrate collaborators -d truefoundry
tfy migrate collaborators -d truefoundry --write
```

The first command is a dry run. `--write` updates files on disk. Review the diff, then apply:

```bash theme={"dark"}
tfy apply -d truefoundry --dry-run --show-diff
tfy apply -d truefoundry
```

This CLI migration does **not** rewrite virtual account `permissions`. For virtual accounts, grant access from **Access Control** (or export/apply a role-binding manifest) instead of putting `permissions` on the virtual account YAML.

## Audit logs

If you see `collaborators` or `permissions` removed in an activity diff, that is expected. It means authorization was taken off the resource document — **not** that people lost access.

When access is granted or revoked through Access Control or role bindings, look for role-binding activity such as **Apply role binding** / **Delete role binding**.

## Timeline

| Milestone                                                                  | Date                              |
| -------------------------------------------------------------------------- | --------------------------------- |
| Announcement                                                               | This release                      |
| Older `collaborators` / virtual-account `permissions` fields fully removed | **Two months after this release** |

<Warning>
  Update GitOps and programmatic manifests well before the removal date so applies do not fail when the fields are no longer accepted.
</Warning>

## FAQ

<AccordionGroup>
  <Accordion title="Will users lose access when collaborators disappear from the form or YAML?">
    No. Existing grants stay in place. Access is now viewed and changed from **Access Control**.
  </Accordion>

  <Accordion title="I do not use GitOps. Do I need to do anything?">
    No.
  </Accordion>

  <Accordion title="How do I give someone access to a resource now?">
    Open the resource → **Access Control** → **Grant Access**. Pick the user, team, virtual account, or agent, then pick a role.
  </Accordion>

  <Accordion title="How do I give a virtual account access to resources?">
    Open the virtual account → **Access Control**. Add organisation roles and/or resource permissions there. Do not put `permissions` on the virtual account YAML going forward.
  </Accordion>
</AccordionGroup>

***

If you have questions or need help migrating, reach out to [**support@truefoundry.com**](mailto:support@truefoundry.com).