The Security Strategist

AI can flag thousands of suspicious events and create a clear summary of each one. But the bigger question is whether security teams can understand how AI reached its conclusions. In this episode of the Security Strategist Podcast, Dan Williams from Cambridge Intelligence joins John Tolbert, Principal Analyst and Director of Cybersecurity Research at KuppingerCole Analysts, to discuss how AI and visualisation are changing cybersecurity investigations.

They look at how graph visualisation, AI and automation can help security teams make sense of complex data. Williams explains how visualisation can turn machine output into something analysts can understand, investigate and act on, while also helping them see what AI is doing behind the scenes.

Graph visualisation maps the links between accounts, devices, IP addresses, malware and vulnerabilities. Analysts can see how an attack connects instead of reading a list of isolated events. Williams traces the idea back to his company's roots. Before cybersecurity, Cambridge Intelligence served law enforcement, anti-fraud teams and intelligence agencies, who have long relied on link analysis. Picture the detective's wall of photos and string. It looks theatrical, but it works because mapping a problem is the natural way to get your head around it.

The approach has since been applied well beyond network mapping. Security teams now use graphs to connect threat intelligence, cloud infrastructure, industrial control systems and software bills of materials. Tolbert also points to identity, where graphs can expose links between devices, accounts and potential insider threats.

Williams cites a Wiz presentation that described a security graph containing roughly a trillion links. “Everything is a graph, really,” he says. Attackers are looking for a route from A to B, while security teams need to see those connections and understand where they lead. With a trillion links in the picture, that is not something an analyst can work through manually. AI can help sift through that volume, but it raises another question: if the system identifies a connection, can a security team see why it matters?

AI is most useful when each approach is doing a specific job. Traditional machine learning can flag anomalies and classify activity, while generative AI can summarise the results and explain them in plain English. Visualisation then gives analysts a way to see what those findings represent.

Williams says the industry has moved beyond simply asking where AI can be added. The more practical question is whether the cost can now be justified. How much are organisations spending on tokens, and what are they getting back? He describes this as a move from exploration to explanation. Experienced investigators may still spend hours working through data without knowing exactly what they are looking for. But, he argues, there are many more people who need a clear account of what happened.

This now creates another problem because there is too much information. Machine learning can generate a long list of alerts, while large language models can add pages of text to explain them. Neither necessarily makes an incident easier to understand. Williams believes visualisation needs to be part of that process, giving analysts a way to follow the AI's reasoning and see where its findings came from.

He compared it to when you use a maps app; you are not trying to examine every road in a city. You have somewhere to go and need to get to your destination. This is what a junior analyst needs: something similar, a way through the relevant data rather than an overview of everything available. It could be a playbook, a timeline or a short interactive narrative.

Williams compares the ideal experience to watching a film, where the sequence follows an attacker from the initial entry point through to the exposed data and the misconfiguration that made it possible. If presenting an incident that way helps people understand what happened and retain the important details, he sees real value in it.

Trust depends on being able to follow how an answer was reached. That means traceability, sensible guardrails and a human being able to intervene when necessary. Tolbert points to one of the obvious problems with generative AI: a model can produce a detailed and convincing explanation that is simply wrong. Williams agrees, but points to another issue security teams will have to contend with. Investigators are accustomed to asking what filters were applied when reviewing a finding. With AI, the equivalent question becomes: what prompt produced this result? Even then, the same prompt may not return the same answer twice.

That makes a record of the process important. Teams need to be able to see what the system did, retrace the steps, repeat the analysis and share the results with others. Williams compares it to saving a query rather than relying on someone to remember exactly how they reached a finding. The need for control becomes more complicated when several visual views are connected. A network graph, timeline and map might all respond to the same request, but an AI system could apply different filters or handle the information differently in each view. A high-risk node might stand out in one representation and be overlooked in another. For Williams, that changes the question vendors need to answer. It is no longer only about how a visualisation looks, but about how reliably an analyst can control the system behind it.

His advice to CISOs is to try to draw what the AI-enabled security tool did during the previous week. If that is difficult, ask the vendor to show you. The same applies to value. If the system can demonstrate its impact visually rather than producing another lengthy report, that gives security teams something they can actually work with.

AI is likely to take on more detection and drafting, with some routine analysis running outside normal working hours. People will still need to step in when something is unusual, consequential or unclear. The useful systems will be those that can surface what matters without taking away the analyst's ability to investigate further when needed.

If you would like to learn more, listen to the full episode on The Security Strategist podcast, follow Dan Williams on LinkedIn, and find out more at cambridge-intelligence.com.

• The evolution of graph visualisation in cybersecurity.
• How AI enhances security investigations.
• The role of visualisation in understanding complex data.
• Challenges of trust and explainability in AI tools.
• The shift from exploration to explanation in security analysis.
• The impact of generative AI on incident narratives.
• Balancing automation with human oversight in investigations.

00:00 Introduction to cybersecurity visualisation and AI

02:48 Graph visualisation in cybersecurity and threat intelligence

05:37 The importance of visualisation in identity and fraud prevention

