The Security Strategist

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.
Why Shadow AI Grows on Indecision
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.
Why Trust Comes Before Speed
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.
From 97 Risks to a Focused Shortlist
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.
Takeaways
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.

Chapters
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.
AI Code Is Creating a Security Crisis
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.
Regulation Is Slowing AI Adoption
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.
Building Trust in the Software Supply Chain
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.
Takeaways
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

Although AI is currently in control of the boardroom agenda, a discussion on the latest The Security Strategist podcast suggests that enterprises might be posing the wrong first question.
The real AI problem isn't just how many AI models an enterprise can deploy, but whether the data that powers the AI model is protected, can be recovered, is affordable, and is, in fact, usable.
Chris Steffen, Host and Vice President of Information Security at Enterprise Management Associates (EMA), is joined by Randy De Meno, Vice President of Business Development and responsible for the Microsoft practice at CrashPlan, on The Security Strategist podcast. They claim that data strategy should come before AI strategy since enterprises are facing rising storage costs, token sprawl and ever more complex cloud environments.
They particularly talk about the growing relationship between AI, Microsoft 365 storage, SaaS data, backup, archiving, data recovery and AI token sprawl.
As enterprises generate increasing volumes of data and deploy more AI applications, the cost and security implications are becoming harder to ignore. Microsoft 365 and other SaaS platforms may keep applications running, but organisations remain responsible for protecting and recovering their data.
The conversation explores why enterprises need to think about data strategy before AI strategy, including how to control storage overages, protect business-critical data, make protected data usable with AI, and ensure data can actually be found and recovered when needed.
In this episode:
00:00 Introduction to Data and AI Challenges in Cybersecurity
01:23 CrashPlan's Role in Data Resiliency and AI
03:49 The Cost of SaaS Storage and Data Overages
07:31 The Evolution of Backup and Data Usage with AI
12:29 The Impact of Token Sprawl on AI and Budgeting
18:57 Understanding the Shared Responsibility Model in Cloud Security
23:28 Making Data Easy to Find and Use
24:52 Closing Remarks and Future Outlook
Key topics
• Microsoft 365 storage costs and overages
• AI data storage and enterprise AI costs
• AI token sprawl and technology budgets
• Microsoft 365 backup and data protection
• SaaS data archiving
• Enterprise data recovery and resilience
• AI data security and governance
• Making protected data searchable and usable
• Cloud shared responsibility
• Microsoft 365 and Google Workspace data protection
The discussion highlights a critical question for IT and security leaders: Is your enterprise protecting the data that its AI strategy depends on — and can you recover it when you need it?
Learn more about CrashPlan's approach to Microsoft 365 data archiving and protection:
https://www.crashplan.com/resources/crashplan-archiving-for-microsoft-365/
Read the guide:
https://www.crashplan.com/resources/guide/are-you-headed-for-a-microsoft-365-storage-overage/
Visit CrashPlan:
https://www.crashplan.com/
#Microsoft365 #AI #DataProtection #Cybersecurity #DataBackup #AIData #TokenSprawl #CloudSecurity #DataRecovery #EnterpriseAI

