Skip to main content
Nightshift is built for agents to do real work in — which only makes sense if every action is governed. The policy system is that governance: every single statement, whether it comes from you in the console, Claude over MCP, or a published app, is authorized against the same model before it touches your data. The good news: you rarely have to think about it. Defaults are sensible, agents see and respect the same boundaries you do, and there’s exactly one model to understand.

​
The model

Access in Nightshift is a set of grants. A grant answers three questions:
Who (an org member, or an API token) can do what (read, update, delete) to which object (a table, view, notebook, or app)?
A grant can also apply to all objects of a kind instead of one — that’s what we call a capability. The capabilities you’ll encounter: That’s the whole vocabulary. There’s no separate permission system for the console, the MCP server, and apps — they all resolve to these grants.

​
The defaults

  • Deny by default. A member (or token) with no grant on a table can’t read it — and can’t confirm it exists.
  • You own what you create. Creating a table, view, notebook, or app automatically grants you update and delete on it.
  • Write implies read. Update or delete access to an object includes read access. Create doesn’t imply anything about existing objects.
  • Owners and admins skip grant checks. They can act on anything in the org (the platform-wide guardrails below still apply to them).
There is also one delegation rule, and it’s the same everywhere: you can only grant access you already hold. Sharing an app, granting a teammate read on a table, minting a token — all of it is bounded by your own access. Admins can grant anything.

​
Roles

Org members have one of three roles:
  • Owner / Admin — bypass grant checks, manage invites, tokens, and the audit log.
  • Member — governed by grants. Members can still share and delegate freely — just never beyond what they hold themselves.

​
Tokens

An API token (nsk_…) is a scoped identity you mint from the Tokens page in the console. Tokens are how anything non-human authenticates: a headless agent, a CI job, a Fiber app’s dev environment. What makes them safe to hand out:
  • A token holds an explicit list of grants, chosen when you mint it — and it can only carry access you hold (the delegation rule again). It’s an attenuated copy of you, never an amplified one.
  • Never admin, pinned to one org. Even an admin’s token is a plain grant-scoped identity.
  • The secret is shown once, at creation. Nightshift stores only a hash and a display prefix.
  • Expiry and revocation are built in, and every token shows its last-used time — so stale credentials are easy to spot and kill.
When you connect Claude to Nightshift through the standard OAuth flow, it acts as you — your grants, your role. That’s usually what you want: it’s convenient, and everything it does is attributed and audited. Mint a scoped token instead when something runs unattended, or when you deliberately want a narrower blast radius.

​
What a denial looks like

When an action isn’t allowed, the answer is a plain, specific error — for example:
Agents read these too. In practice Claude will hit a denial, understand exactly what’s missing, and either work within its access or tell you what grant it needs — no silent failures, no guessing.

​
Platform guardrails

A few rules apply to everyone, including owners and admins:
  • No side doors into or out of the warehouse. Statements like COPY, ATTACH, INSTALL, and direct file reads (read_csv, read_parquet, s3://… paths) are blocked in queries. External data comes in through Add Data, where credentials are managed properly — never pasted into SQL.
  • No secrets in SQL. CREATE SECRET is blocked for the same reason.
  • One statement per request. Every statement is authorized individually; there’s no smuggling a write inside a batch.

​
How apps fit in

Published apps are the policy system’s showcase: at publish time, every query in the app is vetted under the publisher’s grants and frozen into the app’s manifest. At runtime the app runs under its own identity and can execute only those manifest entries. Viewers get the app’s output without holding — or needing — any grant on the underlying tables. See Apps and Sharing.