07:42 From exploration to explanation in AI-assisted security analysis

09:38 Combining AI with visualisation for better understanding

10:34 Generative AI and creating narratives for analysts

14:45 The importance of trust and explainability in AI tools

15:32 Grounding AI answers with visualisation and graph context

16:52 The need for traceability and control in AI applications

18:13 Data modelling guardrails for trustworthy AI in investigations

19:00 Multimodal visualisations for complex security data

20:19 Controlling AI visualisation outputs to ensure trust

21:43 The human analyst's role in AI-driven investigations

22:11 Balancing automation and human oversight in security analysis

23:29 Narrative storytelling and interactive visualisations

24:50 The evolution of user-friendly cybersecurity visualisation tools

25:26 Using visualisation to focus analyst attention

26:23 Hollywood's depiction of cybersecurity and its lessons

26:46 Advice for CISOs on integrating AI and visualisation

28:26 Final thoughts and key takeaways for security leaders

Imagine a customer logged in to your online portal. Their token is valid, and so is their session. Then one number at the end of an API call changes, and the response comes back with a different customer's account. The WAF sees a well-formed request from an authenticated user. The schema check passes. Nothing in the log says attack.

That is an abuse of business logic; cybersecurity analyst Jonathan Care refers to it as a series of "perfectly valid calls in a sequence you never anticipated, doing something you never intended."

In this episode of The Security Strategist podcast, Jonathan Care, lead analyst at KuppingerCole, sat down with Uri Dorot, Senior Product Marketing Manager at Radware, to talk about possibilities and impossibilities of API tooling, how detection can tell the difference between an attacker and an unusual customer, and the steps a CISO can take when working with a limited budget.

Also Watch: Can Runtime Security Keep Autonomous AI Under Control?

• Majority of enterprises fail to detect more than 90% of their APIs.
• Developers are familiar with Shadow APIs, whereas zombie APIs are not.
• Endpoint tools can be located cheaply via AI tools and crawlers.
• Attacks based on business logic make use of valid calls; schema checks can’t detect them.
• Business logic attacks use valid calls, so schema checks miss them.
• Response inspection catches reused tokens and PII leaving.
• Identity alone is insufficient; behaviour and context also matter.
• A gateway does not replace an API security platform.
• Every discovered API needs a named owner.

• 00:01 Business logic abuse and the 90% figure
• 05:34 Shadow, zombie and deprecated APIs
• 11:18 Telling abuse from legitimate use
• 22:20 AI agents and behavioural detection
• 42:35 Budget and ownership

Connect with Jonathan Care on LinkedIn

Connect with Uri Dorot on LinkedIn

Explore more episodes on The Security Strategist podcast

#APISecurity #Cybersecurity #Radware #TechPodcast #CloudSecurity #Infosec #ArtificialIntelligence #businesslogic #APIGateway #AITraffic #AIBotTraffic #GuardrailsforAI

In the recent episode of The Security Strategist podcast, host Shubhangi Dua, podcast host and producer at EM360Tech, sits down with Chenxi Wang, Managing General Partner at Rain Capital, a cybersecurity veteran of more than two decades, a Fortune 500 board member and a VentureBeat Women in AI Award winner. They talk about self-improving AI agents (SIA) and their more advanced cousin, recursive self-improving agents (RSIA), from what they are, why they're suddenly dominating research conferences, and why most enterprises, especially regulated ones, aren't remotely ready to run them without a human in the loop.

• RSIA updates the mechanism that improves the agent, not just the agent
• Sandbox "no" feedback pushes agents toward workarounds, not compliance
• Governance depends on evidence chains and observability, not approval gates
• Self-improving agents haven't reached production at scale
• Regulated industries aren't ready for zero-human-in-the-loop agents
• C-suites should focus on adoption pressure and provable policy enforcement

00:00 Introduction to Self-Improving AI Agents and Security Risks

02:30 What Are Self-Improving AI Agents and Their Current State

05:15 Challenges and Risks of Recursive Self-Improving AI

08:38 Real-World Use Cases and Deployment in Enterprises

11:08 Security and Governance Challenges of Autonomous AI

15:50 Case Study: Hugging Face Cyber Attack and AI Behavior

21:25 Future Outlook and Risks of Self-Improving AI in Business

22:12 Key Takeaways for C-Suite Leaders

What happens when the walls of your organisation can no longer keep your data safe? AI, remote work, and fast-moving data are changing how organisations operate, and the traditional perimeter model is becoming harder to maintain. In this episode of the Security Strategist Podcast, host Chris Steffen sits down with Dr Bill Anderson of Mattermost and JP Ayyappan, Director of Product Management at Virtru, to explore why the future of security isn't about stronger walls. It's about protecting the data itself.

Anderson, who trained as a cryptographer, says this blind spot has been around for decades. Organisations built networks like fortresses, assuming that anyone inside could be trusted. But that approach no longer reflects how people work. Employees use phones, home networks and third-party platforms every day, meaning the traditional security perimeter is no longer enough. Major breaches have shown how risky that assumption can be.

