Roles and permissions
The three roles and their capabilities, which tier each feature needs, the Splunk permissions behind ES write-back and data onboarding, and how login stays Splunk's.
The app has no account system of its own. Users sign in to Splunk; the app decides what they may do from the capabilities their roles carry. The account menu holds only Preferences; passwords are changed in Splunk.
Roles
default/authorize.conf defines three capabilities and three roles that inherit upward:
| Role | Capability | Permissions |
|---|---|---|
rst_copilot_viewer | copilot_use | Ask, explain, view every page. Writes only own data (conversations, feedback, preferences, saved queries) |
rst_copilot_analyst | plus copilot_write | Triage, investigate, draft detection rules, generate reports, upload to the knowledge base, test notifications, write back to ES, open tickets, save as Report |
rst_copilot_admin | plus copilot_admin | AI settings, Settings, licence, channel and ticket configuration, rule deploy, enable and delete, asset import, apply rewrites, suppression and onboarding configs, MCP tokens |
Splunk's own admin and sc_admin hold all three. The 1.5.x role copilot_user equals analyst and is removed in the next major version.
Roles are assigned in Splunk under Settings, Roles and Users, or in authorize.conf. A plain user with no rst role can open the app but lacks copilot_use, so every AI request returns forbidden.
Gates
| Endpoint type | Gate |
|---|---|
| Pure admin endpoints (AI settings, licence, deploy, asset import, alert-source setting) | restmap.conf requires copilot_admin; the request never reaches the handler |
| Mixed endpoints (knowledge base, baseline, channels, reports, triage results, onboarding, MCP) | The handler checks the capability per action. Reads are open; writes are tiered as above |
Search-bar commands | copilot, | splexplain and MCP tools | The same gate. An MCP token is bound to its issuer's tier and cannot be issued above it |
A refusal returns {"code":"forbidden","params":{"capability":"copilot_write"}}; buttons show the reason rather than disappearing.
Splunk permissions behind features
The app runs searches as the current user, so an index the user cannot see in Splunk is invisible to the copilot too. Some features need more:
| Feature | Requirement |
|---|---|
| Alerts, posture | Search access to the alert index (default notable) |
| Write back to ES notable | Enterprise Security installed; the user may call notable_update (ES ess_analyst or above) |
| Deploy rules, save as Report or Alert | schedule_search; writes saved searches into the search app |
| Data onboarding apply | Write access to the target app's local/props.conf (edit_props or admin) |
| SPL performance advisor | Search access to _audit (admin only by default) |
| Platform health | Read on /services/server/health, licenser and kvstore/status (admin only by default; other users see those checks as unknown) |
| Baseline | Search access to the CIM Endpoint and Change data models |
| Asset inventory | With ES, read on asset_lookup_by_str and identity_lookup_expanded; without ES, CSV import |
| Scheduled jobs (baseline, KB sync, auto-triage, MCP) | Scripted inputs run as splunk-system-user. A Splunk Free licence has no such user, so scheduled jobs get no session |
Admin pins for masking and egress
| Item | Effect |
|---|---|
RST_MASKING_MODE in splunk-launch.conf | Pins the masking mode; the UI cannot loosen it |
[limits] agentic_index_whitelist | Bounds what the model may probe on its own |
| Egress switches for threat intel, ticketing, channels and MCP | Independent, all off by default |