Snake Oilers: Minimal.dev, Request Rocket and TRM Labs

0:04Alex Ferguson: Hi everyone and welcome to this special Snake Oilers edition of the Risky Business Podcast. My name's Patrick Gray. For those of you who aren't familiar with what a Snake Oilers edition is, it's where we get a handful of vendors together into the one podcast to pitch you, the listener, on the software or services that they make or provide. And yeah, we're going to be hearing from three vendors today. In the first slot, we've got minimal.dev, but I'll intro them in a minute. In the second slot is an Australian company called Request Rocket. And what Request Rocket does is it lets you sort of add granular permissions to APIs that otherwise may not have them.

0:47Alex Ferguson: So it's like a gateway for outbound API requests that applies security controls around how API access tends to happen in a typical organization. So Alex Ferguson is the founder of that one, and he'll be along shortly to walk us through all of that. We will also be hearing from Simon Warren at TRM Labs in this podcast. TRM Labs started off as a blockchain analysis company or a blockchain forensics company, kind of like a LipDik or Chainalysis. But these days, they do all source threat intelligence. And, you know, some serious backers for this company like Goldman Sachs and Visa. And, you know, they've come up with a really interesting product that they want to promote, whereby they can give you access via like an AI chatbot interface, I guess, to just an incredible array of threat intelligence feeds and products.

1:43Alex Ferguson: I think they're adding MCP, an MCP sort of, you can access it via MCP in the future, but currently it's like a chat interface. but instead of you having to buy and like you know tick the box to subscribe to a whole bunch of different thread intel feeds what they're doing is it's a perk weary billing method so you just get incredible breadth of access without having to you know buy or you can eat subscriptions to a lot of these these feeds very interesting stuff so Simon Warren will be along a little bit later on to talk through the Ardents platform from TRM Labs. But first up, we're going to hear from Jake King.

2:23Alex Ferguson: So Jake, regular listeners might remember Jake. He co-founded a company called CMD, a Linux security company he wound up selling off to Elastic. Jake, as you'll hear, he is Australian, but he is based in Canada. But now he's running a new startup. He's back, he's doing it again. And the startup is called Minimal.dev. And the idea behind minimal.dev is it is a sandbox for AI agents. So if you want to run like a software development agent on your computer without having it like ransacking every corner of your hard drive and like doing horrible things to your system and, you know, bad stuff on the network and whatnot, you're going to need something like minimal.dev.

3:07Alex Ferguson: So yeah, agent sandbox and agent runtime. time. And here is Jake King kicking things off in this podcast by explaining what minimal.dev actually is. Enjoy.

3:19Simon Warren: Remote agents are an incredible ergonomic. And I think the major model providers, the flagship model providers gave us a really good hint of what using an agent and giving an agent its own computer can feel like and look like. That doesn't really work in the reality when you want to use that in the enterprise, when you want to give it access to internal code bases when you want to give it access to internal tools or you want to govern the way that that agent can operate on a machine and so we focus on all of those primitives being a first class experience inside a minimal so things like network access isolating what an agent can go talk to on the internet ingress and egress uh thinking about the secrets but i mean

3:58Alex Ferguson: come on as if there'd be any problem letting an agent talk to the internet that's crazy talk jake

4:03Simon Warren: Yeah, absolutely. You know, agent network controls are always a bit of a hot button topic because we, you see the press and the news. I think there's always one of these flagship agents breaching containment, going and using an old wiki for, you know, agent to agent comms or swarms. isolating the things that an agent can do on a network layer, I think is like almost the table stakes for how you want to use an agent. It's when you go beyond that, you know, where is it pulling your resource from? What is it doing? How is it working? How are we collecting telemetry on that agent and how it's running all the way down to being able to move it around and not being tied to a single vendor?

4:42Simon Warren: How, how we use agents, I think has matured a lot in the last year and And probably in the last three months, it's accelerated insanely. So staying ahead of how that stuff works is going to be incredibly important.

4:54Alex Ferguson: Now, early on, your focus is on coding agents, right?

4:58Simon Warren: Yeah.

4:59Alex Ferguson: And, you know, that makes sense because that's what most people are using agents to do at the moment. I mean, obviously, that's going to change in the future. And I'm sure you'll be able to service those people as well. But, like, I guess, you know, you're throwing some shade. And I'm here for it. But you're basically throwing some shade at the Frontier Labs and saying, this is not an Enterprise product. Why don't you, you know, can you substantiate that for us? Like, what are the risks that you're kind of actually trying to address here? You know, tangible risks that people are experiencing when they're using Codex, you know, when they're using Claude Code, what are those risks?

