Actors

Actors are the identities that access Firezone. There are four kinds, differing in whether they represent a human and in what they're allowed to access:

ActorHuman?Can accessAuthenticates with
Regular userYesClientsYour identity provider (SSO or email OTP)
AdminYesAdmin portal + ClientsYour identity provider (SSO or email OTP)
Service accountNoClientsA long-lived token (not tied to a provider)
API clientNoREST APIAn API token

Regular users, admins, and service accounts connect through a Firezone Client, so they're granted access to Resources by adding them to Groups and writing Policies. API clients are different — they call the REST API rather than connecting a Client, so they aren't governed by Policies.

Every human user — both regular users and admins — is automatically a member of the special Everyone group, a managed group that cannot be deleted or modified. Service accounts and API clients are not members of Everyone: a service account gains access only through the Groups you explicitly add it to.

Regular users

Regular users are human actors who sign in to the Firezone Clients to access Resources. They have the User role, which grants access to the Clients only — not the admin portal.

Users can be created manually (Actors → Add Actor → User) or provisioned automatically from your identity provider. Automatic user sync is available for Google Workspace, Microsoft Entra ID, and Okta on the Enterprise plan — see directory sync for how it works.

Admins

Admins are human users with the Admin role. In addition to signing in to the Clients to access Resources, they can sign in to the admin portal to manage the deployment — Sites, Gateways, Resources, Policies, actors, and account settings.

An actor's role (User or Admin) can be changed from their detail page in the admin portal. Grant the Admin role sparingly, following the principle of least privilege.

Service accounts

Service accounts are non-human actors that authenticate to Firezone with long-lived tokens. They're intended for headless Clients running on servers, IoT devices, CI runners, or other unattended systems where no user is present to perform an identity provider sign-in.

Service accounts can be added to Groups and Policies to gain access to Resources. Unlike users, however, they aren't included in the Everyone group, so you must add a service account to a Group explicitly before any Policy will apply to it. They're also managed manually and are never synced from your identity provider. Their tokens are multi-owner (a single token can be used by many headless Clients at once), default to a 365-day lifetime, and are unaffected by identity-provider configuration or session-lifetime settings.

To authenticate a headless Client as a normal user instead of a service account, you don't need a service account at all — the Linux and Windows headless Clients support browser-based sign-in. See the Linux Headless Client or Windows Headless Client guides.

For a worked example of creating a service account and using its token in automation, see Access Resources from GitHub Actions CI.

API clients

API clients are non-human actors that authenticate to the REST API with an API token. They're how you manage your Firezone account programmatically — creating Resources, Policies, Gateways, actors, and more from your own scripts and tooling.

Unlike the other actors, an API client cannot sign in to a Firezone Client or the admin portal, and it isn't granted Resource access through Policies — its API token authorizes it to call the REST API on behalf of your account. Because that token can manage your whole account, treat it like an admin credential: scope its use carefully, store it securely, and rotate or revoke it when it's no longer needed.

API access is off by default. To turn it on, open Settings → API Clients in the admin portal and request access; once Firezone enables it for your account, you can create an API client and generate one or more API tokens for it, and revoke any token at any time. See the REST API setup guide for step-by-step instructions and the REST API reference for the available endpoints.


Need help? See all support options.

Found a problem with this page? Open an issue
Last updated: July 01, 2026