Skip to main content

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.

TrueFoundry Identity and Access Management (IAM) is built around a simple model: every tenant is an isolated workspace, and every person, service, team, role, and resource belongs to that tenant. IAM helps you decide who can enter that workspace, how they are created, how applications authenticate, and what each identity can access after it is inside. TrueFoundry hierarchy: a single Control Plane hosting multiple isolated tenants. Each tenant contains its own users, teams, virtual accounts, models, MCP servers, and other resources.

​
The IAM mental model

A control plane hosts one or more tenants. In the SaaS hosted version of TrueFoundry, the control plane is managed by TrueFoundry. In a self-hosted setup, your organization runs its own control plane and can create tenants under it. A tenant is the boundary where identity and access decisions happen. Each tenant has its own users, teams, virtual accounts, SSO configuration, provisioning mode, identity providers, roles, and resources. A user can belong to more than one tenant, but their access is evaluated independently in each tenant.
There is no interaction between data in different tenants. Users, teams, virtual accounts, models, MCP servers, and every other resource are scoped to a single tenant. To work in a different tenant, a user has to log in to that tenant separately — each tenant can also have its own SSO settings.
Resources such as models, MCP servers, prompts, clusters, workspaces, and applications live directly under the tenant. Tenant admins grant access to these resources to users, teams, or virtual accounts within the same tenant.

​
Users, teams, and services

Most IAM setup starts by deciding which identities exist in the tenant: Users are people who log in to TrueFoundry. They have unique email addresses and can be invited, synced from an IdP, created on first SSO login, deactivated, or deleted depending on how you configure user provisioning. Teams group users so that access can be managed once for a group instead of repeatedly for individuals. For example, you can give a team viewer access to a model, admin access to a workspace, or permission to use an MCP server. When users join or leave the team, their effective access changes with the team membership. Virtual Accounts are service-account-style identities for applications, services, CI pipelines, and automations. They are not tied to a human user, so their tokens remain stable when employees join or leave the organization.

​
Getting users into TrueFoundry

There are two related decisions for human users: how they authenticate, and how their user records are created. Use SSO when users should log in with your organization’s identity provider, such as Okta, Azure AD, Google, or Keycloak. TrueFoundry supports OIDC and SAML-based SSO. Use user provisioning to decide how users appear in the tenant:
  • SCIM syncs users and groups from your IdP and can also deprovision them when they are removed upstream.
  • Just-in-time (JIT) creates a user the first time they successfully log in with SSO.
  • Invite-only requires admins to manually invite users before they can join the tenant.
See SSO Overview for login configuration and Manage Users for provisioning behavior.

​
Giving applications access

Human users are not the right identity for long-running applications or automations. For those cases, use virtual accounts. A virtual account can be granted only the permissions that an application needs, and its token can be rotated, monitored, and synced to a secret manager. If your application already receives JWTs from your own IdP and you want TrueFoundry to accept those tokens for API, AI Gateway, or MCP Gateway access, configure Identity Providers. Identity Providers validate those external JWTs and resolve them to existing TrueFoundry users or virtual accounts. Identity Providers do not create users or teams. If a token should resolve to a user, that user must already exist in the tenant with the matching email. If a token should map to a team, the team must already exist and have the relevant identity provider mapping configured. Use Manage Users for user creation and Identity Providers for token resolution.

​
Granting access

After identities exist, access is controlled through roles and resource permissions. In practice, most teams use this pattern:
  1. Create or sync users into the tenant.
  2. Add users to teams that match how your organization works.
  3. Create virtual accounts for services and automations.
  4. Grant users, teams, or virtual accounts access to resources such as models, MCP servers, clusters, workspaces, prompts, and applications.
  5. Use custom roles when the default roles are too broad.
This lets platform teams centrally manage shared resources while still giving product, ML, data, or application teams the exact access they need.

​
How the features work together

These features are not alternatives — they are layers that work together. Most organizations use several of them at the same time. Layer 1 — Authentication (how users log in): Set up SSO so users log in through your organization’s IdP. This handles authentication only — it does not decide how the user record is created. Layer 2 — Provisioning (how user records are created): Choose a provisioning mode to control when and how TrueFoundry creates user accounts. SSO + SCIM is the most common combination for organizations that want the IdP to manage both authentication and the user lifecycle. SSO + JIT is simpler if you only need users created on first login. Invite-only works without SSO when admins want manual control. Layer 3 — Workload identity (how applications authenticate): Applications and services do not log in through SSO. Instead, they use virtual account tokens (issued by TrueFoundry) or present JWTs validated by Identity Providers (issued by your IdP). Neither of these creates users or teams — they resolve to identities that already exist. Layer 4 — Access control (what each identity can do): Once identities exist, grant them access to resources through collaborator roles on individual resources and tenant-level roles for broader permissions. See Manage User Roles and Permissions for details.

​
FAQ

Yes. A user can create or be invited to multiple tenants and switch between them. Each tenant is fully isolated, so the user’s roles, teams, and accessible resources are evaluated independently in each tenant.
Yes. You can create multiple tenants on the hosted control-plane. Each tenant is completely isolated — users, teams, resources, SSO, and billing are all scoped to the tenant.
Multi-tenancy on a self-hosted control-plane is offered as part of our higher-tier enterprise plan. It is typically used by very large organizations that have entirely separate platform/IT teams or business units that need hard isolation. Reach out to the Truefoundry team to enable this for your deployment.
You cannot. Tenants are designed to be completely isolated — there is no cross-tenant sharing of users, teams, resources, models, or MCP servers. If teams need to share resources, they should operate within the same tenant and use teams and roles to scope access.
Use teams to manage access for groups of human users. Use virtual accounts when an application, service, or automation needs a token to call TrueFoundry APIs — virtual accounts are not tied to a person and remain valid even when employees leave.