An AI assistant that inherits Splunk’s boundaries instead of working around them.
AI Workbench is a host shell: a single app you install into Splunk that delivers an AI assistant inside your other apps — Search, ITSI, Enterprise Security, custom apps, or the apps you run for your customers. It has no use-cases of its own. Everything it can do is derived from two things: the app a user opens it from, and the Splunk roles that user holds. That single design decision is what makes it safe to put in front of a SOC.
Generation that validates itself
Most AI tools hand you SPL and hope it runs. AI Workbench treats generation as a loop, not a guess.
When you describe what you want — “show me failed logins by source IP over the last 24 hours and build a panel for it” — the assistant drafts the SPL, executes it against a small sample of real rows to confirm it actually works, and only then saves the result. If the search fails, it reads the error and corrects itself before showing you anything. Dashboards, alerts, saved searches and MLTK workflows are written into the correct app’s namespace, so they appear exactly where your team expects them — not orphaned in a sandbox.
What it generates: SPL searches · Simple XML dashboards · alerts and scheduled searches · MLTK / machine-learning workflows · investigation and triage chains across ES and ITSI.
Bring your own LLM
You should never have to choose between “use AI” and “keep our data in our perimeter.” AI Workbench separates the assistant from the model behind it.
Every supported provider can run through the Splunk-side proxy, which means your API keys live on the Splunk server and never reach the browser. For the strictest environments, you can point the assistant at a local model running on your own hardware — no data leaves your network at all. And because the model is a configuration choice, not a hard dependency, you can switch providers per tenant or move off a provider entirely without re-platforming.
Supported today: Anthropic Claude, OpenAI, Azure OpenAI, Google Gemini, Groq, AWS Bedrock, OpenRouter, and local Ollama models. Each can run server-side via the Splunk proxy; several also support direct browser calls where your network allows it.
The knowledge layer
An AI assistant is only as good as the context it can reach. But stuffing every prompt full of detections and playbooks is slow, expensive, and noisy.
AI Workbench takes a different approach: the assistant pulls knowledge on demand. When a question warrants it, it routes to the right sources — Splunk Security Essentials detections, your own curated playbook fragments, lessons-learned your SOC has agreed on — retrieves only what’s relevant, and cites where the answer came from. Nothing is pre-injected, so adding a thousand detections doesn’t make every prompt heavier. And because the routing is deterministic rather than agentic, there’s no extra AI step for an attacker to manipulate.
Governance and multi-tenancy
This is where AI Workbench earns its place in serious environments.
Access is scoped by Organization and Business Unit. Tools, templates, skills and knowledge sources can be assigned per tenant, so a managed-service provider can give each customer exactly the right capabilities with clean isolation between them. A single license key can cover multiple Splunk environments up to a licensed maximum. Every AI action respects the user’s Splunk roles — the assistant can never read or write something the user couldn’t themselves — and activity is recorded so administrators retain a continuous audit trail.