5:31Simon Warren: So I think the way that Enterprise uses agents today looks very different to the way that you might see some folks on X on Twitter kind of talking about using an agent in a very agentic software factory. Um, most of the use cases that I hear about are agents being used for tab code completion. You know, they're being used to some automation tasks. They're often being used in like agentic workflows. And in those cases, you know, having an agent given, giving it access to the internet, giving it a very scoped task is, is, is something that a lot of companies have just grown to accept is the normal role of how we use these things these days.

6:07Simon Warren: Um, I, I fundamentally disagree with that. I think when you use an agent today, that agent should have access to the tools that it needs and nothing more. It should have access to the resources it needs and nothing more. And it should have access to the credentials it needs and nothing more. And that all lays down the basic principle of building good hygiene and security, especially for the enterprise. Open source or kind of like frontier agents have been being released for months now. You kind of talked a bit about the outside of coding agent kind of world. OpenClaw is a great example of this.

6:42Simon Warren: The first thing people want to do is make these agents do things that are very powerful. And, you know, that's well within the right of anyone to go and do and well within the right of the enterprise to need to do. We want to make those use cases a lot smoother, a lot more seamless and really grow the ways that they can be used in a sensible manner. When you think about your Frontier Lab releasing an agent, fundamentally they're a company of software engineers and machine learning experts building a model. They're training that model and then they're putting an agent on the other end of it to make an interface that works for a lot of the tasking that we use day to day.

7:21Simon Warren: That's fantastic. But how do we make sure that where that process runs, the things that it can do and the access that it's granted can be done in a safe manner? So we're not seeing, you know, the horror stories that we've been hearing about over the last 12 months happen to us.

7:37Alex Ferguson: Yeah, it's funny, right? I mean, look, you know, they're pretty edge cases-ish, right? Because you're running something through a cyber gym or an exploit gym, right? That's when you're going to see some funny behavior as opposed to when you're trying to update a corporate web application for code code, right? So, sure. But I do get your point that the major labs, they are trying to pivot hard into enterprise, right? At the moment, they are a little bit behind. But I think the point is, too, you alluded to this earlier, that there are open source agents popping up. And I think, you know, you look at how much people are using OpenWeight's models as well at the moment.

8:17Alex Ferguson: And you can sort of see that for a lot of organizations, they're not going to want to use the Frontier Enterprise, you know, their enterprise product. They might want to use some open source thing, give it some enterprise features. and then route requests, route work through something like OpenRouter to whatever model it is based on their request. I mean, is that kind of the vision that you've got that's driving you building a product that you think people are going to want because in the future, they're going to be much more relying on sort of some of these open source building blocks?

8:48Simon Warren: Openweight models and open source agents, I feel are really the future of building bespoke products. So, you know, if you think of Anthropic building Claude, as an agent that you can use on your machine called Code. It's a powerful system, but it is a very generic system. It's designed to be very good for a lot of general purpose tasks. If you have built your own version of Pi and you've customized a system prompt and you've given it very specific access to tools and you want to use QN 3.8 because you can do a lot of the work that you would normally do with Code at 5x the cost yourself, this is a reality that people are coming and talking to us about.

9:26Alex Ferguson: You're going to need a runtime for that, right? Absolutely.

9:29Simon Warren: You are absolutely going to need a runtime. And going beyond that, thinking about where that runtime runs is a challenge that a lot of the enterprise is dealing with now. Right now, you've got developers installing Pi on a local workstation. They're firing it up, customizing a system prompt, and they're saying, hey, go for it. I think a lot of the edge cases -

9:47Alex Ferguson: I told the agent not to do anything bad. I instructed the model not to tell the agent to do anything bad, so we're good, right?

9:53Simon Warren: Make no mistakes is the - Yes, exactly. The statement that I always hear, but don't cause me any trouble. Don't, don't, don't give me a heart attack. The, the component that I always kind of lean into here is, you know, the enterprise has specific use cases. And I think while Anthropic and OpenAI have done an amazing job of providing model access and frontier, you know, intelligence APIs, when you get into more advanced use cases and you want to be using these agents to perform automated tasks, you know, modify code, write code, write responses. It's really important to be able to isolate how that software runs and the kind of primitives that are required for it.

10:30Simon Warren: So to answer your question, it's exactly where I think the future of these systems goes. We all want personalization in the way that we use a model and we all want personalization in the way that we use an agent. Yes, you can use a general purpose, you know, kind of agent to perform a lot of specific tasks. It's inefficient. It's certainly not the way that you should be building in a consistent way. It's expensive. And it's expensive. Yeah. It's really expensive. And slow. It's very expensive. I'll also say there's another side of this that started to pop up as well. And, you know, we're talking a little bit before we started recording today about open weight models and, you know, running your own inference.

