Trust and security: support access

Use Security in your Praxis account to review how support can get access to your site’s admin. This guide explains how support can enter, what a grant or revocation controls, and which entries appear in the Security log. It also covers permissions and the available ways to recover a change.

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

Praxis combines EmDash’s content management with controls for your team, your visitors and the copilot.

Your team controls access

Sign in to your Praxis account, then use Open admin → on the Sites tab. The handoff carries your site role, works for that site only, must be used within two minutes and opens one session. The site then keeps its own admin session.

The site roles are Viewer, Contributor, Author, Editor and Admin. By default, Editors cannot read visitor records or form submissions, export visitor data, manage consent policy or manage the team. These permissions are checked separately from whether a screen is visible.

An account owner or Admin can open Security and set a Team session policy. It offers required two factor authentication, session lifetime, idle timeout and allowed network addresses. The network list must include the address of the person saving it. 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.

The policy is checked when your team uses the Praxis account, including Open admin →. It is also checked inside an already open site admin session. 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. Session lifetime and idle timeout do not apply to tokens.

The model proposes; the platform authorizes

The copilot submits actions to a platform gate. The gate checks permissions and validates the request before it prepares a change. When the copilot publishes, deletes or changes consequential settings, it requires an approval card. The platform checks the approval against the person, the proposed action and the state it was prepared from.

Read the consequence and reversibility lines before approving. Some actions return Undo. Others cannot be undone, including visitor erasure. A scheduled publish is approved for its future time when you approve the schedule.

For pages and posts, the publish check runs before scheduling and again when publication is due. Approval does not bypass it. A refusal removes the schedule and leaves the draft or its changes unpublished; a check that cannot finish leaves publication waiting for another check.

EmDash’s own admin screens remain part of Praxis. A team member whose role allows publishing can use Publish in EmDash’s editor to publish at once, as their explicit act. Anything the copilot publishes always pauses for the approval card.

Support access is visible

1. In your Praxis account, open Security.
2. Find Support access.
3. Read the ways Amadalis staff can enter below:

• You can grant read only entry for a reason you state, and revoke that grant. 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.
• Support can use an active grant to enter your site read only.
• In an incident, support can state a reason and enter read only without your grant.
• Platform Admin staff can enter your site without your grant, after confirming an Admin override and giving a reason. The override uses a separate Amadalis staff user with Admin permissions, subject to the staff 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. A missing end can be recorded later by the platform’s regular run after an eligible grant expires; the entry makes that delay and the unknown use of the entry link explicit.

Emergency read only access needs no grant from you, but support must state a reason. An Admin override also needs no grant from you, but platform Admin staff must confirm it and give a reason. 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.

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.

The Security tab also has Single sign-on (SSO) and SCIM provisioning. It can connect an OpenID Connect sign in provider for a verified email domain and issue SCIM tokens for automatically creating or disabling team memberships. Account owners and Admins can read the Security log under Activity and download it as a CSV spreadsheet file. Amadalis has a public Subprocessors list of service providers that process customer data; ask support for the current register.

Site data and AI requests

Can another customer see your site’s private data?

Not through their own site. A hosted site’s hostname selects only that site’s own database, and unknown, pending and suspended hosts are refused rather than falling back to another site’s database.

Your account’s Overview includes Where your data lives. It reports the recorded database region, or says when that record is missing. The global network, caches and AI features are not all pinned to that region. A database location is not a promise that every part of the service runs in that country.

Model requests use an authenticated Cloudflare AI Gateway route. The provider adapters request gateway logging of request details only, with collection of the prompt and response content disabled. This describes that gateway setting. It does not establish a model provider’s retention or training terms.

Records and recovery

Your account’s Security log records account actions. Each entry is linked by a SHA-256 checksum, a digital fingerprint, to the previous entry in the platform’s audit log. Its tamper-evident checks identify editing or deletion of an earlier entry, and the platform checks the whole chain every night. The result identifies four recorded gaps from 19 August 2026. Account erasure is designed to remove personal details without breaking the check. The account does not show a verification result. Read verification and its limits. The site’s copilot Activity record is a separate record. An approved change goes ahead even if its Activity record fails to save; the failure is logged on the server. The change keeps any Undo it offered on its receipt.

Amadalis staff perform site restores. A restore returns the whole site database to a chosen backup, replacing work saved since that backup. The flow takes a fresh backup first and suspends the site while it runs. Ask support to arrange a restore. Taking or downloading a content backup from EmDash’s Backup settings screen is not available on the hosted site’s database yet.

Read Privacy and consent for visitor controls and Known limitations before planning an integration or a security review.