Especially as rogue AI agents are increasingly escaping safe testing environments, such as OpenAI’s rogue AI agent attacking Hugging Face, it’s now more important than ever for enterprises to implement AI agent identity governance strategies that prevent unauthorised access to their systems.
As AI agents seem to be turning into employees in enterprises, the majority of identity security strategies were never created with software that can act on its own.
As a result, a new security issue has emerged concerning AI agent identity governance and the security of non-human identities (NHI). Since enterprises are now using agents who can access data and choose tools while carrying out actions on the employee's behalf, the conventional approach of granting access once and then reviewing it later is starting to appear increasingly unsuitable.
Levent Besik, Chief Product Officer at SailPoint, believes that the solution is continuous authorisation. It means evaluating, as soon as an AI agent tries to carry out a particular action, whether it should be allowed to do so.
In the recent episode of The Security Strategist podcast, Besik joined host Nitish Deshpande, a Senior Analyst at KuppingerCole, to talk about why AI agent governance needs restrategising, starting with continuous authorisation for non-human identities. Besik said that identity had to be something that you assessed at every action rather than something that you could check simply at the door.
“The question most security leaders are asking is: Is this AI agent authorised with one-time permission?” Besik added, “It should be: Is this specific action by this agent on behalf of this human that has access to this data still authorised right now, in that very moment?”
However, it goes to show a pivot from the static provisioning time process to a continuous, real-time plane of authorisation. “Identity has to be evaluated at every action, not something you can check once at the door,” Besik said.
The change is necessary in a rapidly changing technology environment in the cybersecurity industry. In the past, human identities have been the main focus in the area of identity and access management (IAM), but the growing influence of agentic AI is quickly increasing the number of non-human identities working within enterprise environments.
Why does AI Agent Governance Need an Audit Trail?
According to Besik, businesses need three basic principles: human ownership coupled with deep context, an unchangeable record of agent activity, and constant risk assessment.
A real-time ledger of all the agentic activities is what’s needed, the Saipaint Chief Product Officer notes. “An immutable record that agents cannot alter, because we've seen these agents erasing their tracks.”
It’s like "something which you would have read about in a science fiction book ten years ago is now actually taking place."
Without such an unchangeable record, enterprises run the risk of establishing what Besik refers to as "autonomy without accountability".
The other option is what SailPoint refers to as “governed autonomy.” This comes in because an agent should never have the capability to exceed the permissions of a human.
While AI agents can function on their own, they cannot go beyond the permissions granted to the human user they represent; all of their activities can be monitored, and their level of risk is constantly assessed.
For Besik, this eventually leads to a convergence of the governance of human and non-human identities.
He says that the identity, human governance and agentic NHI governance should all be brought together since each side needs the context from the other side. As enterprises go from experimenting with AI agents to putting them into use across their business-critical processes, AI agent identity governance may well serve as the link between AI autonomy and enterprise security.
Takeaways
AI agent governance must go beyond discovery.
Agents need clear human ownership and context.
Authorisation should be validated continuously.
AI security must cover prompts, planning/MCP actions and runtime.
Human oversight should match the level of risk.
Immutable logs are key to agent accountability.
Human and non-human identity governance will converge.

Chapters
00:00 Introduction to the episode and guest
01:01 Levent's background and expertise in identity and security
02:05 Emerging challenges in AI trust and security
03:22 The impact of AI waves on enterprise security
04:21 From static to continuous trust in AI environments
07:19 Discovery as a foundation for AI governance
09:15 Lifecycle management of AI agents
12:39 Real-time protection and continuous authorisation
16:29 Layered security model for AI agents
21:35 Balancing autonomy and human oversight in AI
23:46 Converging human and AI governance strategies
25:37 Final thoughts and industry outlook
Visit sailpoint.com for further information on AI agent governance when dealing with non-human identities (NHI).
AI Agent Identity Governance, AI Agent Security, AI Agent Governance, Non-Human Identity, NHI Governance, NHI Security, Continuous Authorisation, AI Identity Security, Enterprise AI Security, Agentic AI, Autonomous AI, Identity Governance, Identity Security, IAM, AI Access Governance, Shadow AI, AI Agent Lifecycle, AI Agent Discovery, AI Agent Accountability, Runtime Authorisation, MCP Security, AI Governance, Governed Autonomy, SailPoint, KuppingerCole, Security Strategist