11:10Simon Warren: This is something that I do for a myriad of different reasons, mainly because it's cheaper for some tasks, but it's also only what I need for a lot of the things that I do day to day. And, you know, I think the enterprise is moving towards hosting their own models or using the hyperscaler that they're already paying for compute from to give them access to a model, you know, gives you options. You've got the, you've got the ability to choose what you want to run, how you want to run it and, and which agent goes and talks to that model. And so, you know, I think, I think the more we get into specialized use cases around these tools, it'll be the Apple versus Android ecosystem.

11:46Simon Warren: Do you want a very kind of run of the mill, very standardized process, or do you want to add a bit of customization to the workflow that you want to create for your business?

11:54Alex Ferguson: So tell me a little bit about minimal, actually what it is. Like, is it a hypervisor based product? Is it just like some sort of, you know, is it a containerized environment? Like what actually is it?

12:04Simon Warren: So we started by looking at primitives of isolation and we chose to use LibK Run, which is a isolation technology that works on Linux and macOS for us. And it gives you an environment that effectively allows you to isolate things like network, process, access to resources, and all of these kinds of things. And a lot of companies kind of stop there. I think everyone that's listening to this has seen 50 ,000 sandbox vendors pop up on the planet, which has a very different path, which is most of the use cases that we see in businesses today are a developer using an agent or using multiple agents on a local workstation.

12:41Simon Warren: And we make that as seamless as possible. So the second that user wants to go from one to many agents, each time an agent started, it can be run in an isolated fashion with just what it needs. And as we start to scale up with those users of our technology, they can either push things remotely, run it on compute, they run in their own cloud, and potentially even run it on some cloud that we host as well. But foundationally, we use an isolation capability that launches these runtimes. What makes this very special is the attention to detail of what that environment is. So the majority of sandboxing that's done today is done with a standard Debian operating system environment.

13:19Simon Warren: What we've chosen to do is take dependencies straight from upstream. So if you're using a project on GitHub, you're running a Golang runtime or a Rust runtime, we fetch these directly from the upstream vendors and we build everything that we push into these environments with a huge attention to detail. We're aiming for sales to level four and we're probably around sales to level three right now in the early days. And what this means is that every ingredient that's pulled into that isolated environment is verified. And we give consumers of our capabilities the way to declare new tools, but we offer a huge capability list of tools that anyone can use in these environments today.

14:00Alex Ferguson: Yeah, I mean, I just looked it up. I hadn't actually heard of that before, but LibK Run, it's like, yeah, like a micro VM thing, right? Using KVM on Linux and Hypervisor.framework on Mac OS 64. So that is groovy. Nothing for Windows at the moment, mate.

14:15Simon Warren: We're working on it. We're working on it. You're working on it, right.

14:17Alex Ferguson: Is that actually part of the roadmap? Is that part of the plan?

14:20Simon Warren: WSL. I've had the question about WSL a few times. So Windows subsystem for Linux is is really interesting. A lot of people are using -

14:29Alex Ferguson: Oh, so you could just WSL this, right. Okay. That's right. But does it work with LibK Run or does that get a bit jank? Like, I'm just being honest.

14:36Simon Warren: I think it's going to get, I think it needs a couple of ethics built out. But if someone's got a Microsoft environment they want to talk about isolation in, I'm all ears. I'd love to hear about it.

14:48Alex Ferguson: So you're going to need to submit some suggestions to the LibK Run team?

14:53Simon Warren: Submit some suggestions. Tell me about the use case. Yes, I'll explain why there's a bit of a softer story there to start off with. The majority of agent users that we see out there today that are in the enterprise are either using macOS machines or they're using some kind of remote compute to do some of this work.

15:09Alex Ferguson: Yeah, it's going to be some cloud-based VM in digital or whatever, right? Like that's how it's going to be.

15:14Simon Warren: And a lot of the time, you know, we've heard a lot of things about, you know, hey, can I run this directly on Windows? Is this something that you want to support? We've built an ecosystem and supply chain kind of posture around a lot of Linux binaries. I feel really strongly about agents running on Linux the best. And I kind of like it. But if I'm hearing feedback -

15:35Alex Ferguson: Well, you are a Linux nerd. I mean, your last company was literally a Linux-based security company. So this makes sense at all tracks. Jake, man, we're out of time. It's great to have you back on the show talking about a new company. It's really good to have you here. Minimal.dev, very interesting stuff. Wish you all the best with it. And I'd expect that we'll be talking to you a bit next year as you build this out. So thanks for joining us.

15:56Simon Warren: Perfect, mate. Thanks, Pat. Appreciate the time.

