Create and use TrueFoundry API keys — Personal Access Tokens (PATs) for users and Virtual Account tokens (VATs) for applications.
TrueFoundry API keys are bearer tokens that let you authenticate to the platform programmatically — from the CLI / Python SDK, the REST API, the AI Gateway, the MCP Gateway, and CI/CD pipelines. The same token works across all of these surfaces.
The CLI and Python SDK accept the API key via the TFY_API_KEY environment variable. For HTTP APIs (REST, AI Gateway, MCP Gateway), pass the same token in the Authorization: Bearer … header.
Avoid using PATs in production. If the user who created the PAT is deactivated or leaves the organization, the token stops working and your application will lose access.
A PAT is created by a user and inherits all permissions of that user. Any user can create a PAT for themselves — admins can additionally configure tenant-wide limits and revoke other users’ tokens.
In the platform, go to Access > Personal Access Tokens and create a new token. You can optionally assign a Team to the token so that all costs incurred through this token are attributed to the selected team.
PAT creation form with optional team selection
Selecting a team on a PAT is for cost attribution only — it does not restrict the token’s permissions. The PAT still inherits the full permissions of the user who created it.
Save the token value when it’s first displayed — TrueFoundry will not show it again. Treat it like a password.
Admins can limit the maximum age and number of tokens that a single user can create under Settings > Security.
Mandate team selection for PATs
Admins can require users to select a team when creating a PAT by enabling Mandate Team Selection in Personal Access Token (PAT) under Settings > Security. When enabled, every PAT must be associated with a team, ensuring that all API usage costs are attributed to a specific team. This is useful for organizations that need strict per-team cost tracking, especially when users belong to multiple teams.
Security setting to mandate team selection for PATs
Revoke a user's PATs
Admins can revoke all active personal access tokens for a particular user from Access > Users.
A virtual account is a non-user identity owned by an admin (or by a team if allowed by a custom role). It’s granted exactly the permissions an application needs, and its token survives staff turnover.
Use a separate virtual account per application or service. This gives you per-application usage tracking, independent rotation, and least-privilege scoping.
1
Create a virtual account
In the platform, go to Access > Virtual Accounts and create a new account, picking the resources and roles your application needs.
2
Get the token
Click Get Token on the virtual account to retrieve the bearer token. Use this as your API key in the application.
3
(Optional) Configure rotation, notifications, or secret store sync
Virtual accounts support advanced lifecycle features that PATs don’t:
Auto-rotation — rotate the token at a configurable interval, with a grace period for the previous token. See Configure auto-rotation.
Secret store sync — write the token to AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault, etc., and keep it in sync on rotation. See Configure secret store sync.
Identity provider mapping — let an externally issued JWT resolve to this virtual account. See Identity provider mappings.
For full virtual account management — collaborators, permissions, deletion, and the management API — see Manage Virtual Accounts.