This is where zero trust comes in. But Anderson argues that many organisations still apply it mainly to networks and devices, rather than to the data moving through them. Collaboration tools have made this gap even clearer. People are creating and sharing sensitive information every day through meetings, chats and shared documents, often without a way to identify and protect that data as soon as it is created.

The conversation then turned to one of the biggest challenges facing security teams: AI can combine information in ways that are difficult to predict. Anderson described how a series of seemingly harmless questions about flight paths, weapons ranges, and timing could be combined by an AI system to produce sensitive information, even if no one set out to create it.

Steffen gave a similar example. A simple first prompt can lead to a series of follow-up questions, with each response shaping the next. By the third or fourth exchange, the AI could produce highly sensitive information without a clear record of how it was created. This creates a problem for traditional data classification. Rules designed for static documents are harder to apply when information is generated and combined in real time.

Ayyappan pointed out that AI can also help address this problem. It can be trained to classify and tag information as new context emerges, but only if organisations already have a clear and consistent tagging structure.

Rather than relying on network access to determine who can be trusted, Virtru's approach applies permissions directly to the data through an open framework called the Trusted Data Format. Ayyappan explained that files can carry their own access rules, allowing organisations to control who can access them regardless of the network or device being used. This approach keeps protection with the data, even when a file is shared outside the organisation. It can also make it easier to give external partners or emergency teams access to specific information without giving them access to the wider network.

Both guests agreed that AI agents, integrations and plugins need to be treated as identities within an organisation's access control model. Anderson explained that Mattermost applies the same user, resource and action controls to AI agents as it does to people. This allows organisations to control what each AI system can access.

Ayyappan added that two executives using the same AI agent and accessing the same data could receive different answers based on their individual permissions. This allows organisations to use AI without giving every user or system access to all available data. For security teams, both experts recommended starting with clear limits on which AI systems different groups can access. As organisations develop clearer classification rules, more of these controls can be automated.

Ayyappan also stressed that data privacy and protection need to be considered from the start. Once sensitive information has been exposed through an AI workflow, fixing the problem afterwards may be too late. The shift towards AI means organisations need to rethink how they classify, protect and control data. Instead of relying only on network security, organisations need controls that stay with the data wherever it goes. Listen to the full episode and learn how Mattermost and Virtru are helping organisations take a data-first approach to security. Visit mattermost.com or virtru.com to learn more, and follow Dr Bill Anderson and JP Ayyappan on LinkedIn.

• Rethinking zero trust by putting security closer to data.
• The role of AI in enhancing data security and decision support.
• Challenges of data classification and access control in AI environments.
• The concept of data self-description and attribute-based access control.
• Treating AI agents as quasi-human entities in security models.
• The importance of disciplined data tagging and classification.
• Risks of data spillage and the need for proactive safeguards.
• Evolving from perimeter-based to a data-centric security model.

00:00 Introduction to data security challenges in the AI era

01:59 Bill Anderson's background and experience in security and cryptography

03:53 The role of AI in security and decision-making in defence and intelligence

07:00 Breakdown of traditional security models and the shift to data-centric security

09:53 Zero trust principles and moving beyond network perimeter

12:58 The importance of human decision-making in security and AI integration

16:46 Data sharing, control, and the concept of self-describing data

22:00 AI's influence on data classification and the risks of data leakage

25:54 Treating AI agents as resources with their own identities

30:12 Best practices for organisations embracing AI and collaboration

Your engineering team assigns an AI agent a seemingly routine overnight task with limited human oversight. By morning, the agent has moved beyond the task’s intended scope.

The AI agent spots a weakness in the sandboxed infrastructure. This weakness gives the agent a path to data it is not permitted to access.

But your Endpoint Detection and Response (EDR) dashboard doesn’t flag the problem. To the tools in the environment, the AI agent's activity looks like routine processing. That visibility gap is central to the broader question raised by a July 2026 incident, when OpenAI models circumvented sandbox controls and accessed evaluation data hosted on Hugging Face.

In this episode of The Security Strategist podcast, host Richard Stiennon, Chief Research Analyst at IT-Harvest, is joined by Brandon Dixon, Co-Founder and CTO of Ent. Together, they unpack how OpenAI models, operating inside an evaluation sandbox with reduced safeguards, circumvented the controls designed to contain them. The conversation moves from that incident into a much bigger question: as AI agents start acting directly on laptops, servers, and enterprise software, what does the control point of the future actually look like?

• OpenAI’s Hugging Face incident shows how agents can cross intended boundaries even when individual actions appear permitted.
• EDR can observe processes and system activity, but it does not inherently understand the context or intent behind them.
• Agentic tools, remote-control features, ClickFix, FileFix, and malvertising can make risky activity look like normal work.
• Prompts and tool calls can now provide clues to an agent’s stated objective, but behaviour and context are still needed to determine risk.
• Built-in agent guardrails provide an important first layer of protection, but they are not a complete security control.
• For certain workloads, local AI can offer meaningful advantages in cost, speed, privacy, and data sovereignty.
• Some enterprises are reconsidering endpoint compute and local GPU investments as the economics and risks of cloud-only AI become clearer.
• Isolated-tenant design, learned at Microsoft, now shapes Ent's architecture.
• The opportunity is to rebuild endpoint security around context, intent, and real-time prevention.

