# Advanced Topics Source: https://docs.nightshift.sh/advanced-overview Becoming a Nightshift power user The most important thing to internalize about Nightshift is that it's a platform built to be consumed by Agents. This might be awkward at first because most of us are used to working with SaaS through the SaaS provider's UI. We indeed have a UI we call `console` but it's more of a way for humans to audit the work done by an Agent. We've designed Nightshift to fit into the "auto" workflow as much as possible which is what we describe (rather informally) as: * Prompt Claude (or any other agent) to research across a bunch of structured or unstructured data * process data like running aggregations, groups, cleaning operations, etc. * create stateful catalogs, tables, and views * integrate these data objects into dashboards or live applications We say this because the main way you'll interface with Nightshift is through an Agent over our [MCP server](/). When adopting this new platform, there are a few things you should know to get the most out of Nightshift and this is what this guide is for. We'd recommend starting with [Apps](/apps), then working through the rest: Hosted data applications, built by your agent Saved, re-runnable SQL analysis How access works — for people, tokens, and agents Every change recorded, every change reversible Give teammates access to apps, notebooks, and data Habits that make agent-driven data work go well # Apps Source: https://docs.nightshift.sh/apps Real, hosted data applications — built by your agent, governed by Nightshift Nightshift Apps are real-time, stateful applications built and deployed through Nightshift's remote build system. Claude uses our MCP server as a development environment: it writes the application code, submits it, and Nightshift compiles, checks, and hosts it — no local toolchain involved. A published app lives at `apps.nightshift.sh//` where anyone you've [shared it with](/sharing) can open it. ## How an app gets built Ask Claude for an app ("build me a revenue dashboard with a region filter") and this is what happens under the hood: 1. **Claude inspects your warehouse** — listing objects and describing schemas so it writes queries against your real tables, not guesses. 2. **It writes a small React app** using the Fiber SDK (more below) and submits the source to Nightshift's build service. 3. **Nightshift compiles it against your live warehouse.** Every query in the app is type-checked against the actual schema — a misspelled column or invalid SQL fails the build with the warehouse's own error, *before* anything ships. Claude reads the errors, fixes the source, and resubmits. 4. **On success, the app is live** — hosted, versioned, and ready to open. This loop is why apps built by an agent are trustworthy: nothing reaches production unless it compiles cleanly against your real data. ## The Fiber SDK Application code is written with **Fiber**, our React SDK for governed data apps. Fiber lets code define SQL queries with bound parameters, get precisely typed rows back, and render them with a built-in set of charts, tables, and KPI components — which is exactly the feedback loop that helps Claude drive toward working software quickly. A flavor of what that code looks like: ```tsx theme={null} const revenueByMonth = defineQuery(` SELECT strftime(sale_date, '%Y-%m') AS month, sum(amount) AS revenue FROM sales WHERE ($region = 'all' OR region = $region) GROUP BY 1 ORDER BY 1 `) function App() { const [region, setRegion] = useAppState("region", "all") // filter state, synced to the URL const q = useQuery(revenueByMonth, { region }) return } ``` Queries are static and parameterized (never string-built), filter state lives in the URL so any view of the app is shareable by link, and apps can even define managed read/write tables for their own state. Developers can also build Fiber apps by hand with a local toolchain — `npx @nightshift-sdk/create-fiber-app` scaffolds a Vite project, and `fiber publish` ships it to the same hosting. If you're interested in how Fiber works under the hood, read more [here](https://nightshift.sh/fiber). ## Identity: development vs. published Like everything in Nightshift, apps are tied to our [policy system](/policies). While Claude is building, its queries run under *your* identity (or the scoped token you've given it) — it can only see what you can see. Publishing changes that. A published app no longer makes queries as you — it runs under **its own identity**, and what it's allowed to do is frozen at publish time into what we call the **manifest**. The manifest is a frozen-in-time set of queries (and, for read/write apps, table operations) extracted from the app's source and vetted under the publisher's access. At runtime, the hosted app can execute *only* manifest entries — arbitrary SQL from a browser is simply not runnable. This is a security feature, and it's what makes sharing apps with many users safe. You can think of an app as a composed view: people you share it with see the data the app presents, without needing (or receiving) access to the underlying tables. If that sounds like a lot — don't worry. There's nothing you need to do to get this behavior; it all happens automatically on every publish. ## Versions Every publish creates an immutable **version** carrying the exact source, the built bundle, and the manifest. The live URL always serves the current version; older versions remain pinned and inspectable. In the [console](https://console.nightshift.sh), an app's detail page shows a live preview, its published source and manifest, and the full version history — so you can always answer "what exactly is this app allowed to run?" Creating an app requires the `app:create` capability. If Claude authenticates as you through the standard flow, it acts with your access — which is usually the convenient and reasonable choice. Mint a scoped [token](/policies#tokens) instead when you want tighter control. ## Next steps * [Sharing](/sharing) — give teammates access to run or manage an app * [Policies](/policies) — the grant model apps are built on * [Organizing site analytics data](/organizing-site-analytics-data) — an end-to-end example that finishes with a published app # Audits Source: https://docs.nightshift.sh/audits Every change to your warehouse, recorded as a snapshot — and reversible If agents are doing the work, humans need a way to check the work. That's what the audit surface is for: a complete, append-only history of every change to your warehouse, with the ability to roll back when something shouldn't have happened. ## The audit log Every write to the warehouse — a table created, rows inserted, an object dropped — commits a **snapshot**. The audit log (in the [console](https://console.nightshift.sh) under **Audit**, admins only) is that snapshot history, newest first. Each entry records: * **Who** made the change (the member or token) * **When** it happened * **What changed** — which tables were created, written to, or dropped * A commit message describing the operation Because snapshots are the unit of change, the log can't drift from reality: if the warehouse changed, there's a snapshot; if there's no snapshot, nothing changed. You'll also see the snapshot count and the time of the last snapshot at a glance on the org **Overview** page. ## Rolling back Every snapshot in the audit log has a **Restore** action. Restoring rolls the warehouse (and its data) back to exactly how it was at that snapshot — tables created since are dropped, modified tables are re-materialized as they were. Two properties make this a safety net rather than a footgun: * **Rollback is forward-only.** Restoring doesn't erase history — it writes a *new* snapshot (`rollback to snapshot N`) on top. The audit log keeps everything, including the rollback itself and the state you rolled away from. * **It's governed like everything else.** Restoring requires admin or the *Restore snapshots* capability. This is worth internalizing, because it changes how freely you can let an agent work: **mistakes in Nightshift are cheap.** If Claude reorganizes your tables in a way you don't like, you're one Restore away from before it started. ## What else leaves a trail The snapshot log covers changes to warehouse data. A few other records round out the picture: * **Notebook results are snapshots too.** Each [notebook](/notebooks) cell keeps its last-run result with a timestamp, so you can see not just what SQL an agent wrote but what it saw — and whether the SQL was edited after the fact. * **App versions are immutable.** Every [app](/apps) publish is recorded as a version carrying the exact source and query manifest, inspectable in the console on the app's detail page. Failed builds are recorded as well. * **Tokens show their last use.** The Tokens page shows when each credential was last exercised, making stale or unexpected usage visible. ## Reviewing an agent's session A practical pattern after a heavy agent session: 1. Open **Audit** and skim the snapshots from the session — do the changes match what you asked for? 2. Spot-check the [notebook](/notebooks) it saved: the queries and their snapshotted results are the reasoning trail. 3. If anything's wrong, **Restore** to the snapshot before the session and refine your prompt. That loop — act freely, review cheaply, revert instantly — is the workflow Nightshift is designed around. # General Best Practices Source: https://docs.nightshift.sh/best-practices Habits that make agent-driven data work go well Nightshift's design does most of the safety work for you — every action is [governed](/policies), every change is [auditable and reversible](/audits). What's left is a handful of habits that make the difference between an agent that flails and an agent that ships. ## Ground the agent before you build Start sessions with a look around: > "What data do I have in Nightshift? Describe the tables I'd need for revenue analysis." An agent that has listed your objects and read your schemas writes correct SQL on the first try far more often than one working from your description of the data. This costs one prompt and pays for itself immediately. ## Build durable shape, not piles of copies The order of preference for making data useful: 1. **Views first.** They're free, always current, and they turn "the query Claude figured out last Tuesday" into a named object every future conversation can build on. 2. **Tables when you mean it** — materialize when the transform is expensive or you need a stable snapshot to work against. 3. **Avoid one-off copies.** `sales_final_v2_new` is how warehouses rot. If an agent session produced clutter, say so — cleanup is one prompt, and [rollback](/audits) has your back. Name objects for what they mean (`daily_pageviews`, `active_customers`), not for when they were made. The names become the vocabulary you and the agent share. ## Put work where it lives longest * **A question** → just ask; a query in chat is fine. * **A read on the data right now** → ask for a dashboard in chat. * **Analysis you'll rerun or hand off** → have Claude save it as a [notebook](/notebooks). * **Something the team opens every week** → have Claude publish an [app](/apps). The common failure mode is stopping one level short: a great analysis that lives only in a chat transcript. If it was worth doing, it's usually worth one more sentence — "save that as a notebook." ## Let the agent act as you — scope tokens for automation For interactive work, connecting Claude through the standard flow (acting as you) is the right default: full visibility, full attribution in the [audit log](/audits), zero setup. Reach for a scoped [token](/policies#tokens) when: * something runs **unattended** (scheduled jobs, CI, a server), * you're handing access to a **narrower context** and want a smaller blast radius, * an **app or integration** needs its own standing identity. When you mint one: fewest grants that do the job, set an expiry, and check the Tokens page occasionally — last-used timestamps make dead credentials obvious. ## Review like it's cheap — because it is Don't pre-approve every step of an agent's work; review it afterward instead. The platform is built for exactly this: * The **Audit** log shows every change from the session as snapshots. * Notebook cells keep the queries *and* their results. * **Restore** undoes anything, without losing history. Trusting the agent with real writes and reviewing after is faster than supervising every statement — and in Nightshift it's just as safe. ## Bring data in the front door External data enters through **Add Data** (or your connectors) — not through SQL. Queries can't read files, URLs, or credentials by design, so don't ask the agent to `COPY` from a bucket; ask it to load the data through a connector instead. Credentials live in Add Data's managed configuration, never in SQL text. ## Share the artifact, not the warehouse When someone needs numbers, share the [app or notebook](/sharing) that presents them — not read access to the underlying tables. Apps in particular are built for this: viewers see the output with no grants on the source data. Save table-level grants for people who genuinely need to query the data themselves, and review **Access → Grants** now and then. # Examples Source: https://docs.nightshift.sh/examples-overview See what working with Nightshift actually looks like The best way to understand Nightshift is to watch a real task go end-to-end: prompt an agent, let it query and organize your data, and end up with something durable — a set of clean views, a saved notebook, or a live app. Each example is written as a conversation you can replay. The prompts are real prompts; you can paste them into Claude (with the Nightshift connector [set up](/)) and follow along against your own data. Take a raw stream of page-view events and turn it into clean views, a KPI dashboard, and a shareable traffic app. More examples are on the way. If there's a workflow you'd like to see covered, tell us at [nightshift.sh](https://nightshift.sh). # Get Started Source: https://docs.nightshift.sh/index Nightshift Getting Started. Nightshift is a platform for your agents to do data work. You can think of Nightshift as the "batteries included" data api for agents. With Nightshift, agents like Claude can: * Perform batch data operations * Run analytical processing on your data * Build and maintain query notebooks * Build and maintain real time data driven applications Nightshift is not yet generally available. If you want access please sign up at [nightshift/signup](https://www.nightshift.sh/signin) and one of our engineers will reach out to get you onboarded. ## Overview To get started, go to [claude.ai](https://claude.ai) In the sidebar menu, click on customize Then, click on "Connectors" and Add > Add custom connector Add the name Nightshift to the name field, and *[https://mcp.nightshift.sh](https://mcp.nightshift.sh)* for the remote server URL. This URL is the entry point into our official Nightshift Remote MCP server. You can now go back to the chat input and ask Claude to build you a sample Nightshift app. You should be able to see Claude work through queries, intermediate results, and eventually ship an application. This is cool but probably not useful for you yet. Well, not until you have your data inside of Nightshift. You can add data in a number of ways. We have connectors for real time streaming, offline batch loaders, and other necessary tooling for you to load your data. However, the easiest way is to just have Claude do it. Depending on the connectors you have enabled, Claude can compose over those connectors and load data into Nightshift. Just ask... ## Where to go next Look at example of how you can be productive with Nightshift For Admins and Power Users # Notebooks Source: https://docs.nightshift.sh/notebooks Saved, re-runnable SQL analysis — built by your agent, auditable by you A notebook is a named list of SQL cells stored in Nightshift. It's the natural home for analysis you want to keep: the agent writes the queries, runs them, and the results are snapshotted so you (or anyone on your team) can review the work later without re-running anything. Notebooks are the middle ground between a one-off query and a full [App](/apps): | | Lives where | Best for | | ------------- | -------------------------------- | ------------------------------------------- | | **Query** | The chat | Quick questions, exploration | | **Notebook** | Saved in Nightshift | Analysis you'll revisit, rerun, or hand off | | **Dashboard** | Rendered in chat | A visual read on the data, right now | | **App** | Deployed at `apps.nightshift.sh` | Live, shareable, always-current | ## Creating a notebook Just ask. A prompt like: > "Explore last month's orders and save your working queries as a notebook called *Monthly Revenue*" will have Claude create the notebook and fill it with SQL cells as it works. A few things worth knowing about how this behaves: * **Cells don't run on creation.** Adding a cell just saves the SQL. A cell only executes when it's explicitly run — so a notebook can be drafted end-to-end before anything touches your data. * **Running a cell snapshots the result.** When a cell runs, its result (columns, rows, row count, and when it ran) is saved onto the cell. That snapshot is what renders in chat and in the console. * **Stale results are flagged.** If a cell's SQL is edited after its last run, the saved result is marked as *"query edited since, run to refresh"* — you'll never mistake an old answer for a current one. ## Running notebooks from chat When Claude shows you a notebook in chat, it's not a screenshot — it's live. Each cell has a **Run** button, and there's a **Run all** for the whole notebook. Clicking Run executes that cell's SQL through your Nightshift identity, so the same [policies](/policies) that govern the agent govern the button: if you can't read a table, neither can the cell. This makes notebooks a nice handoff artifact. The agent does the analysis, you press Run a week later to refresh the numbers. ## Notebooks in the console Every notebook is visible in the [console](https://console.nightshift.sh), with its cells, saved results, and run timestamps. Since results are snapshots, the console shows you exactly what the agent saw when it ran the query — which makes notebooks a lightweight audit trail for how a conclusion was reached. ## Tips * **One question per cell.** Cells are the unit of re-running and reviewing. A notebook of focused cells is easier to audit than one giant query. * **Promote reusable transforms to views.** If several cells share the same cleanup SQL, ask Claude to create a view and query that instead. Notebooks are for analysis, views are for shared shape. * **Name notebooks for the question they answer.** "Churn by signup cohort" beats "analysis-2". Future-you is the audience. # Organizing site analytics data Source: https://docs.nightshift.sh/organizing-site-analytics-data From a raw event stream to clean views, a dashboard, and a live app This example walks through a complete, realistic session: you have raw web analytics events landing in Nightshift, and by the end you'll have clean reusable views, a saved notebook, a KPI dashboard, and a live app your team can open. Every step is a prompt — the agent does the work. ## The starting point Say your site's page-view events land in a table called `site_events` — one row per event, straight from your tracker: | column | type | example | | ------------ | --------- | --------------------- | | `ts` | TIMESTAMP | `2026-07-12 14:03:22` | | `session_id` | VARCHAR | `s_8f3a…` | | `path` | VARCHAR | `/pricing` | | `referrer` | VARCHAR | `google.com` | | `country` | VARCHAR | `DE` | | `device` | VARCHAR | `mobile` | How the data gets there doesn't matter for this example — a streaming connector, a batch load, or just asking Claude to load a CSV export all end at the same place. ## Step 1 — Look around > **You:** What analytics data do I have in Nightshift, and what does it look like? Claude lists the objects in your warehouse, describes the schema of `site_events`, and runs a few exploratory queries — row counts, date range, top paths. This is read-only work, so it's a good first prompt in any session: it grounds the agent in your real schema before anything gets built. ## Step 2 — Organize it into views Raw events are the wrong shape for most questions. Ask for the shape you want: > **You:** Organize this into clean views: daily page views, sessions with duration and > entry/exit pages, and a referrer summary. Don't copy any data — I want views over the > raw events. Claude creates views like: ```sql theme={null} CREATE VIEW daily_pageviews AS SELECT date_trunc('day', ts) AS day, count(*) AS views, count(DISTINCT session_id) AS sessions FROM site_events GROUP BY 1 ``` Views are the key move here. They cost nothing to store, they're always current as new events land, and they become the shared vocabulary for everything downstream — the next conversation (yours or a teammate's) starts from `daily_pageviews`, not from re-deriving it. Creating tables and views requires the `objects:create` capability. If Claude is authenticated as you, you have it; a scoped token needs it granted explicitly. See [Policies](/policies). ## Step 3 — Save the analysis as a notebook > **You:** Save the interesting queries from this session as a notebook called > "Site traffic — weekly review". Claude creates a [notebook](/notebooks) whose cells hold the SQL — weekly trend, top landing pages, referrer mix, mobile share. Each cell it runs gets its result snapshotted, so the notebook in the console shows both the queries *and* the numbers as of today. Next week, open it and hit **Run all** to refresh. ## Step 4 — Get a dashboard in chat > **You:** Show me a traffic dashboard for the last 30 days. Claude renders a live dashboard right in the conversation — KPI tiles for views, sessions, and mobile share; a trend line; ranked referrers; a device breakdown. Panels run real queries against your views at render time. This is great for *right now* questions; it isn't saved anywhere, which is exactly why the views and notebook from the previous steps matter. ## Step 5 — Ship it as an app When the dashboard is worth keeping, make it permanent: > **You:** Turn that into an app called "Site Traffic" with a date-range filter and a > country filter, and publish it. Claude writes a small React app with the Fiber SDK, publishes it through Nightshift's remote build system, and gives you back a URL like `apps.nightshift.sh//`. The published app carries a frozen manifest of its queries — viewers see the traffic numbers without needing any access to `site_events` itself. See [Apps](/apps) for how that works. ## Step 6 — Share it From the [console](https://console.nightshift.sh), open the app and **Share** it with your team, or share the notebook with an analyst who wants to poke at the SQL — sharing a notebook can even invite someone into your org automatically. See [Sharing](/sharing). ## The pattern This shape — **explore → organize into views → save a notebook → render a dashboard → ship an app** — is the core Nightshift workflow, and it applies well beyond analytics data. The raw data stays put; each layer above it is cheap, governed, and rebuildable by the next prompt. # Policies Source: https://docs.nightshift.sh/policies How access works in Nightshift — for people, tokens, and the agents acting through them 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: | Capability | What it allows | | ---------------------------------------- | ------------------------------------------------------------ | | Create tables & views (`objects:create`) | `CREATE TABLE` / `CREATE VIEW` in the warehouse | | Create apps (`app:create`) | Creating and first-publishing apps | | Restore snapshots | Rolling the warehouse back to a previous [snapshot](/audits) | 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](https://console.nightshift.sh). 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](/audits). 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: ``` missing permission: table:update on sales ``` 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](/apps). 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](/apps) and [Sharing](/sharing). # Sharing Source: https://docs.nightshift.sh/sharing Give teammates access to apps, notebooks, and data — without handing over the warehouse Everything in Nightshift is private to your organization by default, and inside the org, access is granted per-object. Sharing is how you open up a specific app, notebook, or table to a specific person — nothing is ever exposed by an anonymous public link. ## Sharing an app Open the app in the [console](https://console.nightshift.sh) and hit **Share**. You pick: * **Who** — a teammate's email. For apps, they must already be a member of your workspace. * **Access level**: * **Run (view & run)** — they can open the app and use it. * **Manage (publish)** — they can also publish new versions. The app's **Access** table shows everyone who can open it — the owner plus each grant — and lets you revoke any of them inline. Remember that a published app runs against its own frozen [manifest](/apps), not the viewer's permissions. That's what makes app sharing safe: someone you share an app with sees the data the app presents, without needing (or getting) access to the underlying tables. App URLs (`apps.nightshift.sh//`) are sign-in gated. Sending someone the link isn't enough — they need to be a member of your org with access to the app. ## Sharing a notebook Same flow: open the notebook, hit **Share**, enter an email, and pick **Read**, **Update**, or **Delete** access. Notebooks have one extra trick: if the person isn't in your workspace yet, sharing **invites them automatically** — they get access to the notebook as soon as they accept and sign in. That makes "share a notebook" the fastest way to pull a new teammate into Nightshift around a concrete piece of analysis. ## Inviting teammates To add someone to the organization itself, go to **Access → Invites** in the console and hit **Invite member**. You choose their role: * **Member** — works with the objects they've been granted access to. * **Admin** — additionally manages tokens, access, and the audit log. The invite is a single-use link that expires in 7 days. Send it to them however you like — accepting it drops them straight into your org. ## Grants — the full picture The Share buttons are a friendly front-end over Nightshift's grant system, which admins can drive directly from **Access → Grants**. A grant is: > **who** (a member or an API token) × **what** (a table, view, or app — or a platform > capability) × **how** (read, update, delete) This is also where every share you've made lives, so **Access → Grants** is the one place to review and revoke access across the org. The same model governs agents: when Claude acts through a scoped token, that token's grants are just rows in this table. See [Policies](/policies) for how grants and capabilities fit together. ## What sharing is *not* There are no public, unauthenticated links in Nightshift today. Every route to your data — the console, the MCP server, a hosted app — requires a signed-in identity that holds a grant. If you need to show numbers to someone outside your org, invite them in and share the specific app or notebook they need.