15:58Alex Ferguson: That was Jake King of Minimal there or minimal.dev if you want the URL. So yeah, we'll be hearing from Jake some more next year because they're going to come on as a risky business sponsor. So that's pretty cool. So next up, we are going to hear from Alex Ferguson, who is the founder of Request Rocket. And what Request Rocket does is it sort of helps you to add granular permissions to APIs that might not otherwise have them. So you can think of it as like a gateway for outbound API requests that applies security controls around how API access tends to happen in the typical organization, right?

16:37Alex Ferguson: And this is a handy way of adding security controls. Like a gateway like this is good for adding security controls when you're dealing with APIs that aren't necessarily yours. so you can't even modify them or start adding sensible permission models to them. So some sort of middleware like this makes a lot of sense. So here is Alex Ferguson chatting about Request Rocket and explaining what it is that it actually does.

17:03Simon Warren: Enjoy. The problem that Request Rocket's solving in today's world is that I suppose data should be easy to connect to and the connections that we make to it should be secure. and the problem that we've experienced and myself experienced as an integrator over the last 10 years has been that neither of those two things are actually true and so what we built with request rocket is a universal translator that allows us to connect control govern and observe every connection that we're making to every system and even the ones that we don't own because even if we go back 10 years it's not just humans but machines and now even ai only needs to be able to access those things that we commit them to.

17:46And the challenges we have in the industry today is that the systems that we connect to don't necessarily match

17:53Simon Warren: our expectations around the security of those connections. And so Request Rocket allows us to customize how we connect to different systems. And it turns out that that actually is a really big problem today when we're talking about how does AI connect to legacy and even modern stacks. being able to downscope and provide fine-grained control over what AI can do is exactly the problem that we've needed to solve for when humans build integrations and when they connect to different systems.

18:25Alex Ferguson: Okay, so why don't you walk us through a couple of concrete examples there, right? Because you did cover, you know, I mean, that's a pretty wide brush, right? Wide brush painting that you've given us there. You know, one example there, you know, you spoke about AI agents, for example, or even users connecting to third party systems and then being able to like downscope, you know, their access. Why don't you talk to, talk us through an example there so that the listeners can better understand what you're talking about?

18:51Simon Warren: Yeah, sure. It might help if I walk through a bit of a story of how I came about building the platform and the different problems that we solved through a number of different problems that we experienced over the last 10 years. So in the first instance, it's that all of the systems that we connect to, they all authenticate differently. In fact, it's pretty much chaos out there. Despite the fact that we have a range of different authentication protocols and standards as to how we might build those connections, the reality is that everyone who builds an application today does something different from that standard.

19:27Simon Warren: And so the level of nuance across the broad spectrum of different applications becomes problematic when you're trying to connect to different platforms. Before you can even look at the APIs, you've got to think about, well, how do I authenticate? And so the one thing we did first with RequestRocket was build this authentication translation layer where we could drop in a proxy, a reverse proxy, and we can translate from whatever the authentication and upstream service provides into something that we wanted to be able to consume. It turns out that becomes quite useful when you're wanting to connect systems to BI, for example, where systems platforms like Power BI only have two methods of authentication that they can securely handle out of the box.

20:08Simon Warren: So being able to translate from one to the other allows us to just directly route traffic from an API, a third-party system, straight into Power BI without having to have any additional data wrangling, data handling, data processing pipelines. that becomes one thing that the platform has straight out of the box but that wasn't enough for us because in in my story you know I remember back to about five years ago working with a global payroll company and they gave me a key to build an integration for one of their customers now a little known secret in the industry is there's only a certain number of payroll platforms on the planet and a lot of these companies they'll white label a third-party platform when they're providing services to customers.

20:56Simon Warren: So this key that the client has no control over gives me access to at that time 50 different companies and all their payroll data and salary data and personal information about every employee across 50 companies and I only need to build an integration for one of them. And so the key pain point for me is well I have all of this responsibility and accountability over access to this system, but I don't have the tools that I need in order to manage it. And so in Request Rocket, what we also have is the ability to drop in an authorization layer that says this user or this particular request is either allowed or denied based on certain criteria that we can configure in the platform.

21:41Simon Warren: And so we have this deterministic predicate-based rule system that allows us to determine down to the individual identity of the caller as to the parts of the API that they're allowed to access.

21:55Alex Ferguson: This kind of reminds me of some products that were around a long time ago, like 20 years ago for databases, right? So I remember IBM had one, and it was sort of like this idea that you could redact fields on the fly. It's like, well, this user is connecting from a call center or whatever. They don't really need to see this field, that field. And then you had companies doing some more sophisticated stuff like Imperva. I don't know if that rings a bell for you, but they were doing similar stuff back then before they wound up doing web application firewalls and whatnot. I mean, it is that sort of thinking, isn't it?

