In this panel, moderators and experts discuss how the rapid acceleration of cyber threats driven by large language models (LLMs) forces financial institutions to rethink traditional cybersecurity. Andrei explains that while classic security practices (extensive testing, audits, and tools like cURL) can still provide a strong baseline, the speed of modern attacks—exemplified by the LightLLM breach and the ability to develop proof‑of‑concept exploits within minutes—outpaces human‑driven incident response. The conversation moves to the need for automated defensive agents, but also the governance challenges they introduce, as such agents can inadvertently destroy data. Speakers highlight the operational impact: a shift from reactive, checklist‑based processes to proactive, agile decision‑making, requiring new skill sets and a focus on quality over headcount. They debate how to balance business continuity with heightened cyber defense, noting that budgets, data criticality, and cross‑functional responsibility (IT, risk, CEOs, boards) shape the trade‑off. The panel then contrasts fintechs—built on cloud, flat structures, and continuous agility—with legacy banks, suggesting incumbents can learn from fintech resilience. Finally, they address vendor strategy, discussing the tension between reliance on hyperscale cloud providers and the push for local solutions, and argue for extending security tools and standards to suppliers while being cautious about over‑reliance on emerging tools like Mythos or Project Glasswing. Throughout, the discussion underscores the urgency of faster patching, automated response, and coordinated governance to survive an AI‑driven cyber crisis.
Chapters
Okay, so we discussed trust, the client with the relationship between the financial institution and the client, the compliance risk, the risk on the reputation. So to move on, how we can make sure that under fire we can still run our business? We need to think about what is the impact on processes, on people, and starting on the damage control approach. Do you see any change compared to the traditional approach? Do we need to change the approach to keep it to an entity?
Yes, I think on one hand there's traditional cybersecurity approaches that Don't stop working. There has been a lot of headlines about security vulnerability being found everywhere by Mythos. However, there also has been an attempt to use Mythos to scan for vulnerability in a common tool called cURL. Mythos was able to find zero vulnerabilities. It's because the developer of this tool put in place classical cybersecurity means where they had extensive testing, they had security audits, they were running other security reviews with older models. And if you're following those best practices thoroughly, there's good chances that you are still way too hard of a nut to crack for those new offensively tuned tools. So if you have good classical cybersecurity practices, you are already in a good position. However, no defense is perfect. Eventually, as the tools get better and attackers get more insistent, something is going to happen. Somebody is going to get on your network, acquire administrative privileges, and you need to be ready for it. The speed of lateral movement of attacker once they're in, impossible to control with classical tools. There has been a fairly recent compromise about months and a half ago of a tool called LightLLM, where LLM-based security scanner that they were running on their repository was compromised, stole their secrets, and in only about 30 minutes, a version of tool with a payload has been posted and pushed into production, and then 17 minutes later updated. Historically, we would have expected this transition to take a couple of days at best. Now we are talking 15 minutes. The same thing is happening when there's a patch coming out. We now can reverse engineer using LLMs vast majority of the attacks for which the patch is coming out and create a proof of concept exploit for about 75% of them in under an hour, 90% of them in under 24 hours. This means that if you previously had this practice of waiting a little bit to patch to make sure it doesn't break anything in your company, it is no longer viable. And human-driven incident response, it's no longer fast. You need something that catches the intrusion and stops it or starts separating your network In the minutes that follow the initial intrusion. We are moving to velocities that are too high for human and that probably will be taken by agents. But then we run into a problem that agents that you have deployed for defense are just as capable of destroying your data, destroying your network, and deleting everything that has already happened on several incidents. So there's a need to start working on the governance and limitations of capabilities of those defensive agents in your network right now.
The key point is the velocity, definitely to be quicker, and that will have definitely an impact on the operation.
What are actually the key impacts we can see with this new Well, building on what Andrei just described, so the first thing is really processes. There is a shift from being reactive, and it's about focusing more on preventative measures. The technical tools that Andrei just discussed, but also everything that becomes more decision-making needs to be split from the automated solutions to respond as the attack is happening. This shapes operations, and I take a page from the book of military strategy. What do you do if your opponent no longer follows the rules of engagement? Well, you need to adapt your strategy. So if it's a guerrilla type of warfare. You cannot deploy your battalion and count on numbers anymore. It's about being more agile. There's a lot of training that goes into that. It's not something that can be improvised. You cannot wait for an incident to happen and then trying to work out what to do next. It's something that needs to be prepared upfront. And as far as financial services are concerned, I think historically operations have been more hands-oriented as opposed to being brains-oriented, people waiting for instructions coming from the top or following through checklists. Well, That would not work in nowadays' environment. There has to be an adaptation to that. That it has an impact on headcount. So it's no longer numbers, but it's about quality with a skillset that is not the one of the past, is the one of the present, and is the one of the future. And empowerment follows through because there is no time to wait for instruction. There is no time to wait for analysis the traditional way. So processes, operations, and headcount need to be adapted. Again, it's not about the number. It's not about the headcount per se, but the type of skillset that needs to be ready.
Interesting. So we need more qualified people. We need a process that can be adapted with the new pace we see, we have a lot of changes and we may have more action to protect for cyberattacks. But on the other side, we need as well to continue the business. So we need to find the best trade-off. How can we define the right trade-off here between business continuity and cyber defense?
Yeah, I concur with Daniela. I think she raised a lot of good initiatives and the balance is definitely very hard. I think we need to consider the budgets that the companies have and the critical data and systems. I think there is no one solution fits all. As to how much we reinforce the cyber defense needs to be looked into the, the criticality of stopping of business, delaying the services, having no access to the most essential data, whether the critical fund— in the past, I've been involved with many data leakage incidents, and the main challenge was about where is the data and what data has been accessed. And I wonder now if the AI tools, we will be able to find that faster and easier, but I'm not so sure. If your house is not in order, if the foundation and the cellar is a mess, then it will also be difficult to think, oh, we're protected. And then if one's entered, they might take out random data and it's going to be very hard to assess what is the impact and how bad is the attack. To go back on the decision, I think it's important for the company to understand it's not one team responsibility. It's all across the business, IT, risk officers, but also the CEO needs to understand the main risk and the board needs to be aware what can happen. And Daniela, you also mentioned crisis management. You cannot just find, find a way out if you have no practice. We can also use the new technology to learn better how to deal with the incidents.
Going back, Daniela, so we discussed earlier that fintech can take what's happening at a growth threat and opportunity due to the ability to adapt quicker than traditional institutions.
So if we think how fintechs were designed from scratch, and some of them now have over 10 years of history, so they built on the cloud while everyone else was operating on-premise. And they had from the start this challenge of being, first of all, more exposed to vulnerability and having as well to guarantee uptime of 99.999%. They built their infrastructure with redundancy built in, but also they built their organization in a very agile way. So generally very flat organizations where the lines between operational and IT capabilities were quite blurred. So crossbreeding of expertise required in all teams, at all levels, in all functions. And that empowered them to have a degree of resilience that was definitely different than the traditional players where there are probably stronger and thicker silos and walls between the IT and the operational departments. And oftentimes that's what slows down the response in cases of an incident. And I think this is where experience and expertise can be shared. I do believe that traditional institutions can learn a lot by looking at the experience of the fintechs. The traditional players have undergone several waves of digital transformation, but I think more can be done in that direction. And I think that's probably the best way to respond to these types of threats going forward.
Makes sense. Another topic to discuss today about vendor strategy and also high dependency at this stage on the hyperscale companies. So there is really a big trend currently in Europe, in Switzerland, to get less dependent, to try to have more local cloud solutions. But on the other side, with Project Lastwing, where this company trained their solution based on the models and having an advantage of all the work on the project. Do you think that people that are already working together with this Microsoft, Google, whatever solution should extend the relationship just to have in short term A better protection, or it's not the case?
So there's 2 questions. The first question is, if you have tools to improve the reliability, security in this very fast-changing landscape, should you extend it to your near field, your suppliers notably, people with whom you partner for distribution of your services? And the answer is absolutely yes. From the point of view of the end user, they don't really care who got compromised, but if there's your name of one of the products they were using, it's your reputation that's going to get affected. Even if it's your supplier that did it. So you absolutely need to think, consider extending those tools, requiring things from your suppliers, training your suppliers before there's standards to which you can require compliance that are ready for the AI safety and security. Now there's a second question of Project Glasswing specifically. As I mentioned, you don't need Mythos. Mythos is not outstanding. It's a little bit more handy. It's a little bit faster for beginner users. But as CURL project have showed, as independent companies that found bugs in the systems Mythos claimed to analyze that Mythos didn't find. We do not need this kind of tools in Europe. We have competences and we have people working on those topics already. What we need to do is to cultivate those systems, especially when we are denied access early on, because there's a head start of now almost 2-3 months compared to Mythos, that in the meantime other companies could have closed the gap and help you to start patching. And the problem is not finding vulnerabilities. We have been doing it really well before the LLMs arrived. The problem is patching it on time. And from this perspective, Starting putting in place good practices, starting testing with maybe models that are not as well known, maybe with companies that are local that specialize in coordinating the models in the right way, is much more gainful than wait for this magic tool that will automatically find everything and patch it, because that's not how security works. So, but yes, absolutely extend it to the near field, but also don't wait for the big and shiny thing to appear, and you starting earlier is better than waiting.
