S2E4: The Startup Security Playbook: AI That Keeps Up with AI — with Francesco Piccoli (Almanax).

If you have like critical infrastructure that is being targeted by enemies, whether these are state-sponsored like groups or directly countries coming at you, you want to start putting more resources into protecting your critical infrastructure. And so like, you look at some of the priorities that the DOD, the Department of Defense, has, one of their top priorities is like cybersecurity. Because a lot of wars will be fought in cyberspace too. So it's, uh, very, very topical now, I guess.

Welcome to Startups Decoded, the show that gets real about what it takes to build a successful startup. I'm Andy Walsh, 2x exited founder, strategist, and your host. Each week I talk with top founders, investors, and operators to unpack the plays that drive real traction, not just headlines. If you're building something bold, this is where you'll get the honest insights to scale with clarity and confidence. Confidence. Let's keep growing together. Hit subscribe and share with your community. It would mean the world to me. Hello and welcome back to Startups Decoded. In the age of AI, we're exploring what that means for security, where vibe coding has become a trend. Anyone can start doing prompt engineering and build a product, but what does that mean behind the scenes? And to help unpack that, I've got Francesco Piccolo. Welcome to the show.

Thanks for having me, Andy Walsh.

I'm really fascinated by this topic, and we were chatting before that when you talk about security on platforms, it's not something that people would probably all of a sudden open up conversations and want to talk to you for hours. But if they were to step back and look at history, as far as the people that have the ability to gain access are generally a step ahead of the curve, right? In the sense of technology, how they access it, how they use it. And when you put technology in the hands of people that don't and they take things for granted, it opens up a lot of risk. Today, what we're going to do is look a little bit at Almanax, your company where you're founder of, but also go through the right things that people should consider. So I'd love to hear from you about Almanax and what you're focusing on with your business.

Yeah. Um, We at Almanac, we're building an AI security engineer with the vision of extinguishing software exploits. We started around a year and a half ago coming from a cybersecurity background, both me and my co-founder. And we saw like big gaps in the way that security was done in both like the Web3 space, but more like more broadly in like traditional software. And at the same time, LLMs were starting to become relatively good and promising at security tasks, which led us like to start Almanax. Our initial focus has been on code security. We use LLMs and AI agents to identify security vulnerabilities in a company codebase. So a lot of the focus is on detection and patching of these vulnerabilities. But it turns out that once you build good detection mechanism, that have good detection rate and low false positive rate. You can also help in other aspects of security, such as like triaging. One of the things that security teams spend a lot of time on is receiving a bunch of alerts and going manually through those alerts and try to identify what is relevant for them and what is not. And so really like the, the vision is to build this AI security engineer that could help in a lot of the tasks that a security team does.

And it feels so critical, and I love that there's so much innovation happening now at scale where people are able to create something that is a simple idea or something elaborate, but do it quite quickly. But that also means that they need to be organized and structured with what they're doing. But there's also a lot of trust that goes into the platform that they're using to build. So we'll unpack all of that today, but To give people a little bit of a history to yourself, I always love to understand where you started out and what led you to the security space.

Yeah, I'll go on a quick background run here. I grew up in Italy, in the Italian countryside, where really like the only tech innovation you were seeing was like in agriculture. Not much was going on really, northern Italian countryside. I didn't even know what startups were really, like growing up, never heard of that term. And I did my undergrad in aerospace engineering in between Turin and Madrid, Spain, and really grew fascinated about Silicon Valley and the idea that most of the large tech internet companies that really had written the history of like the internet were born in that area and like grew in that area, right? So I really wanted to immerse myself in that ecosystem, which led me to do my grad school in the Bay Area at Berkeley. And while I was there, I was doing research in AI and machine learning, working with like a few startups on research initiatives. Tried to start my own startup, which wasn't that successful. It started as like a research project in university and then didn't go as planned, but it was a good lesson learned. And after that, I joined a startup in the Bay Area called Onchain.ai, originally as a data scientist. And, you know, it was very young when I joined. I think we were like 6 people at the time, and we grew pretty quickly. I became the head of product, and I was there for roughly 4 years. And we specialize in investigating crypto hacks. So we really develop like product for like law enforcement and companies that were being hacked to help them investigate these hacks, follow the money, and really like create cases that they could bring in court. And was there for years, saw a lot of these gaps that I was talking, telling you about in the security space, which led me to then like start Almanax around a year and a half ago.

