Source: https://docs.amadalis.ai/account/security/

# Account Security controls

Checked against the product’s code on 7 November 2026.

In your Praxis account, an owner or Admin can open **Security**. This tab controls account access and related policies. It is separate from the site’s native security screen and its open admin sessions.

## Team session policy

**Team session policy** offers required two factor authentication, [session lifetime](https://docs.amadalis.ai/reference/glossary/#session-lifetime), [idle timeout](https://docs.amadalis.ai/reference/glossary/#idle-timeout) and allowed network addresses. Include your own current address when setting a network list. The service refuses a list that would lock the saver out.

1.  Choose **Save policy**.
2.  Click again to confirm.
3.  Read the saved result.

The policy applies to each member’s next account request. An empty field means no limit. The policy is checked on account requests, including opening a site’s admin. It is also checked inside an already open site admin session. If the account cannot read the policy, it pauses access if the last known policy has a rule or its history cannot be read. A team with no recorded policy or no last known rules can continue. The page says “We could not check your team’s sign-in rules; try again in a minute.” It keeps the sign-in session for a retry.

When **Open admin →** opens another of your sites, that site’s own team rules decide entry. A closed home site does not impose its old rules on a seat you still hold elsewhere.

On requests inside the site, address and session limit changes are normally picked up within about 30 seconds, or longer if the site cannot reach the account. Idle expiry can be up to 30 seconds late. When two factor authentication is required, use **Open admin →** from your Praxis account; a direct site sign in does not meet that requirement. Requiring two factor authentication does not end a site session already opened from the account. If the site cannot read the policy, it uses a policy read within the last five minutes. Without one, it pauses access if the last known policy has a rule or that record cannot be read. A team with no recorded policy or no last known rules can continue. A server that last read a rule may still pause access after another server has read that the rules were cleared. The paused page asks you to try again in a minute. An existing session is kept; a refused new site sign in opens no session.

Site API tokens obey the team’s applicable network, membership and two factor rules, with the [token checks and read-failure limits](https://docs.amadalis.ai/account/site-access-and-settings/#personal-api-tokens). Session lifetime and idle timeout do not apply to tokens.

## Network addresses in your log

This controls future address records for the site your account was opened with. Entries from other sites keep their own site’s setting. It does not rewrite earlier entries or itself verify the log’s chain.

You can also ask the copilot to keep full network addresses or only the network in future log entries. Read its policy card before approval. Older entries keep the mode used when they were recorded.

1.  Under **Network addresses in your log**, choose **Network only** or **Full address**.
2.  Choose **Save setting**.
3.  Read the confirmation before saving.
4.  Confirm only the intended setting.
5.  Read the result.

## SSO and provisioning

**[Single sign-on (SSO)](https://docs.amadalis.ai/reference/glossary/#single-sign-on-sso)** connects a sign in provider using the OpenID Connect standard for a verified email domain. People who sign in this way join as members, never as owners. Review [the verified-domain requirement](https://docs.amadalis.ai/trust/known-limitations/#access-and-integrations) before connecting.

1.  Fill in **Verified email domain**.
2.  Fill in **Issuer URL**.
3.  Fill in **Client ID**.
4.  Fill in **Client secret** in this dedicated form.
5.  Choose **Connect identity provider**.
6.  Read the connection result.

**[SCIM provisioning](https://docs.amadalis.ai/reference/glossary/#scim-provisioning)** lets an identity provider create or disable team memberships automatically. It can create a provider token, shown once. Store it in the identity provider’s trusted setup. A member created through SCIM joins at the viewer role. Change their role in **Team**; the identity provider never sets roles. **[Viewer](https://docs.amadalis.ai/reference/glossary/#viewer)** can read site content but cannot create, edit or publish. Existing members keep their current roles. An update that tries to change a role is refused in full, even if it also asks to disable the membership. Deactivation disables the membership and keeps its history. Account roles and ownership remain managed in Praxis. Revoking the token stops further use of that credential.

To prepare a provisioning token:

1.  Enter **Token label** in **SCIM provisioning**.
2.  Choose **Mint SCIM token**.
3.  Choose **Copy token** while the token is shown.
4.  Store it in the identity provider’s trusted setup.
5.  Use the provisioning address shown in **SCIM provisioning** in that setup.

To stop that token:

1.  Choose **Revoke** beside the intended token.
2.  Confirm with the second click.
3.  Read the result.

## Support access

Use **[Support access](https://docs.amadalis.ai/reference/glossary/#support-access)** in your account’s **Security** tab to review how Amadalis staff can get into your site’s admin. The entry routes and their limits are described below.

These controls require an active owner or Admin membership on the site your account was opened with. If you also hold an active owner or Admin membership on an active or suspended site in this account, **Support access** shows live grants across its sites. You can revoke any grant in that list. When grants for different sites are shown, the rows name their sites.

Giving a new grant needs an active owner or Admin membership on that specific site, which must be active or suspended. Use **Site this grant covers** when the form offers it. If the form names just one site, check that name. A one-site account keeps its existing form.

If your only active owner or Admin memberships are on closing or closed sites, the list and revocation cover only the site your account was opened with. This applies throughout the account closing window. A live grant left on a closing or closed site can still be listed and revoked when that site is within your view. Fully erased sites no longer appear.

1.  If **Site this grant covers** is offered, choose the intended site. If the form names just one site, check that name. A one-site account keeps its existing form.
2.  Enter the reason under **Reason (what support is helping with)**.
3.  Choose **Grant 4-hour read-only access**.
4.  Read the result.

Revoking the grant stops new entries and ends its open support session on the next request after the grant check refreshes, within 30 seconds. At expiry, the next request ends the session.

To revoke a listed grant:

1.  Choose **Revoke** beside it.
2.  Confirm with the second click.
3.  Read the result before relying on the change.

In an incident, support can state a reason and open a read only visit without your grant. That emergency permission lasts one hour; the next request at its expiry ends the visit. Platform Admin staff can enter without your grant after confirming and giving a reason. They use a separate Amadalis staff user with Admin permissions, subject to the restrictions below.

An Admin override lasts one hour. Staff cannot add users or invitations, change a user’s details or role, re-enable access, add or edit signup rules, or install or configure plugins. They also cannot set credentials, webhook destinations or recipients that would give continuing access. Removing access can still be allowed. Staff cannot use a separate site sign-in or a site API token to keep access after the visit.

The support visit shows a banner naming the staff member, its access and its end time in UTC. If the grant cannot be checked, the request is blocked while the session is kept. The service tries to record when a staff visit ends. If that record fails to save, the visit still ends and the failure is logged on the server.

Only account owners and Admins can read the **Security log** under **Activity**. Support entries into any site in the account appear in your **Security log** and its CSV export. Reading across sites requires an active owner or Admin membership on an active or suspended site in that account.

Entries for a fully erased site no longer appear. Without that active membership, the log and export show only the site your account was opened with. That limit applies throughout the account’s closing period when all its sites are being closed or have closed. See [Trust and security](https://docs.amadalis.ai/trust/security/) for their enforced scope.