22:27Alex Ferguson: But instead of being for like a SQL database where everything's quite structured, in this case, you're able to do it for an API endpoint. Yeah, for an API endpoint, you can actually, you know, I guess what, set up some sort of schema inside your proxy so that it talks to that API. And is that kind of how it works?

22:46Simon Warren: Absolutely. Through configuration, you can set up two different types of scenarios. is one is an authorization that if you imagine someone has a CRM and you want to give one developer access to the client data and another developer access to the opportunity pipeline, we can provide access that is different to each individual developer or system or integration. But as you mentioned, rightly so, that itself, authorization control, doesn't necessarily provide the kind of level of fine brain control that we needed. So we also had to add into the system the ability to filter out data. And so what we can do is actually, again, built on a predicate-based rules engine, determine, you know, for this particular caller, let's say it's a caller or, you know, a doctor calling a health system, you know, the patient record list might come back with all the patients we actually only want the doctor to be able to see only their own patients so being able to remove you know think like row or column level security in a database translating that into the API layer is like we could remove data from an array of responses and we can also removed information like you know their Medicare or other banking details or whatever it might be that's actually in those payloads so that the caller actually never gets to see them in the first place.

24:10Alex Ferguson: Yeah. And I mean, this is, I guess, for a modern world where you're going to have that same user touching data via multiple API endpoints, having one spot where they can do that sort of redaction makes sense. Now, the other thing that you mentioned is, yeah, third party systems are a big part of this, right? Because you can't decide how fine grained their authentication and authorization schemes are. You don't get to do that right so so this is a way to actually apply it to uh some some sort of sensible reduction and scoping to ancient janky systems that where they might have in the case of that payroll company for example an all or nothing auth key uh so i guess at that point you really become yeah you become like a scoping uh platform scoping proxy for those those systems that's right

25:01Simon Warren: We're wrapping authorization, role-based access or attribute-based access control around an existing system. And it's not just the legacy platforms too. We see a lot of modern platforms that come out in their first instance, especially ones that AI is now vibe-coding thousands of applications into existence. the most basic form of authentication that you generally get out of the box for someone who's built a brand new system is an API key. And broadly, API keys are all or nothing in their scope in most cases.

25:39Alex Ferguson: I do feel like that's going to change, but it's probably going to take 20 years. You know what I mean? I think AI is helping with that because everyone's like, we need to limit OAuth scopes because of AI agents.

25:49Simon Warren: And the challenge then is that there are some systems that simply can't consume an old scope right um and so when we talk about being i think is the point you can we can we can rotate them and we keep those connections up to date so that means that we take a lot of the heavy lifting off of the off of the developer um but the other aspect of it is because traffic's flowing through the platform and we're a hyperscale platform so we you know we we work faster than most APIs be on in production today. What we can do is we can also get telemetry data and observability and audit data that allows us to go back and actually understand what were the access patterns over time as well.

26:30Simon Warren: And so when it comes to GRC,

26:33Alex Ferguson: who touched what with what? Yeah, exactly. I get it. And, and, and, you know, what's funny is like so many people, cause I'm building a tool with some of this sort of thinking in it. It's a very different product, but you know, everybody gets excited like someone in the on the developer team might be like hey you know we could do all of this really cool detection stuff and figure out what's normal and it's like that's not actually what people want what they want is an audit trail so that when something does go wrong they can go back to a nice structured audit trail and actually be able to figure out like what what happened what went wrong yeah exactly yeah has that been your experience as

27:08Simon Warren: well a hundred percent and and one of the one of the reasons we built that in is because as an integrator, I'll tell you a little story. You know, once you build an integration for a client, what happens next? Your fingers crossed, everything goes great. Six months later, something fails. And that failure immediately by default was the responsibility of the integrator. And it's their fault that things aren't working. You know, you can take three or four days diving through logs to find an actual problem. Whereas in most cases, in my experience, the problems occurred at an interface, at an API interface, whether it was a token expired or something of that kind or the system went down and you didn't you know and became unreliable so we have to work around that when we build different connections with request rocket what we can do is log directly into the system we can see exactly when those api calls started failing now we now instead of searching through a week's worth of logs we know these are time stamp of the logs we need to go and look at to find the problem so we're reducing the effort that's required to maintain these connections but also being able to go back and you know replay well what are the things that actually occur that led to that point you know in Reese in a month ago I had a client who had a very similar situation their integration was failing they went ahead and looked at the logs and they could within five minutes they could figure out that their customer had actually revoked their credentials and so you know very easy for them to turn around and say hey actually the integration is working perfectly, except you've just now denied all of our access to the system.

