Splunk security exec charts course for responsible AI

DENVER -- Responsible AI took on heightened significance this week against a backdrop of heady industry talk about AI-driven human extinction, leaving Splunk's AI security leader with the unenviable task of articulating how enterprises can safely navigate the journey ahead.

During a keynote presentation at Splunk's annual .conf user conference here this week, John Morgan, senior vice president and general manager for Splunk Security, outlined five daunting threats and their links to high-profile security incidents:

• The sheer speed of AI agents.
• The vulnerability-sniffing prescience of frontier models such as Anthropic's Mythos.
• The democratization of such capabilities through open-weight models such as Moonshot's Kimi 3.
• The demonstrated ability for AI agents to break containment, as they did during this year's OpenAI-Hugging Face attack.
• And the demonstrated risk of malicious agents attempting to recruit humans and other agents, as seen during the UK's AI Security Institute testing in August.

These incidents, along with others, led frontier AI companies to call for a slowdown in AI development last weekend and stoked fears about AI safety globally.

Despite the broader dark climate, Morgan, whose LinkedIn profile shows he joined Splunk in January from a stealth AI security startup, said during his presentation that he believed enterprises could rise to the occasion.

"This is not a doom and gloom scenario -- We do have solutions for these things," Morgan said. "One is, defend autonomously ... Two, stop attacks at the source with enterprise-wide visibility. And three, mitigate critical exposures before that risk turns into an actual exploit."

TechTarget News caught up with Morgan on-site shortly after that keynote to ask some follow-up questions.

There's been a recurring scenario in Splunk's press briefings and presentations: a site reliability engineer (SRE) or security operations center (SOC) analyst assessing whether an agent has gone rogue, been poisoned or has a configuration error, and distinguishing among them. Is that something you can do now with Splunk's agent observability tools?

John Morgan: There are two broad platform infrastructures going on -- there's integration with Cisco Cloud Control, Splunk Enterprise Security (ES) and Agent Observability, which is what you saw in demos. We also have a separate set of integrations for Enterprise Security that do not assume the customer is adopting Cloud Control -- that's where we have some near-term roadmap stuff to do to support that scenario.

Cisco Cloud Control is just a new way humans interface with machines through agents, MCP [Model Context Protocol] services and APIs, rather than direct product integrations we've done in the past. This new way of working, whether it's Cisco Cloud Control or another super app, is headless and integrated at the agent and MCP layers. We'll continue to see technology move in that direction.

Now, we haven't made an announcement on that. But we're architecting our systems to work [that way]. I envision, as many customers do, that they may be using other similar agentic harnesses, so I want to make our capabilities available through those as well. But we're not announcing that right now. I just want to be clear on it.

Technically, because there's already an MCP server for Splunk, someone with sufficient skills can do it right now.

Morgan: You're exactly correct. We launched MCP skills and interface for Splunk already, and we're going to keep adding to it for Splunk core. [And] we're launching MCP skills next month for ES.

In your keynote, you alluded to closer integration coming between security and ops. You said you have to respect that they're separate teams, but that there's a further drawing together that Cisco's working on. So, what is that?

Morgan: It's basically the same conversation we just had about agent observability and ES for general applications. We're making integrations available through MCP servers and Cloud Control, and I'm also going to do direct product-to-product integrations to make sure that's the case. So that's the coming soon part.

We have a lot of customers who use our observability platform and our ES platform, and they would love more information sharing between them so each team can better distinguish between a security attack and an application or SRE failure.

If someone has Splunk observability but not ES -- let's say they use a competitor -- and someone on the observability team sets a guardrail or policy, as shown in demos, is there a way to show that to the security team so they know someone in observability just set a policy?

Morgan: Yes, if a customer wants to roll their own security, they can take anything ingested into Splunk and create their own analytics dashboards, detections and workflows. If they're using Palo Alto or any of those, they can create connectors and access Splunk, either through its traditional integrations or now through the MCP server. In fact, we have a lot of customers who are very heterogeneous in their security products. They're sometimes multiSIEM. We often become a centralized aggregation point for all of it.

But obviously, if Splunk and Cisco had their way, they'd be the one portal to rule them all, right?

Morgan: I think any company wants to be in pole position, but Splunk has always had a broad ecosystem, and we do pride ourselves on ensuring the customer gets to choose the best-of-breed products and workflows they have. That's been a differentiator for us.

Big-picture question: Is agentic AI actually governable in the long term? Is it really controllable? Because we're hearing about agents defying the guardrails and instructions set for them, finding their way out of sandboxes and containment setups, and even recruiting other agents. Then, of course, vendors like Splunk are proposing tools to rein them in. But what's to say a Splunk Agentic SOC agent isn't vulnerable to recruitment by a malicious agent?

Morgan: We're heavily restricting the capabilities of any one agent. It's very different from saying, 'Hey, they have access to a bunch of actions, and we're just trying to figure out which ones they will use or not use.' We're giving them a very narrow scope and an extremely narrow action capability. And in fact, sometimes it's just read-only. There are ways to do that where you're not subjecting the agent to deciding what it can break and cannot break.

We're also integrating the same products we want customers to use into our SOC, like Cisco AI Defense. We're doing separation of duties and then giving the customer a choice in how they use them.

So, the idea isn't that it would be impossible for a malicious agent to try to recruit Agentic SOC agents, but that, if they did, the Agentic SOC agents would have limited access.

Morgan: Very limited by design and extremely governed and observed. Those are the practices we're putting in place at speed. That's the key part -- at speed.

There are use cases … that are much lower-risk and get a huge amount of value. And then, over time, as we navigate these waters, we can allow more and more autonomy.

There's also still a lot of talk about human-in-the-loop, but that ultimately doesn't scale, right? So how do you make the leap from the 'walk' to the 'run' with autonomous agents?

Morgan: Speaking of the SOC, there's tremendous value in just allowing an agent to handle the triaging and analysis for you. Forget about letting them respond or letting them configure anything; there's tremendous value in just the front end. We all know there's alert fatigue -- we've talked about it for years. But now it's impossible. There are use cases like that that are much lower-risk and get a huge amount of value. And then, over time, as we navigate these waters, we can allow more and more autonomy.

But is that fast enough to keep up with AI threats?

Morgan: As we go through the years, we're going to have to gain more control, more responsibility, more trust, understand the technology better, and we're going to have to automate more, probably, to keep up. We're building the technology that will get us there, but we're not going to get there before it's prudent. We want to build for a day -- and we see that this is probably inevitable -- where you have to have some level of autonomy.

Now, when I say autonomy, there's also a responsible way to introduce it. If you look at a lot of startups and things out there, they're just throwing agents at it. The instruction I'm giving my team, specifically when it comes to autonomous response, is that we want to go use case by use case with a framework of high-confidence, low-risk, reversible, low-blast-radius actions.

It doesn't mean that we're going to enable it for every customer. It doesn't mean every customer wants it. But when customers are talking to vendors, they want to know what our strategy is, because they have a view of the future, and quite a few of our customers believe if we're not building toward [autonomy], even if we don't want to allow it now, we're probably not heading in the right direction.

Editor's note: This interview has been edited for clarity and conciseness.

Beth Pariseau, senior news writer for Informa TechTarget, is an award-winning veteran of IT journalism. Have a tip? Email her or connect on LinkedIn.