Security settings

Tenant-wide security controls in TrueFoundry: Personal Access Token policy, security notifications, UI login IP allowlisting, and emergency revocation of every PAT.

Security settings are the tenant-wide controls that apply to everyone in your organization, regardless of their role or team. They decide how long-lived and how numerous user API tokens can be, who hears about security events, where the TrueFoundry UI can be reached from, and how to cut off every user token at once if one leaks.

They live under Settings > Organisation > Security & Access, next to the identity settings that decide how people sign in:

Security & Access groups tenant security policy with sign-in and provisioning settings

Setting	What it controls	Covered
Security	PAT expiry, count, and team assignment; security notification recipients; UI login IP allowlist	On this page
SSO	How users authenticate through your identity provider	SSO overview
Provisioning	How user records are created — SCIM, just-in-time, or invite	User provisioning
Identity Providers	Which external JWTs TrueFoundry accepts for API and gateway access	Identity Providers
Revoke all PAT	Immediately revokes every user’s Personal Access Tokens	On this page
Delete Account	Permanently deletes the tenant	Delete tenant

Changing security settings requires the Tenant Admin role, or a custom role with the Manage Settings (settings:ManageSettings) permission.

How the Security settings apply

The Security card holds a single policy for the tenant. Its Enabled switch is a master switch: while it is off, none of the limits below are enforced and the card shows Disabled. Turn it on to enforce the policy you configure.

The Security policy: PAT limits, team assignment, notifications, and UI IP allowlisting

Recommended configuration

Start from this baseline and adjust to your organization’s policy. It keeps user tokens short-lived and few, makes sure someone hears about security events, and keeps the dashboard off the open internet.

Setting	Recommended	Why
Enabled	On	None of the other limits are enforced while it is off.
Maximum PAT expiry	90 days or less	Forces regular rotation and bounds how long a leaked token stays useful.
Maximum PATs per user	5	Enough for a laptop, a notebook, and a couple of scripts; stops tokens accumulating unnoticed.
PAT team assignment	Required if you budget or charge back per team, otherwise Optional	Keeps AI Gateway spend attributable to a single team.
PAT retrieval after creation	Off	A token shown once cannot be read back by anyone who later gains API access as that user.
Security notifications	A monitored group address	Notices still land when people change roles or leave.
UI login IP allowlist (SaaS)	Corporate egress IPs and VPN ranges	Keeps the dashboard unreachable from unmanaged networks. On self-hosted, restrict at the network layer.

Production workloads should not use PATs at all — give them a virtual account with auto-rotation instead.

As a manifest:

security.yaml

type: settings/security
enabled: true
max_pat_expiry_minutes: 129600   # 90 days
max_pats_per_user: 5
pat_team_assignment_mode: required
to_emails:
  - [e-mail]
access_restrictions:            # SaaS only
  allowed_ip_cidrs:
    - 203.0.113.0/24            # corporate egress
    - 198.51.100.0/24           # VPN

Personal Access Token controls

Personal Access Tokens (PATs) act with the full permissions of the user who created them, so they are the most sensitive credential most users hold. These settings bound how much damage a single token can do and how long it stays useful.

Setting	Effect
Maximum Expiry Time for Personal Access Token (PAT) in days	The longest lifetime a user can choose when creating a PAT. Up to 7000 days. Shorter limits force regular rotation.
Maximum Personal Access Token (PAT) Per User	How many PATs each user can hold at once. Leave blank for no limit. A low limit keeps tokens from accumulating unnoticed in scripts and laptops.
Personal Access Token (PAT) Team Assignment Mode	Whether a user must, may, or cannot attach a team to a PAT. See Team assignment modes.
Enable PAT Retrieval After Creation	Lets users read back the value of their own PATs through the API after creation. Off by default, so a token is shown only once.

Limits apply when a token is created. Tightening the maximum expiry does not shorten tokens that already exist — to cut those off, use Revoke all Personal Access Tokens.

Turn on PAT retrieval only when a workflow genuinely depends on it. A token that can be read back can also be leaked again, and anyone holding it acts as its owner.

Team assignment modes

Attaching a team to a PAT decides which team its AI Gateway usage is billed to. It does not change what the token can access — a PAT always carries its owner’s permissions.

Mode	When creating a PAT	Cost is attributed to
Required	The user must select a team.	Only the selected team.
Optional	The user may select a team.	The selected team, or every team the user belongs to if none is selected.
Disabled	The user cannot select a team.	Every team the user belongs to.

Choose Required when chargeback to a single team matters, for example when budget limits are set per team.

Security notifications

Send security updates to lists the email addresses that receive security-related notifications for the tenant. Use a monitored group address, such as [e-mail], so notices still reach someone when people change roles or leave.

Restrict UI logins by IP

Restrict UI Logins by IP limits browser access to the TrueFoundry UI to the IP addresses and CIDR ranges listed under Allowed IPs and CIDRs. Use it to keep the dashboard reachable only from your corporate network, VPN egress, or approved administrator locations.

The restriction applies to UI logins only. API calls and AI Gateway traffic are authenticated by tokens and are not affected — to control those, scope tokens with roles and gateway access control.

Include the public IP you are configuring from. TrueFoundry refuses to save an allowlist that would lock out your current session.

UI login IP allowlisting is available on TrueFoundry SaaS. On a self-hosted control plane, restrict access at the network layer instead — see Self-Hosted Security.

Manage the policy as code

The same policy can be kept in Git and applied with tfy apply. Apply using YAML on the form generates the manifest for your current values:

security.yaml

type: settings/security
enabled: true
max_pat_expiry_minutes: 525600   # 365 days
max_pats_per_user: 20
pat_team_assignment_mode: optional   # required | optional | disabled
to_emails:
  - [e-mail]
access_restrictions:
  allowed_ip_cidrs:
    - 203.0.113.0/24

tfy apply -f security.yaml

The manifest expresses PAT expiry in minutes, while the form uses days. Multiply days by 1440.

Revoke all Personal Access Tokens

Settings > Organisation > Account Management > Revoke all PAT immediately revokes the Personal Access Tokens of every user in the tenant. It is the emergency control for a suspected credential leak, when you cannot tell which tokens were exposed.

Revoke all PAT under Account Management

Every script, CI job, and local tool that authenticates with a PAT stops working at once, and each user has to create a new token. This is one more reason to run production workloads on virtual accounts instead of PATs. Virtual account tokens are managed separately — rotate them from Access > Virtual Accounts.

To cut off a single person rather than everyone, deactivate the user — their PATs stop working too.

Related

SaaS security checklist

The full set of controls to review during onboarding and quarterly.

API keys

Create, use, and rotate Personal Access Tokens and virtual account tokens.

Disable password login

Require SSO for everyone once it is verified.

Delete tenant

Permanently delete the organization and its data.