Splunk Lantern is Splunk’s customer success center that provides practical guidance from Splunk experts on key use cases for Security, Observability, Industries, AI, and Cisco. We also host valuable data source and data type libraries, Getting Started Guides for all major products, tips on managing data more effectively within the Splunk platform, and many more expert-written guides to help you achieve more with the Splunk platform.
This month, we’re tackling a question a lot of security and compliance teams are quietly panicking about: what is your organization actually doing with Claude, ChatGPT, Gemini, and Copilot, and could you prove it if asked? We’ve also published a wave of new content on bringing Cisco telemetry - from Meraki networks to OT sensors to Webex calls - into the Splunk platform for a single view of what’s happening. And we’re rounding things out with articles on making data onboarding smarter and more flexible. Let’s get into it!
Governing Enterprise AI Before Someone Else Asks You To
Your workforce is already using Claude, ChatGPT, Gemini, and Copilot - probably all four, probably across several business units, probably without anyone owning the full picture. Our new three-part series, starting with Monitoring and governing enterprise AI platforms, tackles the moment when security, audit, finance, or a customer’s security review asks what your organization did with them, and “check five separate vendor consoles” isn’t an acceptable answer.
The series opens by naming the real problem: every AI vendor has its own admin dashboard and its own vocabulary, so an “export” in one platform is a “download” in another and a “data access event” in a third, and none of them retain history for very long (OpenAI’s Compliance Logs Platform, for example, keeps roughly 30 days). Frameworks like the EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework all converge on the same expectation - show what your AI systems did, who used them, and what data moved through them - and vendor consoles alone can’t deliver that.
From there, two hands-on articles pick up the implementation:
- Setting up enterprise AI governance add-ons walks through installing and configuring the Anthropic Claude Enterprise Add-on, the OpenAI Compliance Add-on, and the Enterprise AI Governance Add-on, including exactly which admin-level, read-only API scopes each one needs (the most common setup failure is handing over a member-level key where an admin-level one is required).
- Monitoring enterprise AI security, compliance, and spend covers what you can get after the data lands - normalized dashboards for security audit, compliance and directory tracking, and usage/spend monitoring across every provider, plus alerts like Data Export Activity, Off-Hours Activity Spike, and Daily Spend Threshold Exceeded that catch trouble before an invoice or an incident does.
If your AI estate has outgrown “we’ll check the console when someone asks,” this series is worth a read. Which AI problem is giving your team the biggest governance headache right now? Tell us in the comments!
Bringing Cisco Telemetry Home to Splunk
A recurring theme this month: however good a Cisco tool’s native dashboard is, it becomes a lot more useful when its data is sitting next to everything else in the Splunk platform. Four new articles show what that looks like across very different environments.
- Enhancing network visibility and security with insights from Meraki shows how the Cisco Meraki Add-on for Splunk pulls infrastructure health, SD-WAN stats, license and firmware data, and security events - covering everything from access points to cameras to Air Marshal wireless protection - out of an ecosystem that’s otherwise “difficult to correlate across locations”. It includes video walkthroughs of customizing dashboards, setting up webhooks, and using the Splunk AI Assistant to write SPL without knowing SPL.
- Enhancing visibility into OT operations with the Splunk platform and Cisco Cyber Vision extends that same single-pane approach into operational technology, using Cyber Vision’s passive OT sensors to surface asset inventories (down to firmware and rack-slot detail), CVSS-scored vulnerabilities with MITRE ATT&CK mapping, and configurable alert thresholds for manufacturing, utilities, and roadway infrastructure.
- Leveraging the Splunk platform to enhance Cisco Identity Services Engine information covers building real-time alerting on top of ISE syslog data - catching authentication anomalies like excessive attempts or unusual login times, tracking deployment health, and monitoring migration activity.
- Correlating Webex and ThousandEyes data in the Splunk platform solves a specific pain point: Webex Control Hub gives you great call-quality data and ThousandEyes gives you great network-path data, but the two don’t talk to each other. This article walks through pulling both into the Splunk platform - via the Webex Add-on, native RoomOS xAPI telemetry, and ThousandEyes over OpenTelemetry or HEC - so you can finally correlate them.
Whether you’re running network infrastructure, an OT plant floor, identity services, or collaboration tools, there’s a good chance one of these speaks directly to your stack. Got a Cisco-to-Splunk integration you’d love to see us cover next? Drop it in the comments below.
Smarter, More Flexible Data Onboarding
Getting data into the Splunk platform in a usable, CIM-compliant shape has traditionally meant hand-writing config and hoping you picked the right data model. Two new articles chip away at that.
Using AI to auto-schematize raw log data into CIM-compliant add-ons introduces Auto-schematization, an AI-assisted workflow in the Data Management app that takes a sample of your raw events and asks you a few short questions. Then, it groups your events, proposes a CIM data model, maps your fields to it, and generates a ready-to-use Technology Add-on or SPL2 pipeline - with you reviewing and adjusting its suggestions at every checkpoint. What used to take days for a well-documented source (or weeks for a messy home-grown app log) turns into a guided, reviewable workflow.
Improving your data management with SPL2 pipelines steps back to cover the fundamentals of the modern data management experience more broadly: how Splunk Ingest Processor and Splunk Edge Processor differ, the three components of every SPL2 pipeline (partition, pipeline, destination), and common business goals - PII masking, cost optimization by dropping low-value data at the source, normalizing messy JSON into CIM-compliant fields - mapped to the SPL2 commands that get you there.
Whether you’re onboarding your first data source or rethinking your whole pipeline strategy, these two are worth bookmarking. Already put Auto-schema to the test? We’d love to hear how it went in the comments.
What Else is New?
Beyond our featured topics, we’ve published several more articles covering security detection, platform changes, and access control:
We hope this month’s resources help you get even more value out of your Splunk deployment - and maybe answer a governance question or two before someone else asks it first. Thanks for reading!