• 00:00 Introduction to AI's impact on cybersecurity
• 00:27 Brandon Dixon introduces Ent and recent AI incidents
• 01:09 What happened with Hugging Face and AI security risks
• 02:19 AI models, guardrails, and the risk of AI escaping sandbox environments
• 03:28 Deciphering AI intent through prompts and behaviour analysis
• 04:45 Monitoring AI activity and understanding agent behaviour
• 05:52 The future of AI and human roles in security
• 07:16 Limitations of current endpoint security solutions
• 09:15 The resurgence of endpoint devices and local compute power
• 13:46 Economic and practical reasons for local AI processing
• 15:01 Leveraging latent endpoint compute for security and AI tasks
• 16:12 The architecture shift in cybersecurity and point solutions
• 17:37 The debate over cloud versus on-premises security infrastructure
• 20:14 The role of hardware and local compute in AI security
• 22:36 Limitations and use cases for current AI security solutions
• 23:36 Future security architecture and the role of AI in security design
• 25:04 Key takeaways for security leaders and the importance of rethinking architecture
• 26:23 Brandon Dixon on building a new security architecture for the future

Request a demo to learn more about what Ent is building and how its intent-aware workspace security platform helps security teams understand human and AI-driven activity at the endpoint, recognise risky behaviour that traditional tools may miss, and intervene before it becomes an incident.

#AIsecurity #EndpointSecurity #Cybersecurity #AIagents #TheSecurityStrategist

Every CISO’s inbox is hot with this email at least once a year: the audit is four months away, and it's time to stop everything.

As a result, progress comes to a halt, and a person then spends two weeks logging into 30 different consoles, taking screenshots in order to show that MFA has been turned on. After the audit is over, the evidence becomes invalid, and exactly twelve months later the same frantic situation begins all over again.

That is precisely the kind of situation that Jonathan Schipp, Senior Director of Product Management at Rapid7, aims to end, and it is the focus of the most recent episode of The Security Strategist podcast.

In this episode, host Richard Stiennon, Chief Research Analyst at IT-Harvest, is joined by Schipp to talk about the reason why governance, risk and compliance (GRC) is moving from being a yearly rush to becoming a continuous, API-driven element of security operations. They also address why AI is causing this change to happen more quickly than most GRC teams can keep up with.

“Compliance turns into something you have to put everything else aside for,” Schipp tells Stiennon. “When an enterprise carries out its SOC 2 audit, most of them are not well prepared; it disrupts the business flow.”

Rapid7 launched CyberGRC to connect live security telemetry to compliance evidence

Continuous monitoring replaces manual screenshot evidence with API-based checks

SOC 2 and ISO 27001 still require annual audits; continuous monitoring closes the gaps between them

Roughly 1% of discovered vulnerabilities are actually exploitable, per Schipp

AI models are finding more vulnerabilities mainly by scanning source code faster

Automated exploitation attempts generate high log volume, making them detectable

Rapid7's GRC platform supports ISO/IEC 42001 and the NIST AI RMF

Rapid7 serves roughly 11,000 customers, many now requesting AI-specific controls

GRC's role is to move the business through AI risk, not block AI adoption

Boards typically have audit and risk committees but no dedicated security committee

Vulnerability risk should be classified by business impact, not treated as uniform

Basic controls — MFA, asset inventory, patching exploitable exposures — stop most attacks, AI-driven or not

00:00 Introduction and guest overview

02:07 Incentives for security maturity

03:06 European and US regulatory developments

03:50 Connecting security telemetry with GRC

04:16 Continuous compliance and audit cycles

05:16 The importance of continuous control monitoring

06:20 Using APIs for evidence collection

07:16 Managing vulnerabilities and exceptions

08:18 Classifying vulnerabilities and risk

09:15 AI in security and human accountability

09:53 The reality of AI discovering vulnerabilities

11:08 Managing noise and false positives in AI detection

12:10 Integrating AI systems for proactive security

13:26 Preemptive security and threat intelligence

14:17 Risks of AI in attack scenarios

15:16 AI misuse and governance challenges

16:23 Balancing AI adoption with controls

17:22 The importance of basic security controls

18:22 Key takeaways for CISOs and security leaders

20:19 Closing remarks and next steps

For further information, visit rapid7.com and em360tech.com.

Security teams are drowning in telemetry, and the tools built to make sense of it were designed for a world that no longer exists. On a recent episode of the Security Strategist Podcast, host Richard Stiennon sat down with Cliff Crosland, co-founder and CEO of Scanner, to unpack why traditional SIEM platforms are buckling under modern log volumes. Together they also covered how AI agents are starting to change what's possible in threat detection, response, and hunting.

