Source Visibility
Restrict which analyst groups can see events from a given log source, enforced across search, alerts, detections, and AI.
Source Visibility
Source Visibility is a data-level access control: it restricts which analyst groups can see the events from a given log source. It sits alongside the permission-based RBAC system — permissions govern what actions a user can perform, while Source Visibility governs which data they can see.
Use it to scope sensitive sources — HR logs, executive-endpoint telemetry, an ongoing insider-threat investigation, a customer's data in a multi-team deployment — to only the groups that should have access.
The enforceable unit is the event-borne source_type string (for example apache_access, windows_event_log, microsoft_sysmon) — the same value you filter on with source_type=… in search. Scoping a source_type applies to every event tagged with it, across every table and profile.
The model
Source Visibility is driven by a restricted-source registry:
- Empty registry = allow-all. By default the registry is empty and every source is visible to everyone. Source Visibility only takes effect once you add a source to it.
- Listing a source makes it invisible-by-default. The moment a
source_typeis in the registry, its events are hidden from everyone — it is then visible only to the groups you explicitly grant. - Grants open it back up, per group. Grant a group and its members can see the source again. A source can be granted to any number of groups.
- The "Everyone" group re-opens it fully. Granting the built-in Everyone system group un-restricts the source for all users, without removing it from the registry — useful for temporarily lifting a restriction while keeping the entry.
This control is fail-closed, and administrators are not exempt. A restricted source with no grants is dark to everyone, including the admin who restricted it. If scope resolution ever fails, nano denies access to restricted sources rather than exposing them. Mis-configuration hides data — it never leaks it.
Accessing Source Visibility
Navigate to Settings → Source Visibility from the sidebar.
| Permission | Grants |
|---|---|
source_scopes:view | Read the registry and its grants |
source_scopes:manage | Add/remove restricted sources and grant/revoke groups |
Without source_scopes:manage, the management controls are hidden and the page is read-only.
Restricting a source
Open the restrict flyout
On Settings → Source Visibility, click Restrict a source. A right-side panel opens.
Choose the source type
Pick an ingested source type from the suggestions, or type any source_type string — the raw string is stored, so you can pre-restrict a source before it has ingested any events. Optionally add a description explaining why the source is restricted.
Confirm
On save, the source is added to the registry and immediately becomes invisible by default — no user (admin included) sees its events until a group is granted.
Grant the groups that should see it
Select the restricted source, click Grant group, and choose a group. Repeat for each group that needs access. Members of granted groups can see the source's events within a few seconds.
Restricting and granting are separate steps by design, so you can lock a source down instantly and decide the audience deliberately. If you restrict a source and grant no groups, the registry list flags it as restricted with zero grants — a valid but fully-dark state.
Managing grants
- Revoke a group — removes that group's access. Members lose visibility within a few seconds.
- Revoke the Everyone grant — re-restricts a previously un-restricted source to only its specific group grants.
- Remove restriction — deletes the registry entry and all its grants, making the source visible to everyone again.
Where scoping is enforced
Source Visibility is enforced at the point data is read or surfaced, not only in the search UI. A user who cannot see a source cannot reach its events through any of these paths:
| Surface | Behaviour for a denied source |
|---|---|
Search (nPL, including the lateral, asset, and cloud commands) | Its events are filtered out of every query and field statistic |
| Alerts | Alerts are stamped with the sources that produced them; an alert is hidden from any user who cannot see one of its sources |
| Alert payloads & notifications (Slack, Teams, PagerDuty, webhooks) | Matched-event detail from denied sources is stripped before an alert is surfaced or dispatched to a channel |
| Detections & signals | Detection matches and logged signals from a denied source are not returned |
| Identity resolution | Host/user PII resolved from a restricted source is dropped for users without the grant |
AI assistants & wizards (PIVT, @summarize, tuning, parser, detection generation) | AI surfaces operate only on sources the invoking user can see — they cannot enumerate or summarise denied-source data |
| Reports & SIEM health | Scheduled reports and health surfaces respect the viewer's visible sources |
Changes propagate across all services within a few seconds. After you restrict a source, grant, or revoke, allow a moment for every running query path to pick up the new scope.
Relationship to permission-based RBAC
Source Visibility and Access Control permissions are orthogonal and combine:
- Permissions decide whether a user can open Search, create detections, view alerts, and so on.
- Source Visibility decides which sources' events those permissions operate over.
A user with full search:execute permission still only sees events from sources they're granted. Conversely, granting a source does nothing on its own — the user also needs the relevant feature permission to act on it. Design both together for least privilege.
Because the admin configuring visibility is often not meant to be in the audience (separation of duties — e.g. whoever scopes HR logs may not be cleared to read them), nano never auto-grants your own group. Grant deliberately.
Auditing
Every restrict, grant, revoke, and removal is written to the platform audit log with the acting user, the affected source_type and group, and a timestamp. Review these entries to track how source scoping has changed over time.
Best practices
- Scope sensitive sources at onboarding. Add the
source_typeto the registry before or as you connect the feed, then grant the owning team. - Prefer specific group grants over the Everyone group. Reserve the Everyone grant for temporarily lifting a restriction.
- Confirm your own visibility. After restricting a source you still need to monitor, make sure a group you belong to is granted.
- Pair with least-privilege permissions. Source Visibility limits which data is seen; permissions limit what can be done with it. Use both.