User Authentication

Every person who uses Agility signs in with an Agility user account, and the same account is used for the Content Manager, the Management API, the CLI and AI assistants connected through the MCP Server. As an organization administrator, you decide which sign-in methods your users may use, whether MFA is enforced, and whether your own identity provider is the only way in.

Sign-in methods

Method	How it works	Available on
Email and password	A verified email address and a password that must meet complexity rules. Can be combined with Agility's built-in multi-factor authentication.	All plans
Google, Microsoft or GitHub	The user signs in with that account. Its verified email address must match an Agility user. See Authenticate with Microsoft or Azure AD/Entra.	All plans
Enterprise SSO	The user signs in through your identity provider (Microsoft Entra ID, Okta, any SAML 2.0 or OpenID Connect provider), which applies your own MFA and access policies. See Enterprise Single Sign-On.	Enterprise plans

Your organization's sign-in policy

These settings apply to every user in your organization, across all of its instances:

• Allowed sign-in methods. Turn off any method you don't want, so users can sign in only with the ones you choose. Requires a Pro or Enterprise plan.
• Enforce MFA. Every user who signs in with email and password must enrol in and use MFA. Requires a Pro or Enterprise plan.
• Require SSO. Turn off every method except your Enterprise SSO connection. Requires an Enterprise plan.

To change these settings, contact support@agilitycms.com. They aren't available in the Content Manager yet. Managing them yourself is on our roadmap: vote for it.

How sign-in and permissions work without SSO

1. An administrator adds the user. In Settings > User Access, they enter the person's email address and choose a role. The person receives an email with a link to set a password. Users can also be added through the Management API. See User Access.
2. The user signs in at Agility's sign-in page with an allowed method. If your organization enforces MFA, they enrol on first sign-in and enter a one-time code from then on.
3. Agility issues a short-lived access token. The Content Manager sends it with every request to the Management API.
4. Every request is authorized. The Management API checks that the user still has access to the instance and that their role allows the action, on every call. See User Permissions.

Removing a user

Remove the user from each instance in Settings > User Access. This takes effect on their next request, and it also stops any Personal Access Tokens they created from working on those instances. If you use SSO, also disable the user in your identity provider so they can't sign in again.

Common scenarios

Require MFA for everyone

Allow only email and password sign-in, and enforce MFA. Every user then signs in the same way and has to pass MFA, whatever their email domain.

Allow only one social login

If your organization trusts Google to authenticate its people, allow only Google sign-in. Users who don't have a Google account with a matching email can't get in.

Require your own SSO

Allow only your Enterprise SSO connection. Every user must sign in through your identity provider, which applies your MFA, device and network policies, and nobody has a separate Agility password. When someone leaves, disabling them in your identity provider blocks new sign-ins. Remove them from your Agility instances as well, because a session that is already open stays valid until it expires.

Things Agility doesn't restrict

• Network location. Agility doesn't offer IP allowlisting (request it on our roadmap if you need it). To limit sign-ins to your network or devices, require SSO and apply the rules in your identity provider, for example with Microsoft Entra Conditional Access. Conditional Access is checked when the user signs in, not on every request.
• Personal Access Tokens. Any user can create a Personal Access Token for scripts and integrations, and this can't currently be turned off for an organization. Tokens carry the owner's permissions, can't manage users or tokens, and expire after at most two years. If you need to turn them off, request it on our roadmap.

For a summary written for security reviewers, see the Security Review Guide.