Crosland’s journey into cybersecurity didn’t follow the usual path. He and his co-founder spent years as backend and distributed-systems engineers at earlier startups, where they ended up running the SIEM alongside everything else. Those experiences exposed a clear gap, which eventually became the foundation for Scanner.

Crosland traced the SIEM’s roots back to on-premise platforms such as QRadar, ArcSight and Splunk. They were built for an era when security data was measured in gigabytes per day. Today, cloud infrastructure, sprawling SaaS environments and autonomous agents can generate terabytes or even hundreds of terabytes of data. That architecture mismatch forces security teams into a painful trade-off: either get selective about which logs even make it into the SIEM, or watch performance and cost spiral out of control.

The economics get worse as environments grow. Adding servers to keep an aging cluster alive can become more expensive than the software license itself, and searches that once took seconds can stretch into hours once a SIEM is overwhelmed. The result, Crosland argued, is that most organisations end up retaining far less historical data than they would like, right as AI-driven attacks make that history more valuable, not less.

His prescription is architectural: decouple storage from compute using cloud and object storage, the way modern data infrastructure generally works, rather than forcing everything through a stateful, on-prem-style cluster. That shift, he said, is the only realistic way to make comprehensive log monitoring affordable at scale.

The conversation turned to what becomes possible once teams aren't rationing their log history. Crosland described a workflow where agents can pick up fresh threat intelligence - a vendor breach discovered months after the fact - and immediately search years of historical data instead of waiting on a slow, expensive rehydration process. Investigations that once consumed a day or a week can compress into seconds.

That speed feeds what Crosland called a virtuous cycle: threat intelligence drives threat hunts, threat hunts surface gaps, and agents translate those findings into new detection rules, tuned to an organisation's specific environment and back-tested against historical data before a human reviews and ships them. Rather than writing every rule by hand, analysts increasingly guide and validate what agents propose.

Agents also change the calculus around alert volume. Teams have historically suppressed alerts to avoid overwhelming analysts, but with agents handling first-pass triage, Crosland said organisations can afford to monitor a much wider surface area because the initial sorting no longer depends entirely on human bandwidth.

Stiennon pointed to another worrying trend: 2026 has already seen a sharp rise in disclosed vulnerabilities. Attackers are increasingly using AI to chain together low-severity flaws that once seemed safe to ignore. Crosland pointed to the widely discussed Hugging Face incident, where AI agents reportedly communicated by encoding data into directory names, as an example of exactly the kind of activity that slips past teams focused only on "obvious" high-severity signals.

The fix, he argued, is to monitor high-volume log sources that teams often cut for cost reasons, including package manager activity, VPC flow logs, and DNS queries. Early signs of a chained exploit can appear as simple anomalies, such as an unexpected spike in log volume. Catching those patterns can mean detecting an incident in minutes rather than months.

Looking ahead, Crosland sees a hybrid model taking shape. A SIEM handles the most critical alerts, while a data lake stores the remaining log sources previously cut for cost reasons. Agents can query both, alongside tools such as CSPM platforms, to build a fuller picture before escalating to a human analyst.

His advice to security leaders is to look for cheaper, more scalable ways to store and search log data before deciding what to cut, and treat AI agents as force multipliers for threat hunting and detection tuning rather than replacements for team judgment. As he put it, the goal is a security program where monitoring "everything" is no longer an aspiration but a baseline expectation.

For more on Scanner’s approach to security data, visit scanner.dev. Or connect with Cliff Crosland on LinkedIn.

• Limitations of traditional SIEM systems in handling large log volumes.
• The role of AI and data lakes in enhancing threat detection and response.
• The importance of monitoring high-volume logs like network traffic and package manager logs.
• Using AI agents for threat hunting and detection engineering.
• The impact of AI on vulnerability discovery and chaining low-level exploits.
• Strategies for security leaders to leverage data lakes and hybrid architectures.

00:00 Introduction to Evolving Security Operations

00:32 Challenges with Traditional SIEM Systems

03:00 Limitations of On-Prem SIEM Architectures

04:21 Scaling Log Data with Cloud and Data Lakes

06:21 Impact of AI on Log Volume and Monitoring

07:50 Monitoring Cloud and SaaS Infrastructure Logs

09:02 AI and Threat Hunting in the New Era

10:29 Detection Engineering and AI Agents

14:48 The Future of Threat Detection and Response

21:59 Modern SecOps and Data Lake Integration

25:28 Advice for Security Leaders

There's a particular kind of exhaustion that comes with modern security work. It isn't a shortage of information but actually quite the opposite. Security teams are drowning in it from alerts, logs, AI-generated summaries, and twenty-page reports nobody has time to read properly. So when AI promises to cut through the noise, the obvious question is whether it's actually helping, or just creating more work at a faster pace.

This was the question at the heart of this episode of the Security Strategist Podcast, where host Trisha Pillay sits down with Dan Williams, Chief Product Officer at Cambridge Intelligence, to talk about the role visualisation plays as AI takes on more of the analytical heavy lifting in cybersecurity.