And it's quite often the things that we observe in roles in other corporations or in market as a consumer and having that front row insight to what you're doing is important to the challenge. And if you look back historically at crypto, I don't know timeline-wise when crypto first happened, but it's one of the main products that is using blockchain to its full potential and the ability then to be able to get under the hood of blockchain and see how do you build on blockchain, how do you operate a secure company on blockchain, allows you to get ahead of the pack. And in the sense of what Almanax is doing now, what would you say that is the connection there that allowed you to go, technology's changing, how do we build a product that can help founders think confidently about what they're doing in market and not feel concerned about any breaches and anything that happens, particularly on third-party platforms too?

Yeah, so while I was there, I got to investigate many like large hacks. One of our clients got hacked for $100 million while I was there. And as we were, as I was diving deep into like the dynamics of these hacks, I really grew frustrated about them. We were having hacks every single week, sometimes every single day, multimillion-dollar hacks. And I couldn't believe that it kept happening for like sometimes like the same reasons. So I started looking into how these companies were doing security, because obviously once you go and investigate a hack, you're after the fact, you're doing like post-incident work, which is very valuable. But what if you could prevent a lot of this stuff from happening in the first place, which is where obviously security comes in, right? And there were mainly two ways that companies were doing security, sometimes combined, sometimes only one of the two, sometimes none of the two. But the first way is, and this is generally for like more mature companies that had budgets and processes in place, they were using security tools that were automated for static analysis or dynamic analysis to identify vulnerabilities. Right. And generally, these were like 10, 15-year-old, like legacy softwares that were having very bad detection rate and were spitting out a bunch of alerts that really like no one was looking at. Some of the companies I talked to had, you know, more than 100, like more than 100 alerts like a day. When there's too many alerts is no alert at all, right? And then the second way that companies were doing security was like through like manual security reviews, where they would outsource security to a third-party vendor, where there was penetration testers or like auditors, where you would be in negotiations on the scope of the review and the price of the review for like weeks. So it would take like a lot of time to even like get started. And then you would do it like probably every 6 to 12 months because they're generally like pretty expensive like engagements. And it was a bunch of like sending PDFs and zip files like back and forth. And so like very manual, like very not efficient. And again, if you're doing it every 6 to 12 months and you keep shipping code in between, like What happens in between, right? Like you're not really doing security there. And at the same time, we saw LLMs becoming pretty good at like code generation. They were starting to show promise in that domain. And we tried them on kind of like in security applications and they seem to be doing like pretty good. So we were in that moment in history where like these old technologies were spitting out a bunch of alerts or were very ineffective and people were growing, growing frustrated of like manual reviews and a new piece of technology was kind of like getting very good at doing some of this work. And that, that's what led eventually to start Helm X.

I remember, and I'm going to age myself a little bit here, but in the days of early Windows on Microsoft, and all the pop-ups and notifications of any kind of virus or access, etc. And it was just consistent all the time. And, and we all would have had some form of like Norton antivirus or something that was, you know, meant to protect us. But I'm always dubious on that. And it's, it's like a vaccination in a way. There's some things that will last the test of time, but it's almost impossible to keep up with things as they evolve. And With that, how does that tension play with you're using LLMs as a tool to be able to be more proactive in what you're doing to identify things before they happen? But if you've got someone else who's developing in AI to be able to hack and get access, like who stays in front in that battle? Or is that a constant thing that you have to do every day?

