Future of Agent Observability: The Future Side of the Security Operations Centre in AI
A look at Splunk Agent Observability: a platform for tracking, evaluating, and constraining AI Agents, and what it means for the people who defend the systems those agents touch.
Summary:
- We allow AI agents to read our data, call tools, and act without human approval at each step, which makes them a security concern.
- On Splunk conf26, they said it is an agent observability platform that traces agent workflow, scores their outputs, tracks the token cost, and uses runtime guardrails
- Before adopting any such tool, ask where prompts and responses are stored, whether guardrails block or only flag, and who owns each alert.
Who is watching the AI Agents?
Security Operations centres were built to monitor users, endpoints, and networks. Still, in 2026, AI agents are a new kind of actor because we allow them to read and write data without monitoring and approving every step.
From a Security point of view, an AI agent can query the database, read and write mails even calls Api, these are very sensitive parts. It may leak personal data of someone in a reply to some prompts. We can find those leaks in our alerts.
BCS authors have already argued that autonomous agents need built-in limits, runtime monitoring, and human oversight, and that every consequential agent action should be traceable. So this tool, Splunk Agent Observability, is aimed at the monitoring part of that job. This article looks at what it does, why its signals matter to the security team, and what BCS members should ask before relying on it. It describes one vendor’s approach, drawn from Splunk’s published material rather than hands-on testing, and is neither a recommendation nor a comparison with other vendors’ tools.
What is it?
As we know, it is a tool from Splunk for watching, testing, and constraining AI agents once they are in production, and it sits alongside Splunk Observability Cloud. Splunk documentation describes it as an observability, evaluation, and guardrail platform for gen AI and agentic applications. Applications feed it through a Python SDK, an API, or integrations with common agent frameworks, and it works with major model providers.
How does it work?
Splunk’s product page describes four capabilities. What follows is Splunk’s own description, not independently tested.
- Visibility – traces each workflow in detail from request to response, including tool calls, model calls, and retrieval steps, and lines it up with the infrastructure underneath, down to GPU and memory use. A bad output can be tied to its cause on the timeline.
- Evaluation – The score outputs for correctness, relevance, tool use, and safety, using Splunk’s built-in custom evaluators
- Tokenomics – A new term emerged in 2026, which is used to track token use and cost by request, model, agent, and workflow, so runaway spend shows up before the invoice does.
- Guardrails – Turns trusted evaluation into runtime checks for PII, PHI, and PCI leakage, tool misuse, and prompt injection, enforced in real time.
The SOC Angle?
The failures these tools catch are security events as much as quality problems, which is why agent telemetry belongs in a security conversation. The table below maps common agent risks, several of which BCS authors have described as AI-native threats, to the capability Splunk names for each.
| Risk | What it looks like | Where Splunk addresses it |
| Prompt injection | Crafted input steers the agent away from its instructions | Guardrails block it at runtime; AI Security Monitoring reports it |
| Data leakage | An answer or tool call exposes personal, health, or payment data (PII, PHI, PCI) | Guardrails; AI Security Monitoring |
| Tool misuse | An agent calls a tool or takes an action it should not | Guardrails; tool-call traces in Visibility |
| Runaway cost | A looping or abused agent burns through tokens | Tokenomics |
| Unreliable output | Hallucinated or biased answers reach users | Evaluation |
Closing thoughts
Agents are becoming actors in the estate, and the controls around them are only now taking shape. Splunk’s pitch is one place to see what an agent did, judge whether it was right, count what it cost, and stop it from doing what it should not.
Whether that reaches the SOC’s daily picture depends less on the product than on whether the security and engineering teams agree on who watches the same traces. For BCS members, the practical first step is modest: find out where your agents are, who can see what they do, and what happens when one goes wrong.
Dayanidhi Meganathan is an MSc cybersecurity student at the University of Hertfordshire and one of the editors at BCS. The views expressed are the authors’ own
Last updated 21st October, 2026 at 5:05pm