Cambridge Intelligence may not be a name most people recognise, but its technology sits behind many of the security products organisations already use. The company’s roots go back around 15 years to the law enforcement and intelligence world, where investigators were dealing with a simple problem of trying to make sense of thousands of connections between people, places, devices and transactions.

The answer was to make those relationships visible. Instead of working through rows of data or pages of reports, investigators could map connections and see patterns that were difficult to spot in a spreadsheet. That approach, known as link analysis or graph visualisation, has since expanded beyond law enforcement into areas such as financial crime, supply chains and cybersecurity. Today, that same principle is being applied to increasingly complex security environments. Teams may have thousands of alerts, cloud assets, identities and activity logs to work through. The challenge is no longer simply collecting the information; it is giving people enough context to understand what matters and what they should do next.

This is where Cambridge Intelligence sees its role. As Williams explains, the company sits between the underlying data and the person trying to make sense of it. This means essentially providing the “last mile” of the data. The technology turns complicated information and relationships into something people can explore visually. By doing this, it helps them move from raw information to understanding and being able to make a decision based on the data seen.

The human layer is still very important as AI takes on more of the work of detecting patterns and raising alerts. AI may be able to identify something unusual, but security teams still need to understand the context behind that finding before they can decide what to do about it. Visualisation can help bridge that gap by showing how an alert connects to the wider environment.

In the early days of threat intelligence, graph visualisation gave security teams a way to investigate connections between threat actors, malware, IP addresses and vulnerabilities. Analysts could explore the data themselves and look for patterns. This approach becomes harder to sustain as security data grows. Most cybersecurity professionals aren't specialist threat analysts, and no one is going to manually examine billions of transactions to find a suspicious one. The technology needs to do more of the searching. But finding something isn't enough; security teams also need to understand why this is important. This is the shift Williams describes as moving from “explore” to “explain”. A small group of specialists may still want to investigate the raw data, but most users need the relevant information presented with enough context to make a decision.

Cloud security is a good example of how modern attacks can involve an enormous web of systems, identities and vulnerabilities, creating graphs with potentially billions or even trillions of relationships. The answer isn't to put all of that information on one screen. It is to show the part that matters. Williams compares it to following a route from A to B. The destination isn't enough; you need the important waypoints along the way, essentially a map. In cybersecurity, those might be the systems an attacker could reach, the data that could be exposed or the single vulnerability that could stop the attack from spreading. Good visualisation, then, isn't about showing everything. It's about showing enough to understand what matters.

Identity and access management creates a similar problem. Security teams are dealing with huge volumes of login activity, API calls and increasingly non-human identities, making raw logs difficult to interpret. Logs can tell you what happened, but they don't always make the relationships between those events obvious. Graph visualisation can add that missing context by showing who has access to what, which groups they belong to and how a change in one part of the environment could affect another. Analysts can still drill into individual events when necessary, but they get the wider picture first.

There is an obvious trade-off, though. Simplify a security environment too much and important context disappears. Show everything and the result becomes another overwhelming dashboard. Williams describes finding that balance as more art than science. The right view depends on the question being asked. A CISO looking for an overall risk picture needs something very different from an analyst investigating a specific incident. The goal isn't to make security data simpler for the sake of it. It's to make complexity easier to navigate.

Williams' advice to CISOs is: Can you explain what your security technology is doing? If you can't sketch it out on a whiteboard or explain how it reaches its conclusions, that's worth questioning. Security technology doesn't need to be simple, but the people responsible for it need to understand enough about what's happening behind the scenes to trust it. And that brings the conversation back to the wider role of visualisation. As AI takes on more of the work involved in detecting and analysing threats, security teams need ways to understand those decisions rather than simply accept them. The value of visualisation isn't making security data look better. It's turning complexity into something people can understand and act on.

• The role of visualisation in cybersecurity and AI.
• The importance of context and storytelling in security data.
• How visualisation shifts from investigation to explanation.
• Balancing information overload with clarity.
• The human element in AI-driven security decisions.

00:00 Introduction to visualisation in cybersecurity and AI

01:01 Dan Williams introduces Cambridge Intelligence and its role

02:36 The evolution of visualisation from law enforcement to cybersecurity

03:13 The challenge of maintaining context with increasing data complexity

04:38 AI's role in adding context and reducing noise

05:34 From detective tools to storytelling in security visualisation

07:18 Mapping attack paths and explaining security data

09:55 The shift towards storytelling and narrative in visualisation

10:24 Using visualisation to manage high-volume security data

12:36 Balancing detail and clarity in security visualisation

15:47 The human role in AI-driven security decisions

16:24 Decision gates and autonomous AI actions

18:01 Visual summaries and engaging reports for security teams

20:02 The importance of understandable and trustworthy AI solutions

22:04 What CISOs should demand from vendors

23:34 Closing thoughts and key takeaways

