> ## Documentation Index
> Fetch the complete documentation index at: https://autopilot.docs.xano.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Control

> Dashboard authentication, role- and namespace-scoped authorization, self-service access requests, and an audited login trail — all opt-in behind a single feature gate.

Autopilot's dashboard ships **open on an internal cluster** and **locked down when you need it
to be** — both behind one feature gate, `auth.enabled` (default **false**). Turning it on adds
sign-in, role- and namespace-scoped authorization, an access-request queue, and an audited
login trail, with a single enforcement point in the server.

<Note>
  With `auth.enabled=false`, the dashboard behaves exactly as it always has — any reachable
  client has full access. Authentication and every control below are inert until you enable it.
  This page covers the enabled state.
</Note>

## Signing in

Two methods, one active per cluster:

* **Xano** (default) — validates against a Xano instance.
* **Google OAuth/OIDC** — with hosted-domain enforcement. See the [Google OAuth setup runbook](/operations/dashboard-auth-google).

Either way, a user is resolved to a role by **email** against the cluster's `AccessPolicy` CRD.

## Roles and scope

Authorization is an `AccessPolicy` (a cluster singleton) plus per-user grants:

* **Roles** — `viewer` (read), `admin` (mutate + privileged tools). Read endpoints require viewer+; every mutation and every [pod tool](/operations/pod-tools) re-checks admin in-handler.
* **Namespace scope** — a grant can be limited to specific namespaces (glob patterns supported). A scoped user only ever sees and acts on their granted namespaces; an out-of-scope request returns an authorization error with no data. An empty scope means full access.
* **Super-admins** — a bootstrap list (`AUTH_SUPER_ADMINS`) that resolves to `admin` even with no `AccessPolicy` present. Unkillable via the API — your lockout insurance.
* **Domain allowlist + deny list** — a whole domain can be granted a default (suggested) role, and specific emails denied.

## Self-service access requests

A first-time authenticated user with no grant lands on an **access-request** screen instead of
a dead end. The request is deduplicated, rate-limited, and (optionally) sent to Slack. An admin
approves or denies it on the **Access Control → Pending Requests** page — approval writes the
grant, denial optionally adds the email to the deny list. Every decision is audited.

## Audit trail

Every login, access request, approval/denial, and privileged action (including every [pod
tool](/operations/pod-tools) open) writes a typed event to a shared audit ring, surfaced on the
**Auth Events** page (`GET /api/v1/access-events`) and durably to Cloud Logging. Filter chips
separate login events from terminal/logs/files events.

## API keys (for the MCP server)

For non-interactive clients, an admin can mint a long-lived, revocable, **read-only** API key.
A key resolves only to an email — the role and namespace scope are read live from that email's
grant on every request, so revoking or re-scoping the grant instantly re-scopes the key. Only a
hash is stored; the plaintext is shown once. See the [MCP server reference](/reference/mcp-server)
for how a client uses it.

## Enabling it

```yaml theme={null}
auth:
  enabled: true
  method: xano            # or google
  superAdmins:
    - you@xano.com        # bootstrap admin(s), unkillable
```

Public exposure adds a safety interlock: when the dashboard is exposed via an ingress **and**
auth is off, the `/mcp` endpoint and the API-key management endpoints fail closed (503) — a
public, unauthenticated cluster can never serve those.