You're spot on on that. They say that security is always like a cat and mouse game where generally the bad actors move a little faster than the good actors, and you're always trying to respond to threats. And we're already seeing some of it. North Korea, obviously they're involved in a lot of the hacks that we've seen in the past, and they're already using LLMs to create novel attack vector to create novel attack strategies to hyper-personalize to a company, to a person, some of their attacks and really like deploy them at scale. And so there's a lot of malware that we found in open source packages that were used by many companies out there and they kind of like, you can see some of the fingerprints from North Korea, but it's, it's eventually, it's always like an cat and mouse game. The good thing is that we are seeing security teams like understanding the problem and opening their eyes to it. Like AI enterprise adoption of AI is much faster than what we've seen for the cloud, for example, because like people are seeing results almost immediately. And so there's, we're seeing much more interest from security teams and like the adoption is starting to be like relatively fast. But some of the challenges that they face, obviously, is that today, you know, Cursor changed the way that engineering teams write code. And this, and security teams now need to secure 10x the number of lines of code than they used to just a few years ago, really. Great engineers I work with use like Cursor or another AI coding assistant tools to ship code much faster. And so security teams are not growing, but they're now getting a lot more alerts from like these legacy security tools and they're, they're finding themselves needing to secure these next lines of code than they used to, right? So there's also research that we were looking at when we started Almanacs that shows that a lot of the bugs that are, and vulnerabilities that are out there in the wild can't really be found with automated tools. Some researchers describe them as like machine unauditable, which means that like these legacy tools can't really find them. Because the way they generally work is they have manually written rules and manually written detectors that go and look for specific type of vulnerabilities, right? Generally, they, you know, there's databases of past vulnerabilities that people have found and reported. And like some of these tools are based off of those like databases, right? And obviously, they generally miss a lot of like the complex logic bugs. You would have to write rules for every possible scenario. And it's kind of like, it's kind of unfeasible. And you have LLMs at the same time that are, can now sort of like understand the codebase, like quote unquote understand, and are able to navigate the codebase, navigate the documentation. Navigate like the internet, look at past hacks, and are starting to find like these machine-inauditable bugs that we thought were like, were only findable like through manual reviews. And it turns out that 80%, right, of these like all the bugs out there are like, were supposed to be like machine-inauditable, but we're now starting to find them, which is very promising.

It makes sense. So if I was to give an analogy, if you were the old version you would go into a store and you can only select a certain number of candy bars. There could be a new one that's just come out and you would not see it because you're not trained to do that. Whereas the new LLMs, dynamically learning, and the more exposure they get, then they can start to anticipate a little bit too, right? And they're connecting the dots with different combinations in a way that we wouldn't be able to do. So it makes sense that those two things go hand in hand. And I guess to build on that, I'd love to look at responsibility. I touched on it at the start of the episode as far as if I'm building on a platform, say I'm using Lovable and I'm developing code and I'm doing all these things myself, like they obviously have their own system of management and protection and security, but then I'm creating a consumer or B2B facing platform using their technology. Whether that's the right example or not, but if I'm using someone else to be able to host and manage my product, where does the burden lie? I don't know if you know that from a legal perspective, but who needs to trust who in that dynamic as far as customers on the startup and then the startup on the platform?

I'm no legal expert, right? So I'm not going to give legal advice on this podcast, but there's a combination of things, right? Obviously, It depends on the type of product you're developing. You know, if you're developing a DeFi product that millions of customers are putting money in, and it's sort of like there's immutable code once you've written it, and if you get hacked or, you know, if that code is exploited, money is directly stolen, you want to have a higher level of security for your application. You want to do much more testing before you go and ship this piece of code. 'Cause obviously this is like one of the big differences in Web2 versus like Web3 hacks. If I hack Meta, I steal customer information or like I take down some servers and, you know, I can ask for a ransom payment. If I take down Uniswap or another like Web3 protocol, I have direct access to money and I can move that money wherever I want to like obfuscate it, and try to liquidate it. And so it's, if you're building that type of product, like obviously you should probably have a little bit more like spending in security. I'm not gonna touch on the responsibility side, right? But I do think that as the founder of a company, you're kind of responsible obviously for, especially if you're dealing with customers' money, you're responsible for like making sure that your platform, your infrastructure is secure. And so you want to have obviously like not just tooling. It's not that if you have like the right security tools, all of your problems are solved in the same way that it's not, it's not that if you're doing your audits or if you're outsourcing penetration testing and you're doing a bunch of it, all your security like problems are solved. There's processes that you want to put in place as well internally at your company from like access control, like privileges, like of, um, and the principle of like least, sorry, like the right word is not coming to mind, but it's a principle of like least privilege access. And so it's, it's a serious step that you need to take to make sure that your customers are dealing with secure code bases and you've done all your best to actually make sure that no one is stealing money, no one is losing money, or like your customer information are like protected. And so this also like plays out in the B2B space, right? Often when you're working with large enterprises, they have you fill out like full questionnaires on how to like, how you as a vendor are like doing your own security, right? To make sure that they have, probably there's a bunch of like legal frameworks, right? That they need to comply with to make sure that They have their certifications and their processes in place. But long story short to say, there's, you know, no tool is going to cover you all. Vendor, outside vendor is going to cover you all, which is why like companies, when they establish a brand and they start growing, they have their security teams that puts in place like best practices internally, right, for all the employees. Because obviously social engineering is like one of the biggest sources of hacks. We've seen a lot in the past, people clicking the wrong links and downloading the wrong stuff and outside bad actors like getting access to things they shouldn't have access to. So humans are still like a weak, if not the weakest, kind of like link in the chain. So like it's a combination of things to go back to your question.

