Monica Verma sits on La Fosse’s AI Workforce Council, the group of ten senior technology, data and security leaders helping to shape our Beyond Headcount Blueprint for the future workforce. She is a three-time CISO, an independent AI advisor and the founder of Monica Talks Cyber, where she writes and broadcasts on AI, cybersecurity, technology and leadership to an international audience. Her background spans security and digital transformation leadership across global businesses, and she is recognised as one of the top CISOs in EMEA.
Security, resilience and governance sit at the centre of her expertise, so we took the questions from our audience closest to her world directly to Monica. Here is what she told us, with a short overview and a fuller breakdown for each.
Frontier models are widening the resilience gap. How should businesses respond?
In short. Discovering a vulnerability is not the same as understanding your exposure to it. This is something the latest PHP2Shell critical vulnerabilities, discovered using AI, showed us. PHP runs around 70% of world’s websites and web application. The impact of the exploit would be massive and something we will only find out in the weeks and months to follow. However, just because a vulnerability exists doesn’t mean it will be exploited easily. Most exploits are extremely difficult to write and execute. Frontier models are fast at finding flaws, but organisations still need to map what a real attack scenario would mean for their business before they can call themselves resilient. Monica recommends a five-pillar approach: Data Governance; Strategy and Leadership; Culture, Literacy and Reskilling; Controls and Engineering; and Governance Risk Management.
In depth. Monica starts by separating two things that get conflated constantly: finding a vulnerability and understanding what happens if someone exploits it.
AI was already great at pattern recognition and correlation. Now, that capability extends to coding agents that not only write code but can find flaws with precision and accuracy. Frontier models are approaching the level of an experienced vulnerability researcher, and in some respects have already gone further, because they can pick software flaws apart one by one. What they are not yet reliably good at is context: understanding when the vulnerability actually gets exploited, how that exploitation escalates into an incident, and might tip into a full-blown crisis. What October 2026 showed us is that AI can mimic a potential kill-chain, i.e. a path from vulnerability to meaningful exploitation, but that doesn’t say much about your true risk exposure. Resilience is not a linear path, and Monica is clear that this is where the real risk sits, not in the discovery step itself.
To make sense of exposure, she uses a layered model built over two decades of enterprise risk leadership across financial services, spanning cyber, IT, project, finance and operational risk. Vulnerabilities sit at the bottom layer. Above that sit the risks associated with them. Neither of those is a full risk scenario on its own. A genuine risk scenario only exists once you add a threat actor, whether that is a criminal, a malicious or careless insider, or a nation state, and trace the path from exploitation through to consequence. Only then can you say what your true business, operational, financial, regulatory and reputational exposure actually is.
You cannot patch your way out of an AI-attack tsunami. That’s why you build resilience. The shit will hit the fan. It has been hitting organisations for a while, even pre-agentic AI. With AI agents, it’s just gotten much faster. Building stronger resilience beforehand is the only thing that counts when a tsunami hits.
As Monica puts it, discovering vulnerabilities is not the moat. The moat is understanding your true exposure and then building the operational resilience to withstand it.
Before any of that mapping can happen, Monica recommends every organisation designate its minimum viable business: the critical operations that absolutely must keep running even in an incident or crisis scenario. In her experience, most organisations have never done this exercise properly, and the gap has nothing to do with AI. If you have not defined what your business cannot afford to lose, you have no way of knowing whether a given vulnerability actually threatens it.
She points to two real incidents from mid-2026 and the tsunami of vulnerabilities that were discovered using AI just in the month of October, as evidence of what happens when resilience has not been tested properly. In July, during an internal cybersecurity evaluation, an OpenAI model exploited a zero-day vulnerability in its own sandbox environment to reach the open internet, then chained stolen credentials with further exploits to gain code execution on Hugging Face’s production servers. The evaluation was deliberately run with reduced safety restrictions, which is an important caveat, but the episode still stands as the clearest public example so far of an AI-driven attack chain running end to end without human direction. Since then, more than 19 cases of OpenAI’s agents attacking other organisations have been publicly documented.
Separately, the UK’s AI Security Institute ran its own cybersecurity evaluations under similarly permissive conditions and found comparable behaviour: an agent, given internet access, researched a real open-source project’s maintainers, created multiple fake online identities, and used them to try to pressure the maintainer into approving a malicious code change disguised as a bug fix. The maintainer spotted it and refused. Monica’s underlying point stands regardless of the exact details: these are not hypothetical scenarios anymore.
Building genuine operational resilience, in her view, rests on defence in depth. If one control fails, the next one needs to hold, and the one after that. That includes practical questions such as how frequently you snapshot any environment an AI agent can touch, and how quickly you can restore from those snapshots if something goes wrong.
Her framework for building that resilience rests on five pillars, and all of them need attention, even if the weighting differs by business. You might be thirty percent mature in one and seventy percent in another depending on what you do, but none of the five can be skipped:
- Data Governance
- Strategy and Leadership
- Culture, Literacy and Reskilling
- Controls and Engineering
- Governance Risk management
For a fuller breakdown of this thinking, Monica has written on governance and control in enterprise agentic AI and on fixing agentic AI security and governance on her own site.
How do you stress-test your codebase and supply chain against exploit-chain attacks?
In short. Know your full AI inventory and every dependency in it. Use short-lived credentials so a compromised account cannot be used to move through your supply chain and pin your dependency versions so nothing gets silently upgraded to a malicious release. Your AI agents have their own identity and permissions. Make sure they are always running with least privileges and permissions, and under the executor’s identity and not the creators.
In depth. Monica is deliberately practical here rather than exhaustive, but she is clear that two controls matter most.
The first is understanding your supply chain dependencies in full. That means having a proper AI inventory: knowing which AI systems you are deploying, which providers they depend on, and where those dependencies sit. Without that inventory, you cannot know what you are exposed to in the first place.
The second is short-lived credentials across every account in that supply chain. Long-lived credentials that get hijacked give an attacker a far easier route through your entire chain, because once they are in, they stay in. Short-lived credentials limit how far a single compromise can travel.
The third is version pinning, and Monica uses a real, striking example to explain why it matters. Attackers have already compromised legitimate AI repositories and replaced trusted packages with malicious versions, deliberately labelling them with an absurdly inflated version number, far beyond anything a real release would use. Automated systems that are not pinned to a specific, verified version see the inflated number, assume it is the latest legitimate release, and pull it in automatically. In one real case Monica references, this kind of attack spread through hundreds of companies in a matter of three hours, because repositories pull dependencies automatically and the damage cascades outward from a single compromised package.
Version pinning closes that gap. It means testing and verifying a clean version of every dependency, recording that version as the default, and preventing anything from auto-updating past it. The investment a cybercriminal needs to make for this kind of attack is minimal, Monica points out, while the potential impact is enormous, precisely because everything in a modern software supply chain is so interconnected. With SolarWinds attack, we already saw how cybercriminals can impact tens of thousands of organisations with attacking one software at one vendor. We are going to see a similar SolarWinds moment for AI, soon.
She is clear there is a longer list of controls beyond these, but inventory, short-lived credentials and version pinning are the ones she would prioritise first.
What stops data leakage when most organisational data isn’t classified?
In short. Classify your data, using AI to help if needed, and build access management around business function even where full classification is not yet in place. Awareness and literacy is key but not enough. You can tell your workforce to not leak data, but you need actual controls that check the data in real-time and prevents data leakage in real-time, e.g. but stopping pasting propriety code into a public version of an AI tool. The critical AI-specific control is that an agent must always inherit the access privileges of the person using it, never the privileges of whoever built it.
In depth. The starting point, Monica says plainly, is classification itself. Organisations often treat this as a huge, slow-moving programme, but AI can meaningfully help. Machine learning is well suited to classifying data at scale, and she recommends using it rather than waiting for a fully manual programme to catch up.
Where classification is incomplete, which is the reality for most organisations, access management becomes the critical control. Even without full classification, access can be structured around business function and sensitivity. A defined set of customers or a defined category of data can carry its own access tier, even if it has not been formally labelled.
The AI-specific principle Monica stresses most strongly is that access management has to extend properly to AI agents, and it has to extend correctly. An agent must always inherit the access privileges of the user operating it in that moment, never the privileges of whoever originally built it. She calls this the non-human identity principle: the agent’s identity and access should always be scoped to the context of whoever is currently using it.
She sets out the failure mode directly, because she has seen it repeatedly in the organisations she has advised. A developer with broad system access builds an AI agent for a general purpose. That same agent then gets deployed more widely, and someone in HR, with far more limited access than the developer, starts using it. If the agent’s access still reflects the developer’s original privileges rather than the HR user’s, the HR user suddenly has access to data they were never supposed to see, simply by asking the agent for it. The access management programme breaks down completely in that moment, not because classification failed, but because the runtime access model was never tied to the actual user.
Her guidance is to treat classification and access management as parallel tracks that need to converge. Classify what you can, build access management around business function in the meantime, and make sure that whatever access model exists is strictly inherited by AI agents based on the current user, not the creator. Do all three together and the risk of leakage drops sharply. Skip any one of them and the whole model is exposed.
Does the EU AI Act automatically apply to UK companies with a European presence?
In short. Applicability comes from what your AI system does and who consumes its output, not from where your company is headquartered. Prohibited uses are already banned. High-risk classification is more complex and phased, with compliance deadlines at the end of this year and in August next year depending on the category. The simplest test is: if anyone in the EU consumes your system’s output, the Act applies to you, regardless of where you or your users are based nationally.
In depth. Monica’s first and firmest point is that the EU AI Act does not apply on an organisational basis. It has nothing to do with where a company is headquartered or where its offices sit. Applicability is determined entirely by the AI system itself and what it does.
Prohibited applications of AI are already in force, having come into enforcement from February 2025. If any of your AI use falls into a prohibited category, that use has to stop, full stop.
High-risk classification is the more complicated area, and it has been affected by the recent Digital Omnibus simplification package, which has deferred the original deadlines. There are two relevant dates, both later than originally planned: 2 December 2027 for standalone high-risk systems under Annex III, and 2 August 2028 for AI embedded in already-regulated products under Annex I. Which date applies depends on the route your system falls under.
Article 6 sets out the two routes into high-risk classification. Article 6(1) covers AI that is a safety component of, or is itself, a product already regulated under existing EU product-safety law, such as machinery, medical devices, toys or lifts. Those systems are listed in Annex I. Article 6(2) covers AI used for a specific purpose in one of eight defined categories set out in Annex III: biometrics, critical infrastructure, education and vocational training, employment and worker management, essential public and private services, law enforcement, migration and border control, and the administration of justice. Recruitment tools and credit or loan scoring both sit within that Annex III list.
The test she considers most useful in practice, and the one she would lead with for most UK businesses, is about output and consumption rather than location. If your AI system’s output is only ever consumed by a department or user base entirely within the UK, EU AI Act obligations do not reach you on that basis. If the output of your system is consumed by anyone in the EU, no matter where your company or your users are based, and regardless of whether that person is an EU citizen, the Act applies to you.
She draws a direct comparison to GDPR to illustrate the principle: you do not have to be an EU citizen or national for GDPR to apply to how your data is handled, you simply have to be in the EU and using the relevant service. The AI Act works the same way. This, she says, is the fastest way for a business to work out where it needs to start paying attention, even though the fuller picture has more nuance once you are actually mapping specific systems against specific annexes.
How are you managing exposure to consolidation among AI vendors?
In short. Do not rely on a single frontier provider. Mix frontier and open-weight models, avoid models from jurisdictions that carry national security concerns where sensitive data is involved, and secure access to a provider’s incident response or trusted-access programme in advance, before you need it in a crisis.
In depth. Monica’s answer here is unambiguous: do not put your business in a position where it depends on one frontier AI model or one vendor. Interoperability across providers is essential, not optional.
In practice, she mixes frontier models with open-weight alternatives across her own work. She uses open-weight models for tasks like voice cloning and voice AI, for example, and pairs a monitoring agent that watches the entire AI environment at application, network and operating system level with a separate, independent traceability agent that logs what a model is “thinking” at each step. The point of keeping that trace independent is that it cannot be manipulated by the model it is observing, even if the model itself hallucinates or behaves unexpectedly. Where data has any national security relevance, she would not recommend using open-weight models from certain countries, though open-weight models from other jurisdictions can be perfectly appropriate.
She illustrates the consolidation risk with the same Hugging Face incident referenced above. Once the intrusion was detected, Hugging Face’s security team tried to use hosted frontier models, including the provider’s own, to help analyse the attack logs and exploit activity. The safety guardrails on those hosted models blocked the analysis, because they could not distinguish a legitimate incident responder from an attacker. Hugging Face had to fall back on an open-weight model running on its own infrastructure to carry out the forensics instead.
The practical lesson Monica draws from this is that businesses should apply, in advance, to any cyber verification or trusted-access programme a frontier lab offers. You do not need to be a cybersecurity company to do this, only a company that wants the option available if a real incident happens. Frontier labs cannot always tell the difference between a legitimate response effort and an attack in the moment, so being pre-verified removes that ambiguity before you actually need it.
Looking further ahead, Monica expects sovereign AI to become an increasingly important part of managing this exposure. She explained what that means in practice: sovereign AI is about having models built and trained on your own soil, not dependent on compute or infrastructure controlled by another country, for example Mistral being built and trained in France as a properly EU-sovereign option. But sovereignty is not only about the model or the compute. It is also about data. When you send data to a provider for training or processing, that provider gains real value from your data even if you retain legal ownership and contractual controls. True sovereignty means not being structurally dependent on a provider that could, in principle, decide to withdraw or change terms and leave your operations unable to function. Monica explores this in more depth in AI sovereignty: from whom? on her own site.
Where are we on the hype cycle for agentic AI?
In short. Generative AI had its hype wave in 2023 and 2024. Agentic AI is having its own version now, fuelled partly by frontier labs’ own marketing. Agentic AI has become strong at coding and, by extension, at tasks adjacent to cyber security, including a full autonomous attack chain, but the industry is measuring capability far more than it is measuring outcomes.
In depth. Monica traces the shape of the current hype cycle directly. 2023 and 2024 were dominated by hype around generative AI in general terms: how capable it was, what it could produce. Agentic AI picked up that baton through 2025 and into now, and the hype has, if anything, intensified.
Part of that is being actively driven by frontier AI labs themselves, in her view. As companies move toward IPOs and compete for attention, real-world examples of agentic capability, including agents reportedly breaking out of sandboxed environments and attacking other companies, have been talked about publicly in ways that read as a demonstration of strength rather than a cautionary tale. Monica sees that framing itself as a signal of how deep the current hype runs.
She is careful to separate genuine capability from proven outcome. Agentic AI has become properly strong at coding, and because of that, it has become great at tasks adjacent to cybersecurity: understanding code well enough to help find vulnerabilities or, in the wrong hands, build malware. But a full exploit chain with a working exploit does require complete knowledge and understanding of the context and risk exposure. Often, the complete path from initial access to actual damage, requires many coordinated steps working together. Although AI agents are capable of vulnerability exploitation, whether that truly works and to what extent depends on your own attack surface. AI in the hands of an Advanced Persistent Threat (APT) or a nation-state is something to manage your risks against. However, should a script-kiddie successfully be able to exploit your organisation, it would point more towards the resilience and attack surface of your own organisation. When an enterprise is a house of cards, bringing it down is much easier, especially with AI.
The most widely cited example of a fully autonomous AI-driven attack, the OpenAI and Hugging Face case referenced earlier, came with a significant caveat that is often left out of the retelling: the evaluation was deliberately run with reduced safety restrictions, precisely to test how far the model’s capability could go. That makes it a genuine demonstration of what agentic AI is capable of under permissive conditions. However, this doesn’t mean that a swarm of AI bots or an army of AI botnet will end humanity. That’s the doomsday narrative one needs to be very cautious of.
“The biggest problem with hype is we are still measuring what it’s able to do, but not the outcome it gives,” Monica says. “We’re not tying that capability to the outcomes. That is where the biggest hype lies.”
Want more from the AI Workforce Council?
Monica is one of ten senior leaders on La Fosse’s AI Workforce Council, all contributing to the Beyond Headcount Blueprint on workforce planning for the AI era. Join the Council live at Beyond Headcount Live on Wednesday 4th November 2026, 6pm at Tower Suites by Blue Orchid, London, for an unrehearsed panel discussion and open Q&A on the Workforce 2027 findings.
Monica Verma is a three-time CISO, independent AI advisor and founder of Monica Talks Cyber, and a member of the AI Workforce Council supporting La Fosse’s Beyond Headcount campaign.