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.
There is no account system of its own. Users log 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.
Three roles
default/authorize.conf defines three capabilities and three roles that inherit upward:
| Role | Capability | Allowed |
|---|---|---|
rst_copilot_viewer | copilot_use | Ask, explain, view every page; write only own data (conversations, feedback, preferences, saved queries) |
rst_copilot_analyst | + 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 | + copilot_admin | AI settings, Settings, licence, channel and ticket configuration, rule deploy / enable / delete, asset import, apply rewrites / suppression / onboarding configs, MCP tokens |
Splunk's own admin and sc_admin get all three. The 1.5.x role copilot_user equals analyst and is removed in the next major.
Assign roles in Splunk under Settings → Roles / 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.
Where the gates are
- Pure admin endpoints (AI settings, licence, deploy, asset import, alert-source setting) require
copilot_admininrestmap.conf; the request never reaches the handler. - Mixed endpoints (knowledge base, baseline, channels, reports, triage results, onboarding, MCP) check the capability per action inside the handler: reads open, writes tiered as above.
- A refusal returns
{"code":"forbidden","params":{"capability":"copilot_write"}}; buttons show the reason instead of disappearing. - The
| copilot/| splexplaincommands and the MCP tools go through the same gate; an MCP token is bound to its issuer's tier and cannot be issued above it.
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 | Needs |
|---|---|
| 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, kvstore/status (admin only by default; other users see those checks as unknown) |
| Baseline | Search access to the CIM Endpoint / Change data models |
| Asset inventory | With ES, read on asset_lookup_by_str / 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
RST_MASKING_MODEinsplunk-launch.confpins the masking mode; the UI cannot loosen it.[limits] agentic_index_whitelistbounds what the model may probe on its own.- Threat intel, ticketing, channels and MCP each have their own egress switch, all off by default.