Within that, and I can speak to Microsoft, I had them as a client for a long time and I will never forget the onboarding process and forms for compliance around things like data management and privacy and where things are stored. Etc. And for obvious reasons, in the sense of all the detail that you need to go into when they were working with us for a period of time there. And within the, I guess from a legal standpoint, and not to double down on it too much, but ultimately you should understand your business and get the right legal advice as far as where the burden lives. And if you're capturing people's data, if you're capturing people's credit card information, if you're holding money, there's a lot of things there that you really should understand. What are some of the big things that you would call out? I've called out 3 there. Are there others that I'm missing that if you're a founder and you're managing certain things within your platform, what areas should you make sure that you've got external advice on?

It's a few, right? But you touched a good amount. We have seen, like some of our customers use this to be compliant with, you know, SOC 2 or ISO and other certifications. If they needed to make sure whether it was like them being in healthcare or like in crypto or like fintech, they needed to make sure that no PII was passed in plain sight and bad actors couldn't get access to customer information. Obviously, again, I tend to put a little bit more emphasis and suggest people putting more emphasis on financial applications, especially if there's code living at the protocol level, because a hack is just like catastrophic, like money stolen. There's generally like very little insurance behind it. So if you're JP Morgan, you get hacked, if you're a customer of JP Morgan and JP Morgan gets hacked, you're probably going to see all your money back through all the insurance protection they have in place. And you're going to see it like back like relatively soon. And the same is not true in Web3, for example. And so if you have money in a protocol, in a DeFi protocol, and they get hacked, that money could stay in the hacker's hand for like years. That happened with like the Bitfinex Bitfinex hack, uh, where, yeah, like that was like a good example actually. Customers got some of their money back, but the hackers held on the money that they stole and the price of Bitcoin like skyrocketed in the meantime. So like the customer like lost all that upside. But what are other things that I would suggest doing? Um, I mean like the classic like hardware security, having YubiKeys, having and making sure that you give access to people. Only if they need access to that specific thing and that you're not just, you're not just like granting access to everybody in the company to your like cloud infrastructure. These are some of the common like best practices, but one of the things that obviously we focus on at Almanex and I would recommend everybody like having some sort of tooling to do this is making sure that every time you're pushing new code, you're not introducing new vulnerabilities in your existing product. And again, like traditional security tooling is falling behind on this in terms of both like detection rates and false positive rates. And so if you're not, you should be using some sort of LLM-based product today to look at code every time you push it.

Are there specialist insurance brokers who would assess that level of risk and with my own company historically, like you obviously have some foundational insurance, but errors and omissions is one that's quite important and also quite expensive for founders to get as well. Are there, I'd assume, yeah, insurance agents that can help guide you through some of that understanding, or is it a combination of insurance brokers and attorneys to be able to make sure that you are covered from a legal standpoint, insurance standpoint?