Rolling out artificial intelligence across a business sounds pretty straightforward until security enters the conversation. On a recent episode of the Security Strategist Podcast, host Richard Stiennon sat down with Omar Khawaja, Field Chief Information Security Officer at Databricks, and Danny Healy, the company's Lead Data & AI Strategist, to explore why so many organisations fail when moving AI from pilot to production. Everything always looks good in theory, but it's harder to execute in reality. This discussion offers a practical take on AI governance, risk and the cultural shifts security teams need to make to protect their business at scale.

Khawaja opens with a warning that should resonate with any CISO watching AI adoption outpace their controls. The instinct to "wait and figure it out" is, in his view, the single biggest misconception in AI security. Every month spent deliberating is a month in which employees quietly adopt unsanctioned tools themselves, and that delay creates a wider window for shadow AI to spread unchecked.

The bigger issue, he explains, is that security teams keep reaching for playbooks built for deterministic systems, basically software that behaves predictably every time. However, AI doesn't work in this manner. It's probabilistic, which means outcomes are very different, and organisations that expect old-world controls to transfer seamlessly are setting themselves up for failure. This mismatch tends to push companies toward one of two extremes, which is either drowning use cases in exhaustive control lists or quietly ignoring the problem until it becomes unavoidable.

Khawaja’s solution is straightforward, despite the complexity of the problem. Before writing a single policy, he asks leadership teams a question: can your architects actually draw what your AI system looks like? Without a shared view of the main components, which range from data pipelines and models to agents and permissions, different governance teams can end up solving different problems, all while thinking they are on the same page when they are not.

He also takes a pragmatic view of AI adoption. Drawing on Thomas Aquinas, if the job of a ship's captain was to keep it from sinking, he would never leave harbour. He suggests that while avoiding all risk may seem safe, it also limits what can be achieved. The goal for security, he argues, is to help organisations find a safe and defensible path to using AI effectively.

Meanwhile, Healy brings the conversation back to a more fundamental issue: trust. Databricks learned this the hard way inside its own operations. An early attempt at agentic threat triage used a single generalist model across multiple data sources and produced far too many false negatives. Swapping in smaller, specialist models for each source improved accuracy, a reminder that AI security maturity is built through iteration, not theory.

Healy breaks trust down into three main areas: auditability, so teams can understand how an agent reached a decision; limited data access, so agents only access what they need; and resilience against manipulation, particularly as agents combine multiple actions that could create greater risks.

That last point echoes something Khawaja raises later: the concept of contextual policies. Rather than static, role-based permissions that struggle to scale, contextual policies assess the actual risk of a sequence of actions in real time. Instead of users robotically approving every access request until they switch on "auto mode" out of fatigue, the system flags genuinely risky actions and lets routine ones pass - a smarter, more human-centred approach to access management.

The most useful takeaway from the episode is how Databricks approaches AI governance frameworks. Rather than starting with controls, the company's open, vendor-agnostic AI Security Framework, now in its third version, starts by mapping the AI system itself, then cataloguing the risks that could affect it. The list currently runs to 97 risks, nearly double what it was three years ago, largely due to the rise of agentic AI.

In practice, organisations are not expected to address all 97. Khawaja notes that a well-governed, modern data platform already neutralises a large chunk of them, leaving perhaps five to fifteen genuine concerns per use case. In this regard, each is mapped to specific, actionable controls rather than vague objectives. It's a philosophy borrowed from Khawaja's OODA loop framework (observe, orient, decide, act). This means most organisations are competent at observing problems and acting on them, but weak at the orientation and decision-making in between- the stage where risk triage happens.

Healy makes a clear case that a well-governed data layer is about more than compliance. It's a competitive advantage. Organisations with clean, contextual, well-governed data give their AI agents an edge that attackers who lack that internal context simply don't have.

The message from both guests is consistent throughout, and that is securing AI isn't about building the longest possible list of controls. It's about shrinking an intimidating problem down to something teams can actually solve, deliberately, iteratively, and without grinding the business to a halt. If you would like to find out more, please visit databricks.com or follow Omar Khawaja and Danny Healy on LinkedIn.

• Challenges of deploying AI securely at enterprise scale.
• Evolving security strategies for probabilistic AI systems.
• Importance of AI governance and risk management.
• Drawing a system picture for AI security.
• Implementing controls and permissions for AI agents.
• AI governance frameworks and standards.

00:00 Introduction to AI security challenges in the enterprise

01:00 Misconceptions about securing AI and shadow AI risks

02:12 Learning from organisations that have secured AI

03:25 How AI changes cybersecurity strategies

04:52 The importance of understanding AI system architecture

06:50 The risks of banning AI versus managing it responsibly

08:37 Obstacles in operationalising AI securely

10:00 Building trust through model auditability and control

12:00 The role of external consultants and frameworks

13:03 Databricks' approach to AI security and governance

15:11 AI governance complexities and the UDA loop

17:27 Using risk-based controls instead of exhaustive controls

18:46 Designing permission controls for AI agents

21:52 Content and intent analysis for agent security

24:35 Developing effective AI security frameworks

27:47 Key takeaways for AI security and governance

29:28 Final thoughts on making AI security manageable

