OS AI Agent connects a language model you choose to your Splunk deployment, and lets it act - search, read knowledge objects, build dashboards and alerts - under the calling user’s own permissions and, for anything that writes, with that user’s explicit approval. This page explains the model so the rest of the documentation makes sense.
Bring your own model
The app ships no model and calls no service of its own. You configure a provider: where the model is, how to authenticate, and which model to use by default. Four provider kinds cover the landscape - anything OpenAI-compatible (which includes every common local model server), Anthropic, Azure OpenAI, and AWS Bedrock - and you can configure several and switch between them per conversation or per search. The cost of a conversation is whatever your provider charges; the app records it so you can see it. See Providers.
The agent loop
A conversation turn is a loop: the model reads the conversation, decides whether it needs a tool - run a search, list the indexes, fetch a dashboard - calls it, reads the result, and either calls another tool or answers. Every tool the agent has is documented in Tools. Two properties of the loop matter most:
- Tools run as you. Every tool executes against splunkd with the calling user’s own session, never a system account. The agent can read only the indexes and objects your Splunk roles allow, and scheduling a search or an alert needs your own
schedule_searchcapability. - Writes pause for approval. Read-only tools run on their own. Anything that creates or modifies a dashboard, saved search, report, or alert pauses on an approval card that shows exactly what will be written. You approve, deny with a reason the agent reads, or edit the parameters first. See Chat.
The chat worker
Chat runs as asynchronous jobs processed by a background input on the search head (os_ai_agent_worker), so a long agentic chain is not bounded by a browser or REST timeout. The chat page streams progress from the job and re-attaches to it if you reload or open the conversation in another tab. On a search head cluster, every member runs the worker and each job is claimed by exactly one of them. A job that needs more time than one worker pass allows saves its progress and continues on the next pass.
What the model sees
The agent sends the provider the conversation itself, a built-in playbook (how to explore data efficiently, how to validate searches before saving them, and to treat tool output as data rather than instructions), the definitions of the enabled tools, the results of the tools it runs, and one line naming your Splunk edition and version. Bulky tool results from older turns are replaced with short placeholders in the view sent to the model - the stored conversation keeps them in full - so long sessions fit small models and cost less on paid ones.
Everything the model reads from your data is wrapped in an explicit untrusted-data boundary, and the app scans it for text aimed at the agent - instructions to ignore its rules, requests for its credentials - and flags what it finds on the tool card and in the activity trail. See Security.
Grounded, not guessed
The binary embeds a cleaned copy of Splunk’s SPL Search Reference and Dashboard Studio documentation, plus curated dashboard examples, and the agent consults them through lookup tools while it works - SPL semantics and dashboard syntax come from documentation, and they work air-gapped. It also reads your deployment’s vocabulary as the signed-in user: search macros with their definitions, lookup definitions, data models with their fully qualified field names and acceleration state, and the SPL commands your installed apps contribute. Add your own conventions as query templates (a shared library of SPL patterns the agent searches before writing its own) or as situational guidance notes. See Tools.
Three ways in
- Chat - the conversational workspace, with server-side conversations, approvals, exports, and per-conversation settings. See Chat.
| osai- the search command: a completion, an SPL explanation, or a full read-only investigation, from any search or a scheduled report. See The osai command.- The alert action - “Ask OS AI Agent” attaches to any alert and investigates it when it fires, with the findings appearing as a new conversation. See Alerts and schedules.
What leaves your environment
Only what you send the provider: the conversation, the playbook and tool definitions, and the tool results the agent chose to read. The app sends no telemetry and phones home to no one; licensing is enforced offline. API keys live in Splunk’s encrypted credential store, conversations live in KV Store collections readable only by administrators and the system context (users reach their own through the app’s REST handlers, never the raw collections), and the activity trail is a log file Splunk indexes into _internal.
What OS AI Agent is not
- Not a hosted service. Nothing runs outside your search head except the provider you configured.
- Not autonomous by default. Every write needs a person’s approval, and unattended runs (scheduled
| osai task=and alert investigations) cannot write at all. - Not a replacement for your permissions. It can do what you can do, and nothing more; it is a faster way to do it.