There's, it depends on, on the industry. Generally there's insurance brokers and insurance providers that would cover certain things if an exploit were to happen. But even for them, often they don't offer like the full range of products, especially for certain industry like crypto, because they have a hard time assessing the risk of a particular like code base or of a particular protocol in the case of crypto. They struggle, you know, one of the things they look at, I was talking actually to some insurance providers in the past few months and they were having like, these were like they were legacy insurance companies that wanted to extend coverage to, they, they wanted to start offering crypto products, basically insurance to companies building in crypto. And they had a hard time because they could not really assess the, the cyber risk of a particular protocol because these companies, the security posture of the industry was like less mature than traditional software. And at the same time, they were giving them, like these companies that wanted the insurance, they were giving them like these PDFs with like an assessment that was done a year ago. And I mean, in the meantime, like code was pushed, right? And that code wasn't really being looked at by anyone. So we started actually like conversations with other insurance providers to help them assess the the risks on like the cyber side for companies and having them like look at code. And it's interesting because like generally these insurance companies will have like set checklists where they would give you a higher risk if you're not doing X, Y, and Z, right? They would give you like a lower risk if you're doing that X, Y, and Z. Again, depending on the industry, right? But for crypto, for example, like, there's some insurance companies, but it's been, there's been like a barrier to entry for them.

It makes sense. And I'm sure that most people would be familiar with when Mark Zuckerberg was in front of an inquiry from a government body. It was, but all of it was quite public on the news except and just the lines of questions and terms that the people were using, and they're all over 60, some of them in their 70s, trying to ask Mark certain questions about data and data privacy, except, and they didn't even understand what they were talking about to even ask the right questions. So from an insurance point of view, to your point, a lot of these industries and businesses have been around for a long, long time and being able to keep up with levels of risk. It feels like it's, I don't know if it's impossible, but you have to get to a certain point, put a line in the sand, make that your policy, and then keep staying in front of that. So I'd assume that's going to be a hugely evolving industry in the sense of assessment of digital risk and that threat that comes off the back of LLMs.

I agree. Both insurance providers and governments are looking at it. If you have like critical infrastructure that is being targeted by enemies, whether these are state-sponsored like groups or like directly countries coming at you, you want to start putting more resources into protecting your critical infrastructure. And so like, if you look at some of the priorities that the DOD, the Department of Defense has, one of their top priorities is like cybersecurity. 'cause a lot of the wars will be fought in cyberspace too. So it's very, very topical now, I guess. I don't know if you saw that there was a hack, a group targeted an exchange, crypto exchange in this case, like a few weeks ago. And they hacked them for, I don't remember if it was like $80 or $90 million. And they didn't even steal the money, they burned the money, just as a sign of almost F you, right? So it's, again, some of these wars will be fought in cyberspace.

And trying to stay ahead is something that you have to keep doing. And I think at a global scale like that, it seems that the risk is significant. Pointing it back down to a founder perspective on a day-to-day, I'm still really curious around the process itself and how you stay out in front And if you're a founder and you want to make sure that you're compliant, that you're reducing your risk, but you also don't want it to interrupt your day. And you talked before around examples that you'd seen where people are getting hundreds of notifications. How do you overcome that where sometimes there's things that happen and is it category of risks? So if it's a low-risk thing that it's proactively identified, it repairs it and doesn't tell you. How do you reduce that noise? Around the old model of security when it comes to software?

