Close AI Monitoring Blind Spots With OpenAI and Anthropic Add-Ons
Security Greg ZiemieckiKey takeaways
- Splunk's new add-ons let teams track who used AI tools, what changed, and whether API keys were created or misused across ChatGPT, Claude, and other providers.
- Local and self-hosted AI models running on tools like Ollama can now be monitored for security risks alongside cloud-based AI platforms.
- Bringing AI activity into Splunk allows teams to correlate it with existing identity, network, and security data for faster investigations and audits.
AI adoption is creating a familiar problem in a new place: activity is happening faster than you can see it.
Your employees use enterprise AI assistants. Your developers connect applications to model APIs. Some teams run local models with tools like Ollama. Others experiment with AI gateways, RAG applications, agents, and MCP servers. Each path creates useful signals about who used the system, what changed, which services were called, and where risky behavior may have occurred.
The hard part is that those signals often live outside the systems you already use for security, compliance, and operations. That creates blind spots. During an audit or investigation, you should not have to jump across provider consoles, local servers, application logs, and one-off scripts to understand what happened.
This is where Splunk has a practical role to play. You do not need to wait for a perfect LLM observability architecture before you start managing AI risk. You can begin by bringing AI activity into the data platform you already use to search, retain, correlate, and investigate operational and security events.
That is the first useful step for LLM monitoring: get the available AI activity under management.
Start With the Audit Questions
Security, compliance, and operations teams tend to ask simple questions first:
- Who used the AI platform?
- What activity happened?
- Which admin settings have changed?
- Were API keys created, rotated, deleted, or used?
- Did content, projects, files, connectors, or sharing settings change?
- Can AI activity be retained for later review?
- Can it be correlated with identity, endpoint, network, and security data?
- Where is adoption, usage, and spend accumulating?
These are not abstract AI questions. They are investigation questions.
They also map naturally to Splunk. The work is to collect the relevant activity, preserve enough context, make it searchable, and connect it with the rest of your enterprise data estate. Once that foundation exists, you can build dashboards, detections, timelines, and audit workflows from the same place you already investigate other business critical systems.
Governance and Auditability for SaaS AI Platforms
The clearest starting point is SaaS AI governance.
Splunk now has three complementary open-source add-ons for enterprise AI governance. The OpenAI Compliance Add-on for Splunk brings broad ChatGPT Enterprise compliance data into Splunk. The Anthropic Claude Enterprise Add-on for Splunk adds deep Claude security, governance, adoption, usage, and spend visibility. The Enterprise AI Governance Add-on for Splunk provides a normalized view across multiple providers and self-hosted models.
The vendor-specific add-ons preserve the depth each provider exposes. The Enterprise AI Governance Add-on provides breadth by normalizing activity from Claude, OpenAI, Gemini, Microsoft 365 Copilot, and self-hosted models into a shared schema. That lets dashboards, alerts, and investigations work consistently across providers while retaining provider-specific details where it matters.
The broader pattern is clear: AI activity belongs in the same place where you investigate security, compliance, and operational events.
For you, the value is practical:
- Search AI platform activity alongside existing audit data.
- Build admin and user activity timelines.
- Track API key lifecycle events.
- Correlate source IPs, users, and user agents with identity and security data.
- Retain AI activity for compliance and investigation.
- Build dashboards without depending only on provider consoles.
This is a strong first use case because it is immediate, concrete, and close to the problems you already care about.
Security Monitoring for Local and Self-Hosted LLMs
Not every AI workload runs on a SaaS platform. You may run local or self-hosted LLMs for privacy, cost control, experimentation, or deployment flexibility. Those environments create a different monitoring problem, but the data management needs are similar.
The Enterprise AI Governance Add-on for Splunk can inventory models running on vLLM, Ollama, and LiteLLM servers, collect available Prometheus metrics, and monitor endpoint health. This brings self-hosted model discovery, performance signals, and availability into the same governance view as enterprise SaaS platforms.
Local LLM deployments can produce useful signals from:
- Ollama or similar model-serving frameworks.
- MCP servers and tool layers.
- Containers and Kubernetes.
- Host operating systems.
- Reverse proxies or gateways.
- Security testing and red-team tooling.
Those signals can support security monitoring, detection development, and investigation. Splunk's work on local LLM/MCP detection development shows how activity from Ollama and MCP environments can be brought into Splunk and used to build MITRE ATLAS-style detections.
Every local LLM environment will look a little different. The practical move is to collect the signals your environment already produces, then use Splunk to search, correlate, and operationalize them.
What Splunk Adds
The market already has AI platforms, model gateways, observability tools, and security tools. Splunk's value is different: it helps you bring AI activity into the same investigation layer you already use across your business.
That matters for a few reasons.
First, AI activity rarely matters in isolation. A suspicious API key event becomes more useful when it can be correlated with identity events, source IPs, endpoint activity, cloud activity, and existing security detections.
Second, audit and investigation workflows depend on retention and repeatability. Provider consoles can be useful, but you may still need the data in your own environment, under your own search, retention, access control, and reporting practices.
Third, LLM monitoring will grow from multiple data sources. SaaS compliance APIs, local LLM activity, gateway events, OpenTelemetry, infrastructure metrics, evaluation events, and application telemetry all answer different questions. Splunk gives you a place to bring those signals together over time.
What You Can Do First
The best first step is the one that gives you visibility quickly.
You can start by:
- Collecting AI activity that exists today.
- Making AI-related records searchable, retained, normalized, and correlated.
- Choosing vendor-specific add-ons for deeper provider coverage.
- Choosing the Enterprise AI Governance Add-on for normalized cross-provider visibility.
- Building reusable dashboards, detections, and investigation views.
That gives you a practical foundation for governance, audit, and security work. From there, you can expand into deeper application, cost, quality, and performance monitoring as your LLM monitoring program matures.
Where This Fits With Broader LLM Observability
AI activity signals are only one layer.
Your application teams may add traces for latency and request flow. OpenTelemetry's Generative AI semantic conventions are relevant for LLM applications because they can describe model requests, token usage, operation names, and related workflow metadata. Your infrastructure teams may add metrics for GPUs, Kubernetes, serving frameworks, and cloud services. Your AI teams may add evaluation events and user feedback to understand quality.
Those layers complement the signals-first message. They make the path clearer:
- Start with AI activity that is available now and maps directly to governance, security, and audit use cases.
- Preserve enough context to reuse the data across dashboards, detections, and investigations.
- Correlate AI activity with existing Splunk security and operations data.
- Add traces, metrics, cost, and quality signals as the monitoring program matures.
The market point is simple: LLM monitoring can begin with the AI activity you can already collect, brought into the platform you already use to investigate critical systems.
Choose the add-on that fits the scope you need. the OpenAI Compliance Add-on for Splunk for broad ChatGPT Enterprise compliance coverage, the Anthropic Claude Enterprise Add-on for Splunk for deep Claude security, governance, usage, and spend visibility, or the Enterprise AI Governance Add-on for Splunk for normalized visibility across multiple providers and self-hosted models.
For more detail, see the Lantern overview on monitoring and governing enterprise AI platforms, the setup guide for the enterprise AI governance add-ons, and the guide to monitoring enterprise AI security, compliance, and spend.
Related Articles

Boss of the SOC 2.0 Dataset, Questions and Answers Open-Sourced and Ready for Download

Splunk’s Response to the SolarWinds Cyberattacks