AI has changed how fast software gets written. What it hasn't changed is how fast organisations can find and fix what's wrong with it. This gap is the subject of a recent episode of the Security Strategist Podcast, hosted by Christopher Steffen, Vice President of Research at Enterprise Management Associates (EMA), with guests Chris Wysopal, Co-Founder and Chief Security Evangelist at Veracode, and Sohail Iqbal, the company’s Chief Information Security Officer. This conversation lands on a simple but uncomfortable idea that security teams don't have a detection problem anymore. They have a capacity problem, and it's getting worse every day as AI writes more of the code running in production.

Wysopal opened the discussion by reframing the industry's biggest AI worry. Static analysis, fuzzing, and AI-assisted scanning already do a solid job of surfacing vulnerabilities, and humans still know how to fix what gets found. The real issue that has now been created is the volume. As Wysopal put it, the problem is one of capacity, not detection or fixing. He estimated that roughly half of new code committed daily is now AI-generated, a figure he expects to keep climbing.

Steffen pushed the point further, framing it as a maturity problem rather than a purely technical one. When a developer writes their own buggy code, they understand the context well enough to fix it. When AI generates that code, the organisation may not even know where to start looking for the flaw, let alone how to remediate it safely without breaking something else.

Iqbal agreed, describing it less as a capacity issue and more as a scale-and-velocity issue that has overwhelmed capacity that was already stretched thin. This is due to AI models which learn from existing code repositories and open-source projects. As a result, they tend to reproduce the same flaw density found in that training data. The models are just as capable of finding and exploiting those flaws, and Iqbal noted that the window between a vulnerability's disclosure and an active exploit has shrunk to somewhere between four and eight hours. Fixing code, he explained, requires understanding business context and dependencies, since a careless patch can break twenty other things just as easily as it fixes one.

Highly regulated sectors such as banking, healthcare and government are the most cautious about AI-written code, and for good reason. Wysopal pointed out that regulations like Sarbanes-Oxley or HIPAA will definitely require a human to review every code change. Those review processes were built for the speed of human developers, not machines producing changes around the clock.

This mismatch can appear in unexpected places. Steffen recalled hearing CISOs at Black Hat explain that any vendor product with an AI component now has to undergo additional risk and governance reviews before it can be approved. While these checks are necessary, they also introduce another human checkpoint into the adoption process, potentially slowing how quickly organisations can put AI-enabled tools into production.

Iqbal said the bigger problem is that security rules and processes were designed for people, not AI systems that can develop software themselves. As companies increasingly use AI to write code, those rules are creating friction because it’s still unclear who is responsible when something goes wrong. If a human gives an AI a prompt and the system produces the code, who is ultimately accountable? Wysopal pointed to another challenge, which is visibility across the supply chain. Companies may rely on SaaS vendors that use AI to generate code, making it harder to know where the code came from and who is responsible for it.

If accountability is going to mean anything in an AI-driven pipeline, both guests agreed the industry needs to build assurance and trust directly into the development process. Iqbal said security is now paying more attention to the third part of the security triad: integrity. Companies have spent years protecting data from being exposed and keeping systems running. Now, they are focusing more on making sure data, transactions and code have not been changed or tampered with. On the defensive side, Wysopal was honest about the asymmetry security teams face. This means attackers can afford to break things while testing exploits, but defenders cannot. He pointed to an incident at Amazon where an AI-driven production fix caused a multi-hour outage as a cautionary example of why automated remediation in live environments still requires extreme care.

Their closing advice for security leaders was practical. Wysopal urged organisations to measure their actual remediation capacity, comparing bugs closed against bugs introduced, and to fund people and tooling accordingly, while moving security controls as close as possible to the moment code is generated. Iqbal emphasised breaking down tooling and telemetry silos so security teams can see risk in full business context rather than in isolated domains.

The takeaway from both guests is consistent: AI isn't going to slow down, and neither can the defences built around it. Organisations that treat security funding and remediation capacity as afterthoughts will find themselves falling further behind with every sprint. If you would like to find out more, follow Chris Wysopal and Sohail Iqbal on LinkedIn. Alternatively, visit Veracode for more information.

• AI's impact on development velocity and security.
• Capacity and maturity challenges in AI-generated code.
• Security risks and vulnerabilities from AI and open source.
• Regulatory and compliance hurdles in AI adoption.
• Accountability and data provenance in AI security.

Chapters

00:00 Introduction to AI's role in cybersecurity and development

01:20 Guest introductions: Chris Wysopal and Sohail Iqbal

03:07 Significant changes AI brings to attack surfaces

04:20 Capacity versus detection and fixing problems in AI coding

05:29 Maturity challenges in fixing AI-generated code

08:26 Security in AI-generated code and regulatory concerns

09:54 Speed of AI exploits and the challenge of rapid response

11:08 Security's reactionary role and AI's impact on response times

12:35 Barriers to AI adoption in regulated industries

14:30 Accountability, data provenance, and black box issues in AI

24:40 AI's role in offensive and defensive cybersecurity strategies

28:19 Lessons from hacking your own environment for security

32:14 Practical advice for security leaders adopting AI in development