Yeah, it's a great question, right? And it's been one of the main focus areas for us. Every security team we talked to, and when we were asking them what their biggest pain point was, was like noise, noise, noise. We receive, we have like a bunch of tools that we turned on, like integrated. and we're literally receiving like hundreds, sometimes like thousands of alerts a day. And I need, we need to go and look at these alerts because there could be something in there, but it's, it's a lot of noise. These, we talked about like why before, right? It's like these legacy tools are looking at everything from like these large databases that could impact the company and say, hey, I found this, I found this, I found this other, but not really looking at that in the context of the codebase. 'cause they couldn't really, like, until LLMs were a thing, you couldn't really, like, have a, like, product, quote unquote, understand that context. And so a lot of the focus for us when we started building our product was in making sure that not only we could improve detection, so we wanted to find as many bugs as possible, but we wanted to decrease false positives. And so we wanted to give you, like, as little alerts as possible. So we've done a lot of benchmarking. Of traditional tooling with our product and the models that we developed. And again, like detection rate and false positive rates are like two main metrics that you want to look at when you look at security tooling. And I'll give you like an example, right, of like how you, like what these two metrics like mean in practice. So for example, imagine you have an application with a software application with 100 bugs and vulnerabilities. You have tool A and tool B. Tool A is like a traditional legacy tool that would scan that application and could find you like 220 alerts or 230 alerts, right? Out of these 230, 10 are good alerts. So they're actually true vulnerabilities in that pool of 100 that there are in the software application. And so you have like a 10% detection rate and the remaining 220 are noise. And this is just like pure noise. And so like, yes, you found those like 10, but then you have like 220 that are just pure noise. Tool B, like the LLM-based one, you might get 70 alerts, 50 of which, 5-0, are good alerts. So like, you have 50% detection rate out of those 100 that were out there. So you still don't find everything, right? It's very hard. Like, there's no tool today that can find everything. There's no human that can find everything. That's why you get like multiple screens, right? And multiple like layers of protection. And so like you have these 50 out of the 70 that were good, and then you have like a 20 that are like our noise. So there's still like significant, like 20 out of 70 alerts that might be noise, but it's much, much better. It's like 90% reduction compared to like the 220 that you had before. So that's sort of like the type of performance improvements that we're seeing with LLMs. Again, it's one layer layer of protection in your entire stack, in your entire security stack, right? But it's a much better layer than like the traditional tooling.

And I would imagine that it's something that you need a person to trust as far as who's going to do it and who can manage that. So in the process for you with Almanacs, from an onboarding perspective, What sort of things do you audit to be able to put in place a solution that works for the customer?

We do a lot of benchmarking, especially early on. Security people are generally like no bullshit type people. So if you tell them, oh, I have like this magic tool that can find a lot of stuff and give you like zero alerts or very low noise, they will look at you like, yeah, sure. Thank you. I obviously believe you. And so like, they're generally show me, don't tell me. Kind of people. And so a lot of the work that we did at the beginning was like creating benchmark datasets where we would test our product against and like publish the results to show them, hey, this is how the legacy tool performs and this is how our tool is performing and it's improving over time. That's kind of like where we started and it was nice to see some of the reactions. From people because they, you know, obviously we built some of these datasets. Some of the others like were existing datasets that other others in the AI or machine learning community or generally more broadly like the cybersecurity community put together. So it was, it wasn't just like us coming up with our own datasets and bringing our own bells, right? And these were some benchmarks that others had created as well. But it was nice to see the reactions from people. We literally had one security guy coming in and starting to try the product. And he reached out after and he was like, look, I expected this to be pure trash. I expected it to be terrible. And I came in and I was like, wow, this is much better than any security tool that I've used for these tasks before. And so he was very impressed and ended up like converting and becoming a customer. So those were the type of reactions that we really liked. And again, zero bullshit, very skeptical people, the security community, but many of them are starting to wake up and see that these can actually like improve a lot of like their day-to-day, whether it's the detection part or analyzing alerts from other tools and having almost like a sort of like first pass for like triaging. If you're getting a bunch of vulnerabilities, you want to take like first, you want to like look at them. Understand whether they're relevant or not, and then like take action. If you can shorten that cycle, not only improving detection, but if you can shorten the cycle review of like these vulnerabilities and these alerts and do like a first pass with LLMs that tells you, hey, yes, this you should definitely solve it. This other, it's a false positive because of X, Y, and Z. And then also have the additional step of automating like the patching, that saves a lot of time in the security process.

I guess if you don't have a security person on your team and you're a young business, you might have 10 employees, you're trying to make sure that you do the right thing. To plug this in, as in Almanacs, across the board, how much skill do you need to have as a, as a founder or operator to be able to implement it, run it, and then deal with anything that does happen?