28:42Simon Warren: We need to push the data into. All right.

28:45Alex Ferguson: Well, Alex Ferguson, sounds like you're off to a terrific start with it. Thank you so much for joining us to walk us through Request Rocket and what it is and how it works. Thank you for having me on, Pat. Appreciate it. That was Alex Ferguson there from Request Rocket. Big thanks to him for that. It's time to hear from our third and final snake oiler now, which is Simon Warren of TRM Labs. Now, as I said at the top of the show, TRM Labs kind of started off a bit like Chainalysis or Elliptic, being like a blockchain forensics, blockchain threat intelligence style company. But now they are very much an all-source threat intelligence play.

29:24Alex Ferguson: They're a serious business. They've got the backing of organizations like Goldman Sachs and Visa. And they've come up with an interesting idea. They've got a platform called Ardents. And as far as I know, the business model for Ardents is pretty unique. Because instead of you getting some sort of Threat Intel aggregator platform where you license a bunch of feeds and pay the monthly fee and plug them all in, Ardents is built on usage. So you can access this incredibly wide array of Threat Intelligence feeds and just pay for what you use. Some of these queries are going to be very, very cheap. some of them are going to be very very expensive that's just the nature of the beast I mean I think this sounds like the sort of thing where I know everybody kind of has their favorite feeds but I feel like this is a great way to go get exposure to maybe some other threat Intel products that are out there you might stick with it you might just say hey I've just found these three really cool ones and they're all I'm using and go off and license them or whatever like either way this is super interesting and Simon join me to explain what this platform, Ardents, is all about.

30:32Alex Ferguson: And yeah, here's what he had to say. Enjoy.

30:35Jake King: The platform I'm going to talk about today is called Ardents. It's TRM's all-source investigation platform, which is powered by AI. I think what makes it slightly different to some of the other similar CTI platforms or CTI feeds out there is that it pulls together about 50 different data partners into one place. All of those data partners have multiple endpoints as It's well over 100 different endpoints that this platform can call, all included in one platform and one contract, importantly. So when you get an Arden's contract, when you log in, everything is all ready to go in there. And it is the analytical layer and the AI that decides which API to call and when, and often calls dozens in parallel to answer your natural language query.

31:20Alex Ferguson: Now, I'm curious, right? Is this a thing that more and more CTI companies are doing, which is sort of bundling together different feeds into a usage-based model? Or is this something new that you guys are doing?

31:34Jake King: We think it's something pretty new, to be honest. So if you look at the threat intelligence... Because I'm sorry to interrupt you,

31:39Alex Ferguson: but I'm sure there's people who are aggregating the feeds, right? And you could pay like a monster subscription or whatever. But like the pay per query thing seems... I haven't heard of that before, but I'm not in CTI. So that's why I'm asking.

31:51Jake King: Yeah. So a good comparison would be to the tip market, the threat and target platform market, where you can buy the platform and then you can choose from their marketplace which feeds you want to ingest. You click, I want to ingest all these different feeds and then you pay an additional subscription to bring that feed in. So you're just choosing which feeds you want to add into your aggregator. And you're getting the analysis and the overlay. Lots of them have a natural language front end now as well. but the big difference is we've just made that decision for our clients and said these you're going to put all the data partners in here already so 50 plus different data partners and then the the ai once you put your natural language query in the ai will decide which data partner to call so from our perspective it's a really efficient and cost-effective way of consuming a really really broad range of data sources which you might not necessarily have traditionally looked at so things like sanctions data, obviously blockchain intelligence data, which is the foundation of the platform.

32:48Jake King: So these are data sources that as a CTI practitioner might have been on the fringes of your investigation. You might want to go out and spend a certain amount on an annual subscription on this, but if you can just call it via API as and when you need it, it's a really cost-effective way of running investigations.

33:03Alex Ferguson: Yeah. Now you were telling me the other day, because we did a prep call before doing the interview, you were telling me the other day that some of these queries cost cost basically nothing, or trivial cost. And some of the costs can be like, what was it? Like a couple of hundred bucks to run certain queries. So are you asking the AI certain questions and then it's like, hey, just so you know, this is going to cost a couple of hundred bucks? Or is it something that can get away from the customers, I guess? I'm guessing you've thought of that.

33:31Jake King: Yeah, it's actually a really good question. And it's a really important part of the front end experience that the clients get. is we want to find a really nice balance between giving them the freedom to run investigations and also them just not blowing out all their credits in one single investigation. And we've seen that through over a year of testing now. There are certain things you can do which will just blow out everything. If you accidentally find 3 ,000 email addresses and then say, just enrich all of those email addresses with all of the data sources you've got, suddenly you've done hundreds and hundreds of thousands of individual API calls.

