# Blank — full documentation > The complete useblank.dev/docs, concatenated for machine reading. Source: https://useblank.dev/docs # Getting started > What Blank is, how it works, and how to roll it out. Discover the AI tools already in use, catch sensitive data on the way in, and coach in the moment. Blank is a managed browser extension. It finds the AI tools already in use across your company, catches secrets and customer data on the way into them, and coaches people in the moment, without blocking the tools they rely on. An administrator deploys it through browser management (Chrome and Edge). Employees don't install it themselves. It runs only on AI-tool pages, and only the *finding* ever leaves the browser. The content someone typed never does. ## How it works Blank follows three steps, in order. 1. **Discover.** Find the AI tools running across your fleet, including ones no catalog has heard of yet. What comes back is a hostname and a count. Never a URL, never a keystroke. 2. **Monitor.** Watch what's on the way out. When a secret, credential, or customer record is about to be sent to an AI tool, Blank records the finding: the detector that fired, the severity, and where. The matched text stays in the browser. 3. **Coach.** When something genuinely sensitive is about to go out, the employee gets a quiet in-page note. They can remove it or say it's fine, and keep working. Blocking is an optional policy you turn on later. You can't coach what you haven't measured, so every deployment starts in monitor-and-coach mode and blocks nothing until you decide to. ## Roll it out in three moves 1. **[Deploy](/docs/deploy/)** Blank to your fleet through Chrome or Edge browser management. Devices enroll automatically with your organization token. 2. Watch your shadow-AI footprint appear in the [dashboard](/docs/dashboard/): which AI tools, on how many devices, and the sensitive data heading into them. 3. When you're ready, turn on [coaching or enforcement](/docs/policy/), per detector or per tool, at your own pace. ## In this guide - **[Deploying Blank](/docs/deploy/):** force-install by MDM for Chrome and Edge. - **[The admin dashboard](/docs/dashboard/):** discovery, detections, extensions, policy, and alerts. - **[Policy and enforcement](/docs/policy/):** monitor, coach, and block modes, and the rules that drive them. - **[SSO and SCIM](/docs/sso/):** SAML sign-in and directory provisioning. - **[Privacy and data handling](/docs/privacy/):** what Blank collects, what it never sees, and how long it's kept. Prefer machine-readable docs? Every page has a Markdown twin, linked at the bottom, and the whole set is at [/llms-full.txt](/llms-full.txt). --- # Deploying Blank > Force-install Blank across your fleet with Chrome and Edge browser management, enroll devices with your organization token, and verify the rollout. Blank is a **managed** extension. Employees don't install it. An administrator force-installs it across the fleet through browser management, and each device enrolls automatically with your organization token. Managed installation is also what unlocks Blank's network-layer enforcement, which the browser grants only to policy-installed extensions. ## Before you start - Admin access to your browser management console: the Google Admin console (Chrome), Microsoft Intune or Group Policy (Edge), or your MDM of choice. - Your **organization token** from **Settings → Deployment** in the dashboard. It ties each enrolled device to your organization. - The Blank extension ID and update URL (its Chrome Web Store or Edge Add-ons listing). ## Chrome (Google Admin console) 1. Go to **Devices → Chrome → Apps & extensions → Users & browsers**, and select the org unit to cover. 2. Add the Blank extension by ID and set the installation policy to **Force install**. 3. Under the extension's **Policy for extensions**, provide the managed configuration so devices enroll silently: ```json { "orgToken": { "Value": "YOUR_ORG_TOKEN" } } ``` Force-installed extensions can't be disabled or removed by the user, and the managed configuration is delivered by policy. There's no per-user setup and no sign-in. ## Edge (Intune or Group Policy) Edge uses the same Chromium management model. 1. In **Intune → Configuration profiles** (or Group Policy), configure **Microsoft Edge → Extensions → Control which extensions are installed silently**, and add the Blank extension. 2. Deliver the same managed configuration (`orgToken`) via the Edge extension policy. ## Verify the rollout - Within a few minutes of a device applying the policy, it enrolls and begins reporting. Enrolled devices and their installed-extension inventory appear under **Extensions** and across the [dashboard](/docs/dashboard/). - A device that isn't policy-installed still runs the DOM-layer protection, but the network-layer backstop is inactive. The dashboard flags those devices as "enforcement is DOM-layer only" so you can spot a misconfigured rollout. ## Rotating the token Change the token value in your management console and the browser pushes it to devices, with no reinstall. Blank re-enrolls under the new token and keeps the same device identity. --- # The admin dashboard > A tour of the Blank dashboard. Overview, tool discovery, detections, installed extensions, policy, alerts, and settings. The dashboard is where you see your shadow-AI footprint and decide what to do about it. It's at **useblank.dev/admin**, and access is controlled by role (see [roles](#roles)). ## Overview The landing view is your fleet at a glance: how much AI use is happening, which tools dominate, and where sensitive data is heading. It reads from a daily rollup, so it stays fast even across millions of events. ## Tools Every AI tool Blank has seen across your fleet, with how many people and how many devices use each one. Tools Blank doesn't yet recognize show up as **candidates**: real tools your employees are already using that aren't in the catalog yet. From here you review a candidate and sanction, block, or dismiss it. ## Detections The findings themselves: which detector fired (an AWS key, a credit-card number, a bulk export of personal data), the severity, the tool, and how often. Never the matched text. Drill into a detection to see the pattern behind it and act on false positives, which make the detector quieter over time. ## Extensions An inventory of the browser extensions installed across your fleet, with the AI tools and the ones that can read every page called out. This is where a device reports whether Blank's network-layer backstop is active or the deployment is DOM-layer only. ## Policy The rules that turn monitoring into coaching or blocking, by detector, tool, tool category, or user group. See [Policy and enforcement](/docs/policy/) for how precedence and the enforcement modes work. A 30-day preview shows the impact of a rule before you enable it. ## Alerts Route notable findings to email or your SIEM. Alerts are de-duplicated so one noisy tool doesn't bury you, and the full event stream is available as an NDJSON export for your own pipeline. ## Settings - **Deployment:** your organization token for [rollout](/docs/deploy/). - **Enforcement mode:** the fleet-wide posture of monitor, coach, or block. - **Single sign-on:** SAML and SCIM ([setup](/docs/sso/)). - **Privacy:** pseudonymization and retention ([details](/docs/privacy/)). ## Roles Access is enforced on the server, not just hidden in the UI. There are four roles. | Role | Can do | |---|---| | **Owner / Admin** | Everything: read, change policy, manage members, export. | | **Auditor** | Read and export, but not change policy. | | **Viewer** | Read only. | Members arrive by invitation, by SAML domain auto-join, or by SCIM provisioning. --- # Policy and enforcement > How Blank's enforcement modes work (monitor, coach, and block), the 14-day gate, policy rules and precedence, the Block precision gate, and custom detectors. Blank starts by watching, and does nothing louder until you decide to. Enforcement is opt-in, and it's designed so you never escalate faster than your data supports. ## Enforcement modes Your organization has one fleet-wide **enforcement mode**, and it's the ceiling on everything. - **Monitor** (the default). Record every finding, coach nothing, block nothing. This is where every deployment begins. - **Coach.** Show the employee an in-page note when a medium-or-higher finding is about to be sent. They can remove it or proceed. It's a nudge, not a wall. - **Block.** Cancel a send that policy says must not go out. The effective action is always the *quieter* of the fleet mode and any rule, so an org in Monitor coaches nothing no matter what a rule says. ## The 14-day gate You can't escalate past Monitor until the org has **14 days of real data**. Coaching people about a picture you haven't actually measured is how you lose their trust, so the gate makes sure the baseline is real first. Pulling the brake back down to Monitor is never gated. An admin mid-incident shouldn't have to wait. ## Policy rules Within Coach or Block mode, rules decide what happens to a specific finding. A rule targets any combination of four axes: - the **detector** that fired (for example, `credit-card`), - the **AI tool** (for example, ChatGPT), - the tool's **category** (for example, chatbot), - the **user group**. When several rules match, the most specific wins (detector beats tool beats category beats group), then an admin priority, then the more restrictive action. A narrow exception can sit on top of a broad rule without deleting either. Every change is versioned with who changed it and a readable diff, and a **30-day preview** shows how many findings a rule would have affected before you turn it on. ## The Block precision gate You can't enable **Block** on a detector until it has cleared a **95% precision floor**: enough real detections to judge, with a low-enough false-positive rate. Blocking on a noisy detector is blocking someone's actual work, so the gate is enforced on the server, not just hidden in the UI. Tool-wide and category-wide Block rules span many detectors and are allowed. A single-detector Block waits until that detector has earned it. ## Coaching has a severity floor Blank records every finding but only *interrupts* at medium severity and up. Low-risk findings, like a colleague's email address or a phone number, are on your usage picture but never in an employee's face. The vocabulary is closed and ours, so it can't be gamed by an odd value. ## Custom detectors Beyond the built-in detectors, you can add your own patterns, like an internal project codename or a customer-ID format. Each one is safety-checked (including against catastrophic regular expressions) before it's allowed to run on employees' machines. --- # SSO and SCIM > Set up SAML single sign-on with domain auto-join and SCIM directory provisioning for Okta and Microsoft Entra ID. Blank supports SAML 2.0 single sign-on and SCIM provisioning. SSO is configured in **Settings → Single sign-on (SAML)**. ## How membership works - **Domain auto-join.** A SAML login whose email domain matches your configured domain auto-joins your organization at the **default role** you set (default: viewer). - **SCIM overrides the role.** If your identity provider has pushed a roster entry for that user (say, provisioned as an admin), that role wins. To sign in, the user types their work email and clicks **Sign in with SSO**. Blank resolves the provider by domain and redirects to your IdP. Launching from the IdP's app tile works too. ## Service-provider details Give these to your IdP. They're shown in **Settings → Single sign-on (SAML)**. | Field | Value | |---|---| | ACS / Reply URL | `https://.supabase.co/auth/v1/sso/saml/acs` | | Entity ID / Audience | `https://.supabase.co/auth/v1/sso/saml/metadata` | The assertion must send the email as the NameID. The account and domain auto-join are keyed on it. ## Okta 1. Okta Admin → **Applications → Create App Integration → SAML 2.0**. 2. Set **Single sign-on URL** to the ACS URL, and **Audience URI** to the Entity ID. 3. Set **Name ID format** to `EmailAddress`, and map the application username to the user's email. 4. Assign the app to the users and groups who should have access. 5. Copy Okta's **Identity Provider metadata URL** (App → Sign On). 6. In Blank, enter your **email domain**, paste the **metadata URL**, pick the **default role**, and **Configure SSO**. ## Microsoft Entra ID 1. Entra admin → **Enterprise applications → New application → Create your own** (non-gallery). 2. Under **Single sign-on → SAML**, set **Identifier (Entity ID)** and **Reply URL (ACS)** from the table above. 3. Under **Attributes & Claims**, set the email from **`user.userprincipalname`** in **both** the **Name ID** (format: Email address) **and** the email-address claim. Don't leave these on `user.mail`. A bare `*.onmicrosoft.com` tenant has no mailbox, so `user.mail` is empty and the login is rejected. The UPN is the only email-shaped value. 4. Set **Basic SAML Configuration → Relay State** to your dashboard URL (`https://useblank.dev/admin/`). This is where an IdP-initiated login lands. 5. Assign users and groups, then copy the **App Federation Metadata URL**. 6. In Blank, enter the **email domain** (for `*.onmicrosoft.com` users that's `.onmicrosoft.com`), paste the metadata URL, pick the **default role**, and **Configure SSO**. ## Deprovisioning Remove a user's app assignment, or push SCIM `active:false`, and their access is gone on their next request. Blank re-checks membership on every request, so revocation is effectively immediate. --- # Privacy and data handling > What Blank collects and what it never sees, how identities are pseudonymized, how long data is kept, and the sub-processors involved. A tool that watches your team only earns that if it collects almost nothing. Blank is built so you can prove it does. This is the operational summary. The full legal policy is at [useblank.dev/privacy](/privacy). ## What Blank collects On AI-tool pages in its catalog, Blank reports events about AI-tool use: - which catalogued AI tools are visited; - **detections:** the detector that fired, its severity, and the position and length of the match; - unknown AI tools ("candidates"), which is the domain of a tool not yet in the catalog; - an inventory of the browser extensions installed on the device; - enforcement events, meaning that a coaching prompt was shown or a request blocked. Each device carries an identifier and your organization's enrollment token. ## What it never collects Blank does not send the text you type or paste, the secret or personal data that trips a detector, the contents of the pages you visit, your keystrokes, or your passwords. Only the finding leaves the browser, never the matched content. It does not run, or report, on anything outside catalogued AI tools. ## Pseudonymization You can turn on a mode that replaces the device identifier with a pseudonym everywhere it appears, in dashboards and exports. Re-identifying a specific person is then a deliberate, logged action that requires a **second administrator's approval** and is limited to a 24-hour window. It's one-way by default, and the exception is governed and recorded. ## Retention and deletion Event data is kept for the window associated with your plan and then deleted automatically. You can request deletion of your organization's data at any time, and it's honored after a short, reversible grace period. Deletion certificates and the audit log are append-only, so they can't be quietly rewritten. ## Where data is processed Blank runs on a small set of service providers, each required to protect data and use it only to run the service: **Supabase** (database and authentication), **Netlify** (hosting and serverless functions), **Stripe** (billing), **Resend** (transactional email), and **Google** (optional administrator sign-in). Blank is operated from the United States. For the complete policy, including controller and processor roles, data-subject rights, and international transfers, see the [privacy policy](/privacy).