Almost zero. You could, if you have a website, you could go and plug this in, in the next like 5 minutes with a few clicks. We built it, uh, it's like we built it in a way when we started and as we keep developing the product, we built the product so that it was like very easy for anybody to go and use it. Obviously, our main targets are security teams. But as you said, if you're like a smaller company, you probably don't have a security person, and your engineering team does the security part as well. And so we wanted these with like two things in mind when we like were thinking about like the user experience. On one end, we wanted these to plug in into existing development processes as nicely and easy as possible. And so the product we built as an integration with GitHub, which most developers use, where it's like a GitHub app that you install on your repository. And every time you're opening a new PR, or you're pushing new code, we automatically scan. And so you see the results directly kind of like in GitHub. So it's like a tool you're already using, you're already familiar with, you're not learning really like a new tool. And then obviously if you want to go and see like a more detailed report or you want to go like launch some manual scan, you can go in the UI that we developed. But that was kind of like one aspect, like really plugging it into existing processes and tooling. And the second one was like plain English explanations of what you're seeing. A lot of tooling. Out there, you know, might give you like some weird acronym, uh, that are hard to understand and interpret vulnerabilities that was found. And so it becomes very hard to take actions on it. And LLMs today allow you to give you like very clear and easy to understand plain English explanations of what the vulnerability is, why it is a vulnerability, and what are the steps you should take. To go and actually fix it. So those were the two principles we had in mind.

Great. And it's, it's, I can't restate the importance of data protection and you see it every day. I recently, as in within the last week, had a notification from an airline outside of America, but basically that had a breach and it was my name, address, and my number for that airline that had been accessed, but they didn't access any payment details so that they're separated. And even that email out that I got, I didn't see any news or headlines about it, but being able to know that that was the case and acting accordingly for me as a customer. Within that, I assume that you need to be quite tight with each of your customers as far as the process. So if a data breach or something does happen, do you get involved at all in sort of giving people contextual information that they can then use to distribute to their customer base? How does that work if there is something serious that happens?

Yeah, so none of our customers so far has had any major, like, security breach. That has been good. That's good for them. That's good. But I've had people that I knew and were not customers, like, being hacked and losing money. And I got involved more, like, not because we wanted, like, retribution from them, or, you know, like, a lot of times you see a bunch of security teams, like, a bunch of security vendors coming on you when there's a hack and wanting to help because, you know, it's, you know, revenue that they could make. I got involved because, like, it was this team of, like, young people that I knew because they were, like, we were in like in the same industry in New York and they were building like cool things and they got hacked for several million dollars and I just wanted to help and I had seen many, plenty of those cases in the past and wanted to make sure that they took the right steps in addressing the situation and so I reached out, put them in touch with like law enforcement and the right people in law enforcement, put them in touch with investigative like companies and they were actually able to recover all the money. In this case, it was like a crypto company. And so like, we, our customers obviously would, we would get involved, right? If anything happened and we would like then assist them and holding them through the process. But luckily so far, none of them have been like hacked or experienced like a breach. So I can't tell you what we generally do because it hasn't happened yet, right? Fortunately. But we definitely can like be first to step in and just like help them.

It sounds valuable to be able to think about what you do as a process and who are the contacts that you can have. So good advice there. To finish up today, Francesco, anything about Almanax that you'd love to share as far as the product and how people can reach out to you?

Yeah, so We were saying earlier, like security is always like a cat and mouse game and bad guys are moving faster than good guys. So like bottom line, really, like we're seeing how LLMs can really help in the security processes compared to traditional toolings. And so if you're not using some sort of LLM-based solution, you're, as a founder, you're kind of being irresponsible toward your company and your stakeholders. So you should look at it. The good news, and I'm very optimistic about this, is that most security teams and founders are like being opening their eyes and really starting to adopt these solutions. And the AI adoption, even in cybersecurity, is like moving pretty fast. There's much, much more than we can do. I am, you know, our website is like almanax.ai. So for anybody who wants to like go and try it, there's, you could go and set it up like self-service without even talking to me. But if you do want to talk to me, my email is francesco@almanax.ai, so, um, feel free to reach out. If not, you don't want to talk to a human, just go and talk to the machine at Almanax.

Awesome. What a great way to wrap up. Thank you so much, Francesco. I found that super insightful.

Thank you, Andy. This was fun.

Thanks for listening to Startups Decoded. If today's conversation help you think differently, share it with a founder in your network, and don't forget to subscribe for real-world startup insights every week. We really value your support. If you're interested in partnering with us, email hello@startupsdecoded.com. I'm Andy Walsh. I'll see you next week.