Platform
AI that inherits Splunk’s boundaries instead of working around them
Adjutant AI (formerly AI Workbench) is one app on your search head that delivers AI inside your other apps: Search, ITSI, Enterprise Security, your own apps and the apps you run for customers. This page explains how it is built, and why that design is what makes it safe to put in front of a SOC.
Three decisions everything else follows from
Most of what a security reviewer asks about is answered by three design choices made on day one.
A host shell with no use cases of its own
Everything it can do is derived from the app a user opens it from and the Splunk roles that user holds. One install takes the shape of every app it serves, and artefacts land in that app, owned by that user.
It acts as the user, never above them
The assistant runs under the calling user’s real Splunk identity. There is no privileged service credential behind the scenes. If you cannot see an index, neither can the AI.
Governance is the floor
An upstream OAuth or API scope is only a ceiling. Adjutant’s own controls always apply on top: every tool that writes needs an explicit grant, and the default is deny.
How the platform is layered
Work enters at the top, passes through governance, and only reaches your data through Splunk itself.
Entry points
A person asking in an app, an alert or ES notable, an ITSI episode, a schedule, another agent over MCP, or an integration contract. All of them use the same playbooks.
Governance
Organisation and business unit scoping, per-tenant tool and model assignment, a server-side action gate on everything that writes, and a licence capability matrix checked in splunkd rather than greyed out in the screen. A business unit can only narrow what its organisation allows, never widen it.
Engine
Playbooks define the job and the output shape. Tools do the work, each scoped to one task in Core, ES, ITSI, TrackMe, ServiceNow or the AI Toolkit. Skills carry the rules for doing it correctly. Knowledge is pulled in only when it is relevant.
Model
The language model of your choice, called from the search head so keys never reach the browser. Cloud providers or a local model for fully offline environments, switchable per tenant.
Splunk
Searches run under the user’s own permissions. Results come from your data, grounded in your knowledge objects, installed CIM models and live command syntax. Saved objects are written into the calling app’s namespace.
Generation that validates itself
Most AI tools hand you SPL and hope it runs. Here generation is a loop, and nothing is saved until it has worked against your real data.
Draft
The model drafts SPL or dashboard markup, grounded in your live command syntax, CIM models and knowledge objects.
Run on real rows
The search is executed against a sample of your data. Zero results is treated as a question, not a pass.
Correct
On an error, it reads the message and fixes the search before you see anything. Dashboards are repaired before they publish.
Save in place
Dashboards, alerts, saved searches and AI Toolkit pipelines are written into the app the user came from.
Configuration is checked too. Generated props.conf and transforms.conf are validated against the .conf.spec of your running instance and every regex is compiled, so a hallucinated attribute cannot ship silently.
Deterministic where the answer must hold up
Some answers end up in an incident review, an audit or a board report. For those, the model is kept out of the calculation. Code computes; the model explains the result in plain language.
- ITSI root cause. Scored over the real dependency graph with a transparent model. The same evidence always gives the same ranking.
- Fraud data coverage. Graded from a structured catalogue of nine typologies, identifying event families by what events contain rather than by sourcetype name.
- Risk scores. Computed from fixed operator weights, never by the model doing arithmetic.
- Integrations. A runner executes a versioned mapping record by record. The model never transforms rows.
- ServiceNow descriptions. Produced by a fixed renderer, so the model cannot fabricate numbers or smuggle markup into another system.
The knowledge layer
An assistant is only as good as the context it can reach, but stuffing every prompt with detections and playbooks is slow, expensive and noisy.
Pulled on demand
When a question warrants it, the assistant retrieves only what is relevant: Security Essentials detections, your curated playbook fragments, lessons your SOC agreed on. Adding a thousand detections does not make every prompt heavier.
Cited, not invented
Answers say where the knowledge came from, so an analyst can check the source rather than trust the phrasing.
Routed deterministically
The routing to knowledge sources is rule-based, not another AI step. There is no extra model decision for an attacker to manipulate.
A runtime built for unattended work
The same engine runs without a person present. That demands more than a scheduler, so the unattended engine ships disabled and has to be switched on deliberately.
- Bounded. Concurrency caps so an alert storm cannot spawn unlimited runs, and a watchdog that reclaims hung runs.
- Single-flight. A scheduled job never overlaps itself. A tick that arrives during a live run is skipped and shown as skipped.
- Search head cluster safe. Queues and watermarks live in replicated storage, not on one node.
- Honest under pressure. Slow upstreams are skipped and noted, lowering confidence, instead of blocking the run.
- Stateless when you want it. Durable state can move to an object store. A rebuilt instance restores itself, verifies what it restored, and refuses scheduled work until that check passes.
- Reliable model access. Failover, circuit breakers and retries across model providers (Enterprise).
Security, in the language your reviewers use
AI applications face risks ordinary software does not: prompt injection, data extraction, tool abuse and supply-chain tampering. The OWASP Top 10 for LLM Applications and MITRE ATLAS describe them. Here is how the platform answers them, natively inside Splunk and with no cloud AI-defence service in the loop.
See what the AI did
A defensible record of every action.
- Audit logging per organisation, written server-side before a request reaches the model (Enterprise)
- A governance log of who changed playbooks, tools, MCP servers and model settings
- Per-attempt model telemetry and tool-call logging, ready for ATLAS-mapped detections
- Agent telemetry as OCSF events into an index ES already watches
Trust nothing unverified
Nothing untrusted gets to define behaviour.
- No token passthrough: the Splunk backend is the only OAuth client and token holder
- Single-use authorisation transactions bound to user, tenant and redirect
- Generated configuration checked against your running instance
- Content packs carry an integrity check and never overwrite your customisations
Contain what gets through
A successful injection still cannot reach a permitted action.
- Write targets bound for unattended runs; side-effect SPL commands filtered out
- ServiceNow writes limited to an allowlist of tables, default deny
- Secrets stripped from support bundles, with a fail-closed re-scan before sending
- Security-sensitive features must be enabled twice, by deliberate admin action
What these controls are not
A security review goes better when the limits are on the table from the start.
- No semantic injection classifier. Input defence is structural: side-effect refusal, allowlists, identity and write-target binding. The claim is that an injection cannot reach a permitted action, not that every injection string is detected.
- Your authorisation hook is your code. The optional customer IAM hook runs trusted, unsandboxed Python in splunkd, like any other splunkd extension you secure yourself.
- It secures its own AI surface. It is not a model-scanning or red-teaming platform for models you run elsewhere. Pair it with a dedicated scanner if you need that covered.
Multi-tenant by design
This is where the platform earns its place in larger and shared environments.
Organisations and business units
Tools, playbooks, skills, knowledge and model settings are assigned per tenant. Tenancy is resolved from the app and the user’s roles, so nobody picks a tenant and nobody can pick the wrong one.
One key, many environments
For service providers, a single licence key covers multiple Splunk environments up to a licensed maximum, with isolation per environment.
Cost per tenant
Token and cost reporting per organisation and business unit, so AI spend can be charged back to the team or customer that used it.
Put it in front of your security architect
We are happy to walk your reviewers through the architecture, the controls and the gaps, on your terms. Or install the free Personal edition and inspect it in your own Splunk first.