34:03Jake King: And if you're calling a certain data source, that's not a couple of cents. It could be very expensive very quickly. There's a couple of things we do, both manual and automatic. Manually, we'll do a lot of fine-tuning once we onboard clients to make sure they're accessing the appropriate data sources. So if they're really interested in really tactical threat intelligence, internet infrastructure, email addresses, things like that, we'll make sure those are turned on. And if they're not necessarily as interested in maybe dark web intelligence, dark net markets, other intelligence sources will turn them off.

34:37Jake King: So when they run those queries, there's no possibility for it to call irrelevant data sources. So that's what we do right at the beginning. We can also implement credit caps as well. So if the client is concerned about, if they've got maybe 10, 15 users and they don't know what they're doing day to day, we could just put a cap on the credits and it'll either be a hard cap or a soft cap. So the hard cap will be, you know, you've got to this many credits, it'll just stop working, which is a frustrating experience for users. So we try to avoid that. And we've got soft caps where it will say, So, you know, you've used your allotted allowance of credits for the day.

35:07Jake King: Maybe wait until the next day to run out.

35:10Alex Ferguson: Go touch some grass, fella. Yeah, get outside. Yeah, exactly. Go talk to your kids. Makes sense. So why don't you walk us through some use cases here, right? Like where it's going to be advantageous to have this sort of breadth of access. Because, you know, normally these jobs, they're pretty specialized, right? These CTI types, they know they're going into a job and they're like, I need a feed that tells me this, I need a feed that tells me that, I need one for this, one for this, one for this. And they've got their little list of feeds, right? So why is it advantageous then for them to have this broader data access?

35:46Alex Ferguson: I mean, I'm guessing it's that they don't know what they're missing until they actually try pulling from a wider set of sources, right?

35:53Jake King: Yeah, it's partly that because we're just going to put 50 plus data sources in front of the model and it'll choose the most appropriate one. So you don't have to worry about going out there and deciding which data sources you want to look at. But it's also trying to solve that problem of the context switching that analysts have. So they might have had 5, 10, 15 different data sources, but they're all in separate platforms. They might have bought another platform to aggregate them all and consolidate them all into one place. But it's still a lot of context switching, different platforms, different logins.

36:26Jake King: They might have direct access to some dark web forums. might be googling stuff as well it's putting all of that into one place into one interface where you can query it really easily and it will just call those appropriate data sources and pull them back in for you whilst keeping the analyst in the loop as well so it's not just going to run off and do everything by itself if if you let me just talk through a very quick example use case this is a really common one uh we see i really like it please i mean that's i we love we love examples you know walk us walk us through them right yeah and i think this i really like this one because this is something that I have done in the past when I knew back in the day when I was doing CTI work myself it's something that's very similar to a workflow that I would have run and it would have required me to use multiple different data sources again I probably would have started with some sort of Google search to get a bit of context I would have had I would have been going into the dark web look at sources in there maybe looking at discord and telegram as well very time consuming very painful all the way through start to finish so this is a ransomware example so a really good workflow we like to show clients and potential clients is just you know ask a really broad question about something like how is ransomware impacting my sector how has it impacted my sector over the past six months you can be you can be as broad as that ardent's is then going to go and ask a certain number of platforms probably things like bit site flashpoint sop radar it'll ask all of them the same question.

37:50Jake King: Tell me about ransomware and the oil and gas industry, the mining industry in Australia, for example, over the past six months. Pull all that back together, analyze it for you and present those results to you. And from there, you can then start enriching on what you found very quickly with different data sources. So you can say, cool, it sounds like CLOP is a real threat to us in our sector. Tell me about their TTPs.

38:10Alex Ferguson: What CVEs are they targeting at the moment? What sort of equipment? Yeah. Do we have anything? Well, I guess it wouldn't have that. It wouldn't have that context of what you're running necessarily. but yeah you you do so not not yet no not yet yeah but we're building towards that so you'll

38:22Jake King: be able to say okay map that against my assets and tell me tell me what's vulnerable um so you know then you're pivoting into other data sources like maybe overwatch or census or something like that and then then you start going into the those fringe data sources that you might not have touched before so okay this is clop but tell me about wallets linked to clop and tell me about patterns linked to their transactions associated with ransom attacks okay cool and then set up some monitoring and alerting for when you observe those patterns so we can see whether that threat group is still active or not.

38:54Jake King: And then you can look at, you know, ask how are victims typically accessed? Is it through compromised credentials? Okay, well, let's now go and look at another data source, Hudson Rock, SpyCloud, something like that, and ask have we got any compromised credentials that have been leaked recently from our company? So we can go out and look for that as well and pull all that together. So you've pulled stuff from the dark web, leaked credentials, you know, MITRE attack TTPs, all sorts of stuff, and say, cool, that's a lot of information there. And then you can decide what the output looks like and just say to audience, okay, I need an executive summary for my CISO, generate a one-page executive summary of this threat, what we should do about it, listen up to the CISO.

