Support access and break-glass

Tanomis support sometimes needs to act inside a customer workspace: to help during onboarding, diagnose a stuck provisioning, or reproduce an issue. That access is never a standing platform credential. It is a short-lived, signed grant scoped to one workspace, with a reason, an expiry, and an audit binding.

At a glance

• Support acts through a support grant: one workspace, one reason, a short expiry, signed by the platform.
• The grant is the only way support reaches a customer workspace; a raw platform credential does not.
• Every action taken under a grant lands in your organization’s audit trail, attributed to the support principal and the grant.
• You can read the trail at any time; ask your administrator to revoke a grant early.

What a support grant is

A grant names the target workspace, the support principal, the reason given, and when it expires. The platform signs it, and every service on the path to your data checks it, so the grant cannot be widened to another tenant or extended by the holder.

Without a grant, the platform’s own administrators have no route into a customer workspace’s sessions, files, or evidence.

What you see

Actions under a grant appear in the audit trail like any other action, with the support principal as the actor and the grant as the authority. In the Console, the Assurance section and tanomis org audit show them alongside your members’ actions.

Terminal

tanomis org audit --limit 200

Asking for help

When you open a support request that needs someone in your workspace, support asks for the workspace and states the reason; the grant records both. Revocation is immediate and also recorded.

Where to go next

• Audit and evidence: reading the trail.
• Organizations and tenants: how access is decided for everyone else.