# AI Collapses Security Asymmetry for CTOs

**Podcast:** alphalist.CTO Podcast - For CTOs and Technical Leaders
**Published:** 2026-09-17

## Transcript

Hello friends, this is the Alphalist podcast.
I am your host, Tobi.
The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for their company.
We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast.
Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events.
Just go to alphalist.com to apply.
Welcome to the Alphalist podcast.
I'm your host, Tobi.
And my guest today, it's called Charles Guimé and he's the CTO of Ledger.
And Ledger is the company behind roughly 20% of the world's crypto.
It's a hardware ledger that many of us know.
And Charles got a pretty decent warning about what AI is doing to security, the world of security, and why.
And we're here to talk about that today.
Welcome, Charles.
Thank you for having me.
I'm looking forward to it.
Me too, me too.
And maybe we start a little earlier in your career or actually nerd journey, nerd path.
When did you get into computers?
or breaking them?
And when did that first feel like magic to you?
Sure.
So everything started for me when I was 12.
So finally, I sold my piano to buy a computer.
And the first thing I did was to try to understand how these things work and if it was possible to break them.
When I was a teenager, I did plenty of hacking for fun.
A little bit for profit, but mostly for fun, let's say it.
So plenty of things around cryptography, security in general.
And at the time, that was very easy.
There was no real security field.
So everything was clearly open and it was easy to break.
And I studied computer science, mathematics, and cryptography a long time after.
But everything started when I was 12.
One of the funny hacks I did was at the time you had to pay for the internet and you paid for one hour.
That was 8 francs or 16 francs, depending on the time.
And that was not enough.
My deal with my mother was 200 francs per month.
But unfortunately, in a couple of days...
I consumed everything and I couldn't access to the internet anymore.
So one of my first hacks consisted in hacking my internet service provider in order to have unlimited internet for free.
And how did you do that?
I'm not sure I can say it.
No, I won't say it.
But that was not complicated.
Okay, okay, can imagine.
And you also worked on the hardware side for a while, right?
After that, like, what was that?
Like, give me a few details on that.
I mean, you now obviously work with hardware, but you kind of stumbled into that.
Yeah, definitely.
So as I said, I studied cryptography, security, mathematics, computer science.
And my first internship was in a small startup that was designing like security chips, like electronics basically.
And my internship consisted in evaluating the security of one of the chips.
And after a couple of weeks, I was able to extract the keys from the chip.
And I was so happy to explain this to my internship director, but he was not happy at all because I was simply broke his lifetime work.
So that was fun.
And at the end of the internship, they offered me to stay.
And I was like, I don't know anything about electronics.
You want me to help you securing them?
And they were like, yeah, yeah, you know about security.
You learn fast.
So I was like, okay.
I don't know anything about electronics, but it's a good opportunity to learn.
And this is what I did.
This is where I started in...
the security landscape, but specialized in electronics, in hardware.
And how's the role of hardware security in your current gig?
How does that matter to Ledger?
I guess a lot, but how much weight is on the hardware side versus the software side?
When I joined Ledger in 2017, Ledger was...
only a hardware company, let's say, because the only product was the Legend Nano S.
That was the only product at the time.
It was very successful, but at the end, all the teams were focused on designing the hardware, designing the embedded software, running inside the hardware, and that's it.
But since then, we built plenty of new products, new business units, and so on.
And now hardware is the is still very key in the product offering.
However, we have Ledger Wallet, which is the software that you can interact with when it comes to managing your crypto, send, receive, buy, sell, swap, stake, have a credit card, and everything.
And we are building the software, we are building the backend, we are building the infrastructure as well.
We also have a B2B offering that consists in offering to...
enterprise, traditional finance, a big corporation, a way to manage their crypto securely, but also with some governance.
So basically, it's a SaaS platform that is also leveraging hardware.
We are leveraging HSM on the backend, but also we are providing them with a personalized security device.
But at the end, it's a lot of software.
And to answer your question, so today I would say that...
The hardware revenue is not the biggest one anymore.
Now we have other sources of revenue that are more important.
And in terms of effort, this is the same.
I would say that we have around 20% of the tech organization that is focused on hardware and embedded software, and all the rest is implementing everything software, infrastructure, architecture, security, which is clearly a bigger partner.
And back in the days, it was basically just a USB stick that came with some Firefox extension.
I still own one.
I have some in my basement, I think.
I actually don't know.
Maybe I should check it, right?
Maybe there's something on it.
And that was it, right?
Yeah, that was it.
Only the Nano S.
The form factor was really a memoristic, but that was not a memoristic.
It was implementing a hardware wallet with a screen, with a secure element inside.
Secure element is a dedicated security chip that is inside.
It's the smart card technology, the same technology that you have in your banking cards or in your passport.
But the main difference is that instead of...
managing, securing the secret of the bank or the secret of the government with this kind of device, you can manage your own secret.
It's the big difference.
And back in the days, there was only this device.
And in order to manage it, you could use like a Chrome app.
This technology doesn't exist anymore.
Now this is like Chrome extensions.
But back in the days, there were Chrome apps.
And we had the small Chrome apps in order to manage your Bitcoin because at the time we were only supporting Bitcoin and that was the beginning for Ethereum.
Today we are supporting like hundreds of blockchain, like thousands of tokens, NFT, and you can buy, sell, swap, stake, security, all of this within the same application.
So a lot of things have been built in between.
How do you run security in your org?
Is it like a core...
like on top of everything because you kind of have to produce like super secure devices?
Like how do you make sure that the stuff you produce is actually secure?
Yeah, it's a good one.
So I would say there are three ways to do security at Ledger.
The first one is like corporate security, like the CISO organization that is really in charge of making sure that the corporate assets are secure and so on.
It doesn't seem really related to the product, but at the end, if an attacker would be able to integrate some malicious code in our stack, that would be a nightmare for the product itself.
So it also has an impact on the security of the product.
So you have the SIS organization, you have the developers, because at the end, what we are building is a security product.
So you need to think about the security from scratch.
When you are designing the architecture, you need to think security by design.
You need to think about defense in depth.
What happens if this layer is compromised?
What about the threat model and so on?
And all of this is completely embedded in the development lifecycle.
Last but not least, we have the dungeon.
The dungeon is the security team that I built when I joined in 2017.
And basically, it's a security research team that is really focused on offensive security.
So that means that what they do day-to-day consists in trying to break our products.
So they really try to find vulnerabilities on our product, whether it could be hardware vulnerabilities or cryptographic vulnerabilities, software vulnerabilities, or web-free vulnerabilities.
So this is really the four areas of research that they do.
And in terms of hardware, they have plenty of very high-level equipment in order to implement hardware attacks, like side-channel attacks, laser fault injection attacks, all the very cutting-edge hardware attacks.
And we have the same kind of skills and expertise when it comes to cryptography, software security, and web security.
And at the end, they spend maybe 70, between 70 and 80% of their time trying to break a product and they find new things very often.
What they do is working with the engineering team in order to improve things, mitigate, fix, depending on the vulnerability.
Sometimes I like, oh, maybe the next generation, the architecture should be more like this because it would be more difficult to break it and so on.
And the rest of their time is spent in doing more wide security research on the competition, on every security product that you have in the space, the blockchain space, but not only.
And quite often, they find interesting findings.
And what they do is basically doing coordinated responsible disclosure, meaning that they are reaching out to the vendor, explaining what they found.
And then they agree on a period of time where the vendor has sufficient time to fix the vulnerability.
And at the end, everyone publish what was found and how it was fixed.
And I think it's a very important step for the whole ecosystem in order to make sure that everyone learns from this experience.
And this is really the...
the only way to improve security overall.
This is a standard practice in software for more than 20 years.
In hardware that used to be more opaque and more dark, mostly because vendors don't really want to talk about that.
And it's often the case because vendors cannot upgrade their hardware stack because the hardware is produced one forever.
But most of the time, you can fix or mitigate vulnerability by simply upgrading the software running on the hardware.
So this is also a possibility.
And this is what we are trying to do at Ledger, doing security openly, in a very responsible way, and making sure that everyone...
We raise the bar for security in the whole ecosystem and not only for Ledger.
And a few...
A few months ago, maybe that was in October or November, this new Anthropic thing happened with Opus 4.6, I think.
Because we are using AI for a long time, but since Opus 4.6, we suddenly were able to find vulnerabilities in our product using AI that we didn't find before.
Again, I created this team Almost nine years ago, we have between eight at the beginning and 15 security researchers that are spending all their time trying to find vulnerabilities.
And with AI, all of a sudden, in November, the last generation model, the last frontier model, was able to find vulnerabilities that we didn't find in nine years.
So this is really what is happening now.
the cost of finding vulnerabilities is trending towards zero.
I often say that security is a matter of creating an imbalance, like an asymmetry between attacks and defense.
And you can see this asymmetry from an economic standpoint.
For instance, if you are able to create a system where attackers would need to spend more money to break it than what they could extract from the attack, your system is basically secure because no one will spend like 10 million if they can only extract $10,000 from the attack.
So in this case, your system is secure.
You can also see the same thing from a time standpoint.
Like if you need like 10 years to brute force a password, but at the end, whenever you find the password, the secret that is behind this password is no longer relevant, then your system is secure.
It's not absolutely secure.
It's just secure from a game theory standpoint.
And we used to be in such situation.
Because before, finding vulnerabilities were incredibly costly.
That was costly in terms of skills, expertise.
You needed a very good security researcher that would be able to find those vulnerabilities.
You also needed plenty of time.
And at the end, if the secret, if the attack was not that valuable, most of the attackers didn't do the attacks.
And I would say that most systems were secure just because of this.
Just because you won't spend a month with several security researchers to dump a random e-commerce database that you would sell 10,000 on the darknet.
Economically, it doesn't make sense.
But with AI, this completely changed.
This completely changed because finding vulnerabilities is as easy as prompting, please find the vulnerability on this e-commerce website, and you wait for 10 minutes, and then you have 20 vulnerabilities.
So this is really the state of the situation today.
So the asymmetry that we used to have before is completely collapsing.
And that will be very difficult to re-establish it, just because the counter argument could be, oh, yes, attackers have AI, but also defense has AI.
Yeah, that's true, that's true.
And the defense must use AI in order to be at the same level.
But at the end, you won't recreate an asymmetry.
You will just create a symmetry.
A symmetry between the...
attackers and the defense that are very powerful.
But the thing is, the attacker only has to find one vulnerability and break your system.
And when you are on the defense side, you need to be 100% secure.
So this is really the issue that we have today.
Now, finding vulnerabilities is trending, like the cost of it is trending towards zero in terms of time, required expertise.
and absolute cost like in terms of dollars like you need like 50 dollars to break most of the systems um and on the other side you have defense that needs to spend like far more far more money to make uh the defense uh secure so this is really where we are um in in my specific world which is like the security of blockchain it's a little bit different mostly because um like the The asymmetry that I talked about before is a little bit different because when you can break a blockchain protocol, you can extract hundreds of millions.
So, attackers are used to spend millions in order to try to break our systems just because if they succeed, they can simply steal hundreds of millions.
And this is what they do, by the way.
We have several groups, mostly in North Korea.
that are spending hundreds of millions every year.
And they are net positive because every year they are able to extract several billions.
Like last year, that was more than two billions.
And this year, I don't have the exact numbers, but it's already more than one billion.
So they will probably...
From any attacks, they do not particularly against your systems, but against the whole blockchain and Bitcoin world or what?
Yeah, they are trying to break anything they can, including us.
We see them when they are trying to attack us.
And fortunately, our systems are very secure, and we can see them before they can do anything harmful.
We have defense in depth and so on.
But they also are trying to break on-chain protocol.
They are trying to break exchanges.
Last year, they broke Bybit, and they were simply able to...
to steal $1.4 billion in one hack.
Wow.
It's the biggest hack ever.
So just to say that in my world, we already have attackers with a lot of means, they already spend a lot of money to try to break our systems.
So the asymmetry that I mentioned before wasn't that big before, and a lot of companies, organizations...
already spend a lot in the security of their system because the stakes are high and the attackers are very powerful.
But still, the AI capabilities also change the dynamics in our world.
This is where we are.
So, in my mind, I still think about what to do with 1.4 billion in North Korea.
I wonder what they do with the money now.
But let's talk about software and how AI changes the game.
I mean, you just described that.
Does it really end with, are you really well-equipped if you just run such a prompt against a certain website or your own website?
Is it enough or is there more to it?
What would you recommend?
If I want to secure my app as of today with...
Opus 4.8, because Fable won't do it, right?
With Opus 4.8, how can I break it best?
If you ask Fable very kindly, it will do it.
The guardrails do not work well.
Everyone knows that.
So starting with an adversarial mindset, asking...
Opus or Fable or whatever to find vulnerabilities, secure your system, you must do it.
But agree, it's not enough.
It's definitely not enough.
And for me, the only way to secure system is really to do security by design.
as soon as you are starting to build your system, you are like, what are my assets?
What are the important assets?
What are the access to those assets?
And then you are building your system around this.
You are saying, those assets are very important and I'm going to secure them with encryption, with cryptography, with formal methodology.
It really depends on what your system is doing.
And then you are turning your security problem into a key management problem, which is much easier to do.
So this is what cryptography is.
Again, cryptography turns a security problem into a key management problem.
And all the rest is math.
So math is a high level of guarantees.
So if you want to secure your database, for instance, you might make sure that the access management to the database is very clear and you can observe what is going on, what's happening.
And as soon as something weird is happening, thousands of requests per second, all of a sudden is a weird behavior.
So you need to stop this.
Also, you can use cryptography to encrypt your columns and make sure that the access to the key management goes through this gateway that will enforce the client to decrypt the columns.
So you have plenty of design.
It really depends what you want to secure.
But at the end, it's really about thinking your system from an architecture standpoint through a security lens.
And if you don't do that and you just prompt like crazy, implement these data, implement these features and so on, and at the end you just prompt, please find vulnerabilities, it's something.
But this won't solve the situation problem.
It is a starting point, right?
For Vibe coders at least.
But I think the next level of the CTO job is potentially also really understanding security well, right?
If you look at...
the quality of the code produced by LLMs these days, then I would say it's quite decent.
Sometimes much better than a normal developer would produce.
And then the key question is, can I break the system?
Or becomes, can I break the system?
Well, I mean, potentially, does it scale?
But I would say scaling problems are good problems to have, right?
Like most people don't really have them and security will bite you otherwise at a certain point, right?
Yeah, totally.
And more generally, you remember all those books that you might have read in the past that explains you how to do like a very perfect software development, like starting with an architecture, thinking about the scalability, thinking about the security and so on.
And all of this was very clear from the beginning for every single CTO in the world.
But the problem is, at the end, you always have plenty of constraints.
And the biggest one is time and resources.
And so what we used to do was to spend maybe 95% of our capacity into writing code, just because it takes so much time.
But now...
We have AI, and AI is better than human to write code.
So it's a very good opportunity to do the perfect SDLC life cycle that are in the books and that were never implemented before.
Now we have this time to think about security, to think about architecture, to think about scalability, and avoid to do what we were doing before, meaning just develop something and think as...
the security as an afterthought, exactly as scalability and so on.
Again, now writing code is just a matter of a few prompts and plenty of tokens.
At the end, it's very, very fast.
So now you can, as a CTO, as a developer, as a technologist, you can spend your time into something that's really more valuable, meaning like doing...
high-quality software development with a nice architecture, with great security property, with scalability, with a high level of quality.
Now we can do that.
So the job of a CTO, of a technologist, of a developer is not disappearing.
Some people are fearing losing their job.
No, no, no.
If they think they will continue writing code, yes, they will lose their job.
But if they think that now we have the capacity to write code at scale without any issue, and now we can think as engineers on how to create the most scalable, secure, high-quality system, now this is the job of a CTO, of a technologist, of an architect.
I would also counter a bit and say it is also making sure that the products that you produce actually...
generate value, right?
Which is like thinking about product and the customer first.
Yeah, that was always the case, but I completely agree.
But I think so many people were so bad in this.
And I still think that partly the bottleneck that was created in all of the organizations was also a perfect excuse for people not thinking about how to pivot or where to move.
You were always slow in engineering.
You could always like push, put the blame on engineering basically, while not thinking about how to reinvent yourself and not think about the customer really.
Now this is all gone, right?
Or semi-gone for many organizations.
Still, it is not.
It still is alive or they think it is alive.
But this is like really dramatic from my perspective.
Yeah, totally.
I totally agree with what you said and agree also with...
the specific point where you said that we were using the slowness of developers as an excuse for not doing the hard stuff.
This one can be very true depending on the case.
But I think today the perfect setup for a tech organization, a tech company, let's say, is really to make sure that you can create the conditions where you can ship very fast.
a good product, meaning scalability, quality, security, and so that you can have a very small iteration cycle so that if your product is not very well suited to the client needs, it's not a big issue.
You just have to do another iteration to make it more suitable and then evolve your product as fast as you can.
For me, the future of organization is really about that, making sure that you can shorten the iteration loop as much as you can.
Engineers and developers must create this very small iteration loop with a lot of harness engineering, with all the capacity in terms of security, scalability, quality, and so on.
And then...
As soon as you have this very, very short iteration loop, you can interact with your market, with clients, and get feedback.
And as soon as you see that your product needs to be improved or changed or pivoted or whatever, you can do this iteration loop very, very quickly and adapt very quickly.
And I think in this new world, the companies that are able to implement what I just explained will be the winners.
Because at the end, it's very difficult to think about what will be the market in two years and then enter into a tunnel for one year, then build a product, and then you make it on the market.
And for some reason, it doesn't fit with the market because the market has changed or your analysis was wrong.
this doesn't exist anymore.
Now you can just ship very fast and get feedback and improve in an interactive manner and very fast manner.
And if you were now, I mean, you also mentioned that you're also running SaaS, so this is kind of mostly a software thing with some hardware component in your case.
If you were now the CTO of a small SaaS company and you want to reinvent yourself, or you think you have to reinvent yourself, you want to restructure all of your software development life cycles, what would you do?
What would you use concretely?
And how would you make security a key component?
Would you basically build a harness for yourself and your team?
Would you build skills that ensure that security always sits?
Would you use traditional processes like pull requests, etc., to make sure that the stuff that people ship is secured?
Where would you start?
Yeah, it's a good one.
So I think, first of all, you need to make your team's AI native.
And again, that must not be an afterthought.
The development lifecycle is completely managed by your LLM.
Developers do not develop anymore.
They are doing engineering work.
So that means that you need to have smaller teams.
So I think this is really key.
Having teams or six or 10 or whatever doesn't make sense anymore.
I think you need to have a really smaller team, two, three engineers, one product, and they are completely autonomous.
When it comes to the actual work they do, I think they should spend...
95% of their time doing hardness engineering.
Hardness engineering meaning that create the condition for the agents that will develop the code and develop the product to understand what are your constraints, what you expect from the development, from the code that is produced in terms of scalability, in terms of security, quality, and all of this.
When it comes to security, I...
I would put definitely a gating process in the...
So I'm still for creating the pull request model because I don't think we are ready yet.
Maybe that will change and we will push continuously without looking at anything anymore.
But for now, I feel it's not completely ready.
So you still need this pull request that creates...
like an endpoint where we verify everything semi-automatically or fully automatically by agent, by the way, before pushing to production in order to detect potential supply chain attacks, by the way.
So there was still this point that must be taken into account.
Also, in your skills, definitely you can integrate plenty of security guardrails when it comes to the skills.
But at the end...
All of this is a must-have, but it's not sufficient.
Again, I strongly think that the only way to do real security is by design.
So meaning that you have to think about your architecture, you have to think about your threat model.
What's my threat model?
As a SaaS company, what are the crown jewels of my company?
What could go wrong, basically?
If an attacker could do anything, what could go wrong?
What kind of secret, what kind of asset it could steal?
Think about this.
You can use AI for that, by the way.
AI is a great tool, including for that.
You can connect your cloud to your Slack, to your Jira, to your Confluence, your code, your infrastructure, and try to have a view on all of this and try to infer your threat model for it.
And as soon as you have a clear view of what is your threat model, create an empty file that documents this, read it, read your empty file, and try to figure out if it's correct, if it makes sense from what you had in mind.
Because when you talk about threat model with a CTO, with someone in charge of the technology, The threat model is kind of clear in his mind, but as soon as you ask him to write it down, you understand it's not that clear at the end.
You see what I mean?
You feel it, you understand it in the main lines, but when it comes to formalizing it, it's not that clear.
So taking the time using AI to formalize your threat model, understand what could go wrong, understand.
What are the assets, the secrets that you really don't want to lose?
And as soon as you start with that, then you will understand how your architecture could be better to match with this thread model.
So those are the assets.
I really need to protect them.
So again, I strongly think that the best way to do it is...
to turn the security problem into a key management program.
So use cryptography to secure those assets.
And then you only have a key to manage, and you have plenty of ways to manage keys with the key management system.
It's a solved problem now.
So you can start with that, and then you can easily leverage AI to, again, make sure that you can monitor your system properly or have enough observability and this kind of thing.
Again, AI is really a good solution for that, but you need to spend time with it in order to really understand, formalize your problem, and harden your system.
So plan mode, let's build a threat model for my company.
And concretely staying with that SaaS example, I mean, there are a few things in every SaaS that need to be well protected.
Like, I don't know, your Stripe account, right?
This is where the money flows.
Potentially your AWS root account.
potentially a domain, right?
I mean, this would be dangerous if it disappears.
How would you protect those ultimately?
I mean, you're producing a hardware ledger.
Is it okay to say, hey, put it somewhere in a cold storage?
Put, I don't know, your AWS root password somewhere in a cold storage and only one person has access to it?
Or how would you, as someone who works in that field, actually do that?
Avoid the buzz factor.
So when you say only you have access to it, it's not always a good idea.
For the different examples that you took, most of the time it's about not losing access to a third-party authentication system.
So for this, at least for your Stripe account or...
or whatever, it's good practice to have a passkey implementation if it's available, or at least two-factor authentication.
And we are building these nice devices.
They implement, so it's one of the newer.
Here you have the pin code.
You can use it as a passkey authenticator, meaning that you can log in yourself into your Stripe account just by proving that you own your Fido keys using a ledger hardware device.
This is something possible.
Okay, so you would use one password if you can't afford a hardware device?
Plus a multi-factor authentication with hardware, yes, for this.
Okay, and you mentioned the bus factor, right?
In many companies that I see, there are service accounts for many things, and I don't know, a whole team has access to it.
And yes, there's maybe like a hardware protection, but I mean, how do you avoid being kicked out, right?
If many people have access and you don't know whom to trust, like a zero trust still a thing from your perspective?
Yeah, totally.
Zero trust is a very good pattern and the less the humans have access to system, the better it is.
First of all, because you can't completely trust them.
But secondly, and it's the most important one, like...
If a human has a full access to a system that he doesn't need, that also means that the malware running on his computer has the same access.
And this is the biggest issue.
So zero trust patterns are definitely very good patterns.
If you can implement them, do it.
And how do you avoid that people with insecure...
systems have access?
Is, from your perspective, multi-device management still a thing?
And how do you implement that in a world where many people, especially engineers, are freelancers and then bring their own device?
How do you actually implement Zero Trust?
Or what is a concrete solution, a concrete proposal that you would have?
It really depends on the use case.
So again, as soon as you can do zero-thrus, meaning that the developer, the user, whatever, can access to only what it needs, and it's an automated process that will do the action on its behalf, every time you can do that, it's clearly better.
When it comes to securing the endpoint, it's always a complicated problem.
I'm not the biggest fan of endpoint detection, but at the end, it also gives you a good visibility on what's going on at the endpoint level.
And what we are seeing on the field these days is that more and more attackers go through the developer door trying to compromise.
the endpoint of one developer and then leverage his access to the production and so on.
So in order to avoid that, I strongly think that it's far better to first limit the access required to the developer.
Most of the time, the developer doesn't need to access to every single production node, every single GitHub repository and so on.
So if you do the list...
list access rights to any user of your system, you already limit the blast radius.
If the guy is compromised, only the GitHub account and the production node that he was working on is compromised and not the whole production and everything.
So starting with that is already a good practice.
Secondly, being able to understand what's going on in your production in real time is something that is very valuable.
If you're blind, so maybe you're compromised and you don't even know.
Having a way to rotate your secrets, rotate your access right management system and so on, is also something that is very valuable.
Not always very convenient, but still valuable.
Implementing zero trust patterns, as I mentioned, is a good one.
And when it comes to endpoint...
So again, I'm not a big fan, but still we are detecting plenty of attack attempts using endpoint detection system.
We are also using the signals with different signals that we have on the production.
We are feeding AI in order to understand what's going on.
Because now the problem is when you are observing your infrastructure, your production, you are gathering all the signals from, I don't know, your EGR, Crowdsrike or another.
You end up with a lot of data that is very difficult to understand.
That's right.
AI is very good at this.
So what we have built is definitely a system that gather all the system in real time and try to...
to understand if there was something weird going on.
And then it really removes the noise from the signal that is what is happening on the production real time.
So this is what we have built recently at Leisure.
Yeah, I think using AI for everything, obviously, you're creating context around the different production systems that you have.
even though you maybe don't even have an API, you can use a browser for it as well and automate that.
And then let it review all the dull things that no one is looking at.
I guess you saw the Vercel hack for a while ago, for example, which was super awkward around authentication.
But I mean, who reviews these days?
Connecting an app is super easy.
Almost no company reviews who's using which app in combination with their Google account.
So I guess reviewing Google Workspace, for example, through Claude is a good starting point for many organizations, right?
Yep, totally.
Do you fully trust AI to do the right thing in such systems?
Or how YOLO do you go there?
So it really depends on what you...
Because everything that we just mentioned are things that we couldn't do before just because we didn't have enough people.
We could do the perfect system, monitor everything real-time and so on, but we would need thousands of security engineers.
So we were doing this partially before, only focusing on the important part of the system and so on.
Today with AI, we can cover much more.
So maybe we are missing a few things.
Maybe.
But we are covering much more things that we do, that we did.
And more and more, the systems will be reliable.
And more and more, we can see progress on LLM at doing these tasks.
I still think that doing like agency orchestration is really the...
most efficient way to manage this kind of complex tasks.
But still, if you want to have more guarantees of determinism, you can use AI to build the tools that will do that so that you can review the tool and understand how the determinism and how it works and so on.
So if you don't completely trust the AI system, you can do this.
But this wouldn't be my recommendation, to be honest.
Doing like agentic orchestration where you have like different agents that are managing other agents in order to do more complex things, such as what I just mentioned with like gathering different signals in order to find suspicious activity.
If you want to build this in a deterministic way, even with AI, that will be difficult and you might not cover everything.
If you just do a couple of efficient prompts and you give a feedback loop to your agent system to improve itself, you will build something very efficient to spot suspicious activities.
Not necessarily deterministic, but maybe enough for most organizations out there, right?
Like if you did nothing, then...
But I always tend to say, like, some people say, hey, AI is only producing average results, but sometimes average is better than nothing, right?
To be honest, this argument reminds me at the beginning of...
So I'm playing the old guy.
The beginning of Wikipedia.
I remember I was a big fan of Wikipedia and my parents, for instance, they were like, anyone can write on Wikipedia.
So that means there are plenty of false things.
Yeah, there are a few things that are incorrect on Wikipedia, but most of what is written on Wikipedia is correct, reviewed, and so on.
And I feel a little bit the same with AI.
AI is not perfect yet.
Yes, that's true.
However, it's far better than anything else.
So let's use it.
Absolutely.
Absolutely.
I'm with you.
So, like...
Second last question.
Do you think that the traditional job of the CISO is still a thing or is the CTO basically turning into a kind of a team-shaped profile which combines security engineering and everything, all the old engineering disciplines as well, under one roof?
Today at LeGar, the CIS organization is reporting to the CTO to me.
However, I don't think it's the perfect model.
In an ideal governance, having a CISO organization that is challenging the CISO organization that is completely separated, I think it's better.
And at the end, the CISO organization is implementing most of the stuff that makes the system secure.
However, having another team that is specialized into challenging the city organization, making sure that what good looks like when it comes to security is well-defined and so on, I think it's important to have it separate.
Good.
Thanks a lot.
So I still have a little surprise for you.
It's like a bit of a traditional question I carry with me.
One of your security engineers told me about an Easter egg and your newest product, like the device that you've just shown us.
So you just told how to enter a PIN, right?
Did you ever try to enter a year and then hold all the buttons down three times at the same time?
I guess not.
Maybe you try it afterwards.
And what it does, let's assume it lets us travel back in time and we now enter the year.
2017.
And we observed yourself for a while, how we travel back.
You're getting a little younger.
Not much, but like nine years, right?
And we land in 2017.
And it is basically your very first day at Ledger.
And yeah, you can watch yourself for a little while.
And now you have the chance to whisper something into your younger self's ears.
What would you whisper?
It's a very good one.
And I do remember this time.
And I changed a lot.
I learned a lot.
We accomplished a lot.
My first feeling when I joined was a lot of surprise.
That was really a big, very startup-y atmosphere.
Everyone was running in all directions.
nothing was well structured and so on.
And I think I was a little bit surprised and a little bit worried.
I was like, where did I land?
And I was also excited, equally excited.
And frankly, I wouldn't have imagined that we would accomplish that much in almost nine years.
Because when I joined, it was really small.
really chaotic.
There was no security.
The tech team was very small.
The revenue was only about hardware.
So frankly, I couldn't even wish what happened today at the time.
And so if I knew, if I knew at the time, probably I could have even better ambition.
Because at the end...
When you know that something is possible, you can try to go even further.
And to be honest, I was not that sure that it was possible to go that far for Ledger when I joined.
And we did it.
Obviously, it's the beginning of a journey.
There are still a lot of things to do, but I couldn't imagine at the time.
Thanks for reminding me this time.
Thank you.
Thank you.
Yeah, I think that's also a big lesson for using AI, right?
Think bigger.
I mean, just describe your small problem, but describe the bigger one and try to work backwards from the bigger problem instead of the smaller problem.
That's, from my perspective, a very important lesson for everyone.
Yeah, totally.
If you want to change the world, ask AI, tell AI that you want to change the world.
this way and then start challenging your idea and so on and you can go very far with doing this.
Thank you, Charles.
Great discussion and very helpful insights.
Thanks a lot.
I'm, again, a bit more scared about AI and security.
Let's see what Quantum adds, right?
We can do a full other episode on Quantum if you want.
Yeah, let's see, right?
Like super exciting times and great, great times to be alive.
Yeah, totally.
Thank you for having me.
Have a great day.
Bye.
Bye.
Thank you for listening to the Arthalist podcast.
If you liked this episode, share it with friends.
I'm sure they love it too.
Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available.
Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick.
Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company.
Please send us suggestions to cto at alphalist.com.
Send me a message on LinkedIn or Twitter.
After all, the more knowledge we bring to CTOs, the more growth we see in tech.
Or as we say on Alphalist, accumulated knowledge to accelerate growth.
See you in the next episode.