39:30Alex Ferguson: What you're describing is, you know, the sort of AI, ideal sort of AI workflow, just generally. But in this case, you've plumbed it through to actually useful data, right? which is a step many people miss with their AI products when they're dealing with general models. I mean, it makes sense. I mean, do you also offer, is there going to be some sort of API-ish version of this as well where you can hook it up for various types of automated enrichment? But I mean, because you've just given us completely AI-driven, chatbot-driven use cases so far and mentioned the AI side to it a lot. But are there going to be sort of more API-driven versions of this?

40:15Jake King: Yeah, definitely. I think what we're trying to do is build a tool or a platform that fits into existing workflows. We don't want you to get rid of all your other tools that sit around cyber threat intelligence. We want it to plug in nicely and fit in with your SIEM and your SOAR and everything else in there. So we're building towards a world where you'll be able to do a slash command, slash ardence in Splunk, tell me more about this IOC and whether or not I actually need to block this IP address. and it will just call an MCP of Ardent and Ardent store that enrichment in the background and say, yes, this looks bad based on all these different data sources.

40:50Alex Ferguson: Well, it's interesting because I said, are you going to make it available via an API? And you said, well, it'll be MCP, which is like just proving my sort of opinion that MCPs are just the new APIs, basically. Yeah, yeah, they are basically. No, I mean, this is really cool. This is really cool. So are there certain data sources? Walk me through some of these data sources because we spoke about this the other day. And some of them are a bit esoteric. Some of them are a little bit exotic. The sanctions stuff was really interesting to me. Walk me through these providers of sanctions data.

41:22Jake King: Sanctions is probably somewhat exotic. We've got a lot more exotic than sanctions in there. We've got a few different sanctions data providers in there. Sanctions.io is one of the main ones. But that's super interesting. If you get to a place where you found a person's name in an investigation or a company name in an investigation, you can just say, OK, are they on any sanctions list anyway? And I'm like, yeah, they're on an Iranian sanctions list, this company you've never heard of. And then you can say, OK, well, tell me about other directors linked to this company. So you're going well beyond the normal scope of a CTI investigation.

41:56Jake King: And then when you get into the people side of things, you can then use another data source. It has corporate data about, you know, or personal data. tell me about this person's registered email addresses, phone numbers, if they've got an address linked to them. And you can pull those threads and keep pulling those threads where normally you'd probably hit a bit of a wall and say, I haven't got any sanctions feeds.

42:14Alex Ferguson: Can you think of another example of an exotic data source? Something that people just wouldn't think about?

42:22Jake King: Yeah, I think it's not exotic to us at TRM at all, but probably the blockchain intelligence data is quite exotic to some people because we've got the richest source of blockchain intelligence data in the world and again typically you when you ransom investigation is a really good example but if you got to a point where you wanted to know more about you know how active is this threat group a great way to understand that is tell me about recent transactions associated with wallets that they've used in the past you know are they still are there transactions coming in and out of their wallet and then you know tell me about exchanges that are linked to these transactions So you can start looking at where is the money going, start following the money.

42:59Jake King: And more and more of the financial world is moving to on-chain. So that data is incredibly valuable and to a lot of people, I think, would seem quite exotic and almost a bit of a black box. And we've sort of removed the barrier to entry to doing that investigation because Ardentz will suggest if it finds a wallet, it will say, hey, do you want to investigate transactions linked to this wallet? And how many hops do you want to investigate? And maybe you want to look for cash-out points as well. It will sort of hold your hands. If you've never done a crypto investigation before, Ardents will point you in the right direction.

43:29Jake King: You can just say, OK, that sounds good. Run that step for me.

43:32Alex Ferguson: You know, something like that. The question I'm asking it is like, oh, that's an interesting transaction. Tell me the malware families that are connected to this transaction. I mean, because it would be able to actually connect those dots. Simon Warren, this is very interesting stuff. Ardents from TRM Labs. Thank you very much for joining me to walk me and the audience through it. Very interesting stuff. Thanks for your time. Thanks, Patrick. That was Simon Warren of TRM Labs rounding out this edition of the Snake Oilers podcast. Big thanks to him for that. And big thanks to TRM for sponsoring a Snake Oilers slot.

44:07Alex Ferguson: And that is it for this edition. I do hope you enjoyed it. I'll be back soon with more security news and analysis. But until then, I've been Patrick Gray. Thanks for listening.

44:24You