Who can see what

Your people see what their roles allow; API security lists the roles. This page is about the other side: what Atlantic’s own staff can see and do in your tenant, and how you see it happen.

Who counts as Atlantic staff

Only a person signed in through Atlantic’s own identity provider, with an Atlantic email address or Atlantic’s staff group membership, and a second factor. Either alone is not enough: an Atlantic address signed in through your identity provider is one of your people, and a stranger on Atlantic’s provider is nobody. No access rule in your tenant can name Atlantic.

What staff can see

What	Can staff see it?	How it is recorded
Operational telemetry: health, cost, runs, refusals, evaluations	Yes, as viewer, to support you	Every staff read is recorded in your audit log as aal_staff_read (at most hourly per person and view), with their identity provider type
Your content, read in place	Only if your rules allow it. Your administrator sets aal_staff_role: content_viewer; the default gives staff no content access	Every read is in your audit log as content_read, raises a staff content-read event, and is logged in your account by your content reader
Administration: your access rules, keys, command settings, billing	No. Staff never hold client_admin	Not applicable: refused
Commands on your agents (pause, approve)	Only if your command settings allow it, which they do not by default	Every staff command is flagged in your audit log

Atlantic’s staff console reads one tenant at a time, under that tenant’s own row-level security scope, and carries no content.

Break-glass

Two separate things go by this name. Both are off by default and both leave a mark you can see.

Atlantic changing your access rules

Atlantic can change your tenant’s access rules only through a break-glass path, for example to restore access when your only administrator has left. It works under the same guard rails as any change (at least one administrator remains, MFA stays on, Atlantic gets at most content_viewer), and it requires a reason.

The change is recorded in your audit log with that reason and flagged break_glass: true, and your access rules carry the same flag. The flag stays until your own administrator next saves the rules, so it cannot pass unseen.

Your own approval break-glass

Where approvals are managed by LightHouse, your engine accepts approvals only as signed commands from LightHouse. You can turn on a local break-glass for named people, so that work can be approved if LightHouse is unreachable. A decision taken that way records break_glass: true in your account and sends an override record, which LightHouse writes to your audit log, flagged. It is off by default.

Suspension

Atlantic can suspend a tenant, with a reason. While suspended, your people and machine keys cannot sign in or read; your deployments keep running and sending telemetry. Resuming is also recorded with a reason. See Suspension.

What you see of it

• The access review: Settings → Users and roles, or GET /api/v1/access/review?format=csv. Who holds which role by which grant, their last sign-in, every key, and every Atlantic staff read.
• The audit log: Setup and admin → Audit, or GET /api/v1/audit. Filter on aal_staff_read, content_read and anything with break_glass: true.
• Your reader’s log, in your account, for every content read, whoever made it.

The first two need a client_admin signed in as a person.