AI adoption is moving faster than ever, and many organisations are struggling to put controls in place. Employees are already using AI to analyse information, write content, support decisions and solve problems. As a result, this often happens before security teams have had the opportunity to understand which tools are being used or what data is being shared with them.
For Alan Hamilton, Global Chief Information Security Officer at GAM Investments, this is where the security challenge begins. With more than 20 years in security and responsibility spanning 16 jurisdictions and 32 regulators, Hamilton has seen how quickly a technology can move from experimentation to becoming part of everyday operations. In conversation with EM360Tech Head of Content and Podcast Host Trisha Pillay, he shares that organisations cannot secure what they cannot see.
The issue is not simply whether employees are using AI. It is whether security teams understand how it is being used, what information is entering these systems, and what happens as AI begins to act rather than simply provide answers.
AI Has Already Entered the Workplace
The speed of AI adoption is creating a visibility problem for security teams. Employees can access public AI services with very little friction, meaning the technology can become embedded in workflows before an organisation has established policies, approved tools or monitoring.
Hamilton points to data exposure as one of the immediate concerns. Without appropriate controls, security teams have limited visibility into which AI services employees are using or what information they are putting into them. He describes examples where sensitive financial information was uploaded to a public AI service, forcing an organisation to release results earlier than planned. He also recounts a case where proprietary development code was entered into a public AI tool and subsequently reproduced by the service, compromising what had been a competitive advantage. This makes AI governance a practical security issue rather than a policy exercise.
Hamilton's answer is not to block AI altogether. In his view, attempting to prohibit its use can simply push employees towards less visible services, potentially increasing rather than reducing the risk. Instead, security teams need visibility into AI activity, including the ability to monitor prompts and apply data loss prevention controls to web-based AI services.
This is an important distinction for organisations moving into a more AI-dependent operating model: control does not necessarily mean prohibition.
Security Has to Understand What the Business Needs
Visibility alone is not enough. Security teams also need to understand why employees are turning to particular AI tools in the first place.
Hamilton describes how GAM has approached requests for AI tools outside its approved environment by examining the underlying business requirement. In some cases, a requested capability can be brought into an existing controlled environment. In others, particularly where investment professionals require specialised AI capabilities, the organisation can conduct due diligence and bring appropriate tools into its approved framework.
That approach recognises an uncomfortable reality: the most secure tool on paper is not necessarily the tool that employees will use.
If security departments simply dictate which tools employees can use without understanding their requirements, Hamilton warns that users will look for workarounds. The result is a familiar security problem, but with AI making it easier to create: technology operating outside the organisation's visibility and control.
This becomes particularly important as AI moves beyond conventional chatbots. Once systems are given the ability to take actions, organisations can no longer treat them like ordinary software.
Hamilton argues that AI systems need to be onboarded with clear boundaries, much like a new employee. Organisations need to establish what a system is allowed to do, which patterns it should follow, and what falls outside acceptable behaviour. The reason is straightforward: an AI system does not apply the same ethical judgement as a person. If an action appears to solve the problem it has been given, it may pursue that route unless appropriate restrictions are in place.
And responsibility does not disappear simply because an AI system made the decision. Hamilton stresses that organisations and their executives can still be held accountable for actions taken by AI, particularly in regulated environments.
AI Is Changing the Speed of the Security Game
The other side of the equation is that organisations are not only defending against AI-assisted activity; they are also facing attackers who can use AI to operate faster.
Phishing provides one of the clearest examples. Hamilton describes a dramatic increase in phishing activity, with attacks now changing rapidly in response to defensive controls. On one occasion, his organisation received 17,000 phishing emails between 7 am and 11 am, with hundreds of new rules generated to respond to the changing attacks.
For security teams, this changes the economics of response. A human team cannot manually analyse and respond to thousands of evolving attacks at machine speed. Hamilton's organisation has therefore introduced AI-based email security capable of analysing messages and adapting its rules as attacks change.
The same acceleration is affecting vulnerability management. AI-assisted discovery can uncover large numbers of vulnerabilities in a short period, creating substantial testing and patching workloads. At the same time, attackers can use AI to develop exploits much faster than before, putting pressure on organisations that still operate lengthy patch cycles.
This is where the broader question of operationalising intelligence becomes particularly relevant. As enterprise systems become faster, more autonomous and harder to reason about end-to-end, security teams cannot rely solely on processes designed for a slower environment.
The challenge is not simply adopting AI or defending against it. It is maintaining enough visibility and control to understand what these systems are doing, while building the capability to respond at the speed at which threats now evolve.
For Hamilton, one of the next major security problems will be determining what is real. As AI-generated voices, video and other forms of impersonation become harder to distinguish from genuine interactions, organisations will need better ways to verify identity and establish trust before sensitive actions are taken.
That may ultimately be the central security lesson of AI adoption: what organisations cannot see, understand or verify can quickly become what puts them at risk.
Takeaways
AI adoption in organisations.
Security risks of AI use.
Data and information security challenges.
AI-generated phishing and impersonation.
Security controls and monitoring for AI tools.
Impact of AI on patch management and vulnerability response.
Managing autonomous AI systems and accountability.

Chapters
00:00 Introduction to Alan Hamilton and his role at GAM Investments
01:00 Alan's career background and experience in security
02:20 The rapid adoption of AI and associated security risks
03:15 Data risks from unregulated AI use in organisations
04:33 The impact of AI on competitive advantage and code security
05:23 Visibility and control challenges with employee use of AI tools
08:34 Balancing employee needs and security controls for AI tools
11:12 The rise of AI-generated phishing and its implications
13:00 AI in email security and phishing detection tools
15:20 AI's influence on security response speed and patch management
19:19 Managing autonomous AI systems and their unpredictable actions
22:05 The biggest security challenges as AI becomes more autonomous
23:00 The importance of detecting AI-generated content and impersonation
24:24 Future needs for AI detection tools and security practices