# Support access and break-glass

How Tanomis support can act inside your workspace, what a support grant contains, and where you see it.

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.

- 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.

```bash title="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](/guides/audit/audit-and-evidence): reading the trail.
- [Organizations and tenants](/concepts/organizations-and-tenants): how access is decided for
  everyone else.