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

Speaker A: Foreign. 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 uh, into the one podcast to pitch you the listener on uh, the software or services uh, that they make or provide. Uh, and uh, yeah we're going to be hearing from three vendors today. Today, uh, in the first slot we've got minimal.dev, but I'll intro them in a minute. Uh, in the second slot is an Australian company called Request Rocket. And uh, what Request Rocket does is it lets you sort of add granular permissions to APIs that otherwise may not have them. So it's like a gateway for outbound API requests that uh, applies security controls around how API access tends to happen uh, in a typical organization. So Alex Ferguson is the founder of that one and he'll be along shortly uh to walk us through all of that. Uh, we will also be hearing from Simon Warren, ah at TRM Labs, uh, in this podcast. TRM Labs started off as a blockchain analysis company, uh, or a blockchain forensics company, kind of like uh, elliptic or chainalysis. But these days they do all source threat intelligence and um, you know some serious backers for this company like Goldman Sachs and Visa, uh, and uh, you know they've, they've come up with a really interesting product that they want to promote uh, whereby they can give you access via like a AI chatbot interface I guess, um, to just an incredible array of threat intelligence feeds and products. Uh, I think they're adding mcp, ah and mcp sort of, you can access it via MCP in the future. But currently uh, it's like a chat interface, um, but instead of you having to buy and like you know, tick the box to subscribe to a whole bunch of different um, thread uh, intel feeds. What they're doing is it's a per query 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 uh, these feeds. Very interesting stuff. Uh, so Simon Warren will be along a little bit later on to talk through the Ardent platform from TRM Labs. Uh but first up we're going to, we're going to hear from Jake King. Uh, so Jake, regular uh, listeners might remember Jake, uh, he co founded a company called uh, 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. Um, but now he's running a new startup. Uh, 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, 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, uh, to your system and you know, bad stuff on the network and whatnot, you're going to need something like minimal.dev. so yeah, Agent sandbox and agent runtime. And here is Jake King, uh, kicking things off this, uh, in this podcast by uh, explaining what minimal.dev actually is. Enjoy.

Speaker B: 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, uh, or you want to govern the way things that, that agent can operate on a machine. And so we focus on all of those primitives being a first class experience inside of minimal. So things like network access, isolating what an agent can go talk to on the Internet, ingress and egress, thinking uh, about the secrets. But

Speaker A: I mean, come on, as if there'd be any problem letting an agent talk to the Internet. That's crazy talk, Jake.

Speaker B: 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, um, 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 a 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, uh, and not being tied to a single vendor. How, how we use agents I think has matured a lot in the last year and probably in the last three months it's accelerated insanely. Um, so staying ahead of, of how that stuff works is going to be incredibly important.

Speaker A: Now, early on, your focus is on coding agents, right?

Speaker B: Yeah.

Speaker A: Uh, and you know, that makes sense because that's what most people are using agents to do, uh, 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'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. Can you substantiate that for us? What are the risks that you're kind of actually trying to address here? Tangible risks that people are experiencing when they're using Codex, when they're using Claude code. What are those risks?

Speaker B: Uh, 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 talking about using an agent in a very, very agentic software factory. Um, most of the use cases that I hear about are agents being used for tab code completion. They're being used for some automation tasks. They're often being used in agentic workflows. And in those cases, having an agent giving it access to the Internet, giving it a very scoped task, is something that a lot of companies have just grown to accept is the normal role of how we use these things these days. Um, 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 in 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, uh, is a great example of this. The first thing people want to do is, is make these agents do things that are very powerful. Um, and you know, that's, 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, a lot more seamless, um, and really grow the ways that they can be used in a sensible manner. Um, when you think about, when you think about, uh, your Frontier Lab releasing an agent, fundamentally they're a company of software engineers and machine learning, machine learning experts building a model, they're training that model and then they're putting, 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. Um, that's fantastic. Uh, but how do we make sure that where that process runs, the things that it can do, uh, and the access that it's granted can be done in a safe manner. So we're not seeing the horror stories that we've been hearing about over the last 12 months happen to us.

Speaker A: Yeah, it's funny, right? I mean look, you know, that's a, uh, they're pretty, they're edge cases. Ish. Right. Cause you're running something through a cyber gym or an exploit gym. All right. Like that's when you're gonna see some fun behavior as opposed to when you're trying to update a corporate web application for code. Right. So. Sure. But I do get your point that the, 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 mentioned you alluded to this earlier, that there are open source agents popping up.

Speaker B: Yeah.

Speaker A: And I think, you know, you look at how much people are using open weights models as well at the moment 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 open router to whatever model it is based on their, 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 some of these open source building blocks,

Speaker B: open weight models and open source agents, I feel, uh, are really the future of building bespoke products. So if you think of anthropic building Claude, uh, as an agent that you can use on your machine, Claude 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 Quinn38 because you can do a lot of the work that you would normally do with Claude at 5x, the cost, uh, yourself, this uh, is a reality that people are coming and talking to us about.

Speaker A: You're going to Need a runtime for that, right? Absolutely, absolutely. Going to need a runtime. And

Speaker B: going beyond that, thinking about where that runtime runs is a, uh, 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. You know, I think a lot of the edge, I

Speaker A: told the agent not to do anything bad. I told them, you know, instructed the model not to tell the agent to do anything bad. So we're good, right?

Speaker B: Make no mistakes is the statement that I always hear. But

Speaker A: don't cause me any trouble. Yeah,

Speaker B: don't give me heart attack. 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, uh, intelligence APIs, when you get into more advanced use cases and you want to be using these agents to perform automated tasks, um, modify code, write code, write responses, um, it's really important to be able to isolate how that software runs and the kind of primitives that are required for it. 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, uh, kind of agent to perform a lot of specific tasks. It's inefficient. Um, it's certainly not the way that you should be building in a consistent way.

Speaker A: It's expensive and

Speaker B: it's expensive. Yeah, it's really expensive.

Speaker A: And so it's

Speaker B: very expensive. I'll also say there's another side of this that started to pop up as well. And we're talking a little bit before we started recording today about, uh, open weight models and running your own inference. Um, 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. 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. Um, 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 uh, think the more we get into, you know, specialized use cases around these tools, it'll be the Apple vs Android ecosystem. Do you want a very, you know, kind of run of the mill, very standardized process or do you want to add a bit of customization to the workflow that you, you want to create for your business?

Speaker A: So uh, 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 container environment? Like what, what actually is it?

Speaker B: So we started by looking at primitives of isolation and we chose to use LIBK Run, which is a isolation, uh, technology that works on Linux and Mac OS for us. Uh, and it gives you an environment that effectively allows you to isolate things like network, uh, process, uh, access to resources and all of these kind of things. And a lot of companies kind of stop there. Uh, I think everyone that's listening to this has seen 50,000 sandbox vendors pop up on the planet. We chose 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. 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 uh, users of our technology, they can either push things remotely, run it on compute, they run in their own cloud, um, 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 uh, standard Debian operating system environment. What we've chosen to do is take dependencies straight from upstream. So uh, if you're using uh, 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 uh, with a huge attention to detail. We're aiming for SALSA level four, um, and we're probably around SALSA 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. Um, and we give consumers of our capabilities the way to declare new tools. Um, but we offer a huge capability list of tools that uh, anyone can use in these environments today?

Speaker A: 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, uh, hypervisor framework on macOS, uh ARM64. So that is groovy. Uh, nothing for Windows at the moment mate.

Speaker B: We're working on it. We're working. You're

Speaker A: working on it, right? Is that actually part of the roadmap? Is that part of the plan?

Speaker B: Wsl? I've had the question about WSL a few times so um, Windows subsystem for Linux is really interesting. A lot of people are

Speaker A: using. 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.

Speaker B: I think it's going to get, I think it needs a, a couple of, a couple of epics built out but if someone's got a Microsoft environment they want to talk about isolation in, I'm um, only hear about it.

Speaker A: So you're going to need to submit some, some suggestions to the. Submit

Speaker B: some suggestions. Tell me about the use case. I'll, I'll explain why there's a bit of a softer story there. Uh, to start off with the majority of agent users that we see out there today um, 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.

Speaker A: Yeah, it's going to be some cloud based vm um, in digital or whatever. Right. Like that's how it's going to be

Speaker B: And a lot of the time you know we've, 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. Um, and I kind of like it. Um, but if I'm here. Well

Speaker A: you are a Linux nerd. I mean your last company was literally a Linux based security company. So this makes sense. Jake man, we're out of time. Uh, it's great to have you back on the show talking about a new company. Uh, it's really good to have you here. Minimal uh.dev Very interesting stuff. Wish you all the best with it and I'd expect that uh, we'll be talking to you a bit uh, next year as you uh, build this out. So thanks for joining us.

Speaker B: Perfect mate. Thanks Pat, Appreciate the time.

Speaker A: That was Jake King of minimal there. Or minimal, uh.dev if you want the URL. Uh, so yeah, we'll be hearing from Jake some more next year, uh, because they're going to come on as a risky business sponsor. So that's pretty cool. So, uh, 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, uh, that might not otherwise have them. So you can think of it as like a gateway for outbound API requests, uh, that applies security controls around how API access tends to happen, uh, in the typical organization. Right. 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 like modify them or start, you know, adding sensible permission models to them. Right. So some sort of middleware like this, uh, makes a lot of sense. So here is Alex Ferguson, uh, chatting about Request Rocket and explaining what it is that it actually does enjoy.

Speaker C: The problem that Request, uh, Rocket 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. Uh, 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, um, only needs to be able to access those things that we commit them to. Uh, and the challenges we have in the industry today is that, uh, the systems that we connect to don't necessarily match our, um, expectations around the security of those connections. And so Request Rocket allows us to customize how we connect to different systems. Um, 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, um, being able to downscope and provide fine grained control over what AI can do, um, is exactly the problem that we've needed to solve for when humans build integrations and when they connect to different systems.

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

Speaker C: Yeah, sure. It might help if I walk through a bit of a story of how um, 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 ten years. Um, 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 um, a range of different uh, 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. And so the level of nuance, uh, across uh, the broad spectrum of different applications becomes problematic when you're trying to connect, 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 Request Rocket 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. Turns out that becomes quite useful when you're wanting to connect systems to bi. For example, where platforms like Power BI only have two methods of authentication that they can securely handle out of the box. So being able to translate from one to the other, uh, 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 ah, the platform has straight out of the box. But that wasn't enough for us, um, because in my story 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. Um, 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 that are white label a third party platform when they're providing services to customers. So this key, um, that the client has no control over, um, 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 uh, 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, uh, that we can configure in the platform. And so we have this deterministic uh, predicate based rule system that allows us to determine, um, down to the individual identity of the caller as to the parts of the API that they're allowed to access.

Speaker A: 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? But instead of being for like a SQL database where everything's quite structured, uh, in this case you're able to do it for an API endpoint. Yeah, for an API endpoint you can actually, 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?

Speaker C: Absolutely. Through configuration you can set up two different uh, types of scenarios. One is an authorization that if you imagine someone has a CRM, um, and you want to give one developer access to the client data and another developer access to the uh, opportunity pipeline. Um, we can provide access that is different to each individual developer or system or integration. Um, but as you mentioned, rightly so, um, that itself authorization control doesn't necessarily, um, provide the kind of level of fine grained 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 uh, again built on a predicate based uh, 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. Um, 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. And so being able to remove, if you 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. Uh, and we can also uh, remove information like their Medicare or other banking, uh, 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.

Speaker A: 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. Uh, you don't get to do that. Right. So this is a way to actually apply it to uh, some sort of sensible reduction in 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, uh, platform scoping proxy for those systems.

Speaker C: That's right. We're wrapping authorization, you know, role based access or attribute based access control around an existing system. Um, 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 being vibe coding thousands of applications into existence. Um, 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. Um, broadly API keys are all or nothing in their scope. In most cases

Speaker A: 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, uh, because of AI agents and you know,

Speaker C: and the challenge then is that there are some systems that simply can't consume an OAuth scope. Right. Um, and so when we talk about,

Speaker A: I think is the point you can,

Speaker C: 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 developer. Um, but the other aspect of it is because traffic's flowing through the platform and we're a hyperscale platform, so we work faster than most APIs beyond in production today. Um, 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 paths, patterns over time as well. And so when it comes to grc, uh,

Speaker A: touched, who touched what with what?

Speaker C: Yeah, exactly,

Speaker A: I get it. And, and, and you know what's funny is like, so many people, because I'm building a tool with some of this sort of thinking in it, it's a very different product. But, um, 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 happened, what went wrong. Exactly. Has that been your experience as well?

Speaker C: Uh, 100%. And one of the reasons we built that in is because as an integrator, I'll tell you a little story. Once you build an integration for a client, what happens next? Your fingers cross. 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, instead of searching through a week's worth of logs, we know the exact timestamp of the logs we need to go and look at to find the problem. So we are reducing the effort that's required to maintain these connections. Um, but also being able to go back and replay, well, what are the things that actually occur that led to that point. Um, you know, a month ago, I had a client who had a very similar situation. Their integration was failing. They went and had a look 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 we need to push the data into.

Speaker A: All right, well, Alex Ferguson, uh, sounds like you're off to a terrific start with it. Uh, thank you so much for joining us to walk us through Request Rocket and uh, what it is and how it works.

Speaker C: Thank you for having me on, Pat. Appreciate it.

Speaker A: 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, uh, 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, uh, blockchain threat intelligence style company. Uh, but now they are very much an all source threat intelligence play. Um, they're a serious business. They've got the backing of organizations like Goldman Sachs and Visa, uh, 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 like some sort of, you know, threat intel aggregator platform where you license a bunch of feeds and pay the monthly fee and plug them all in. Ardents is a, you know, is built on usage so you can access like this incredibly wide array of threat intelligence feeds and just pay for what you use. Um, 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 uh, Simon, join me to explain, uh, what this platform Ardents is, uh, all about. And uh, yeah, here's what he had to say. Enjoy.

Speaker D: The platform, um, 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, uh, 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 well. It's well over 100 different endpoints that this platform can call. Um, all included in one platform in one contract, importantly. So when you get an audience 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.

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

Speaker D: We think it's something pretty new, to be honest. So if you look at the threat intelligence because.

Speaker A: I'm sorry, sorry to interrupt you, 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 uh, pay per query thing. Seems I haven't heard that of that before. But I'm not in cti, so that's why I'm asking.

Speaker D: Yeah. So, uh, uh, a good comparison would be to the tip market, the threat intelligence 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. Um, 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 you're going to put all the data partners in here already. So 50 plus different data partners and then 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. 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, 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.

Speaker A: Yeah. Now you were telling me the other day, because we did a prep call, uh, before doing the interview um, you were telling me the other day that some of these queries cost basically nothing, um, 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 how do you, are you asking the AI certain questions and then it's like, hey, just so you know, this is going to cost a, a couple hundred bucks or like, is it something that can get away from the customers? I guess I'm guessing you've thought of that.

Speaker D: 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. And if you're calling a certain data source, it's not a couple of cents, it could be very expensive very quickly. Um, there's a couple of things we do, uh, both manual M 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, Darknet markets, um, other intelligence sources will turn them off. 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 will 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 will 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, you know, you've used your allotted allowance of credits for the day, maybe wait until the next day to run out.

Speaker A: Go touch some grass, fella. Exactly. Go Talk to your kids. Um, 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? Uh, 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, you know, one for this, one for this, one for this. And they got their little list of feeds. Right. So, uh, why is it advantageous then for them to have this broader data, uh, access? 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?

Speaker D: 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. Um, but it's also trying to solve that problem of the context, switching that out itself. 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. 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 source 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 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.

Speaker A: Yeah, please. I mean, we love examples. You know, walk us through them. Right,

Speaker D: yeah. And I think this, I really like this one because this is something that I have done in the past when I, you know, back in the day when I was doing CTI work myself. Um, 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 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 as broad as that. Ardents is then going to go and ask a certain number of platforms, probably things like BitSight, Flashpoint, Sockradar, ah, it'll ask all of them the same question. 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 TTDs.

Speaker A: 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 content context of what you're running necessarily, but yeah, you do.

Speaker D: Not yet, no, not

Speaker A: yet.

Speaker D: Yeah, but we're building towards that. So you'll be able to say, okay, m. Map that against my assets and tell me what's vulnerable. Um, so then you're pivoting into other data sources like maybe Overwatch or Census or something like that. And then you start going into 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 ransomware 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. And then you can look at, uh, you know, ask how, how are victims typically accessed? Is it through compromise credentials? Okay, well, let's, let's now go and look at another data source, Hudson Rock spy cloud, 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, leak credentials, mitre, ATT and CKTPs, 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 Ardents, okay, I need an executive summary for my ciso. Generate a one Page executive summary of this threat. What we should do about it.

Speaker A: What you're describing is the sort of AI, uh, ideal sort of AI workflow, just generally. But in this case you've plumbed it through to actually useful data. Right, which is, which is a step many people miss, uh, with their AI products when uh, 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 they going to be sort of more API driven versions of this?

Speaker D: 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 seam and your saw and everything else in there. So we're building towards a world where you'll be able to do a slash command Ardents 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 Ardents and Ardents to all that enrichment in the background and say, yes, this looks bad based on all these different data sources.

Speaker A: 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 um, sort of opinion that um, MCPs are just the new APIs, basically.

Speaker D: Yeah,

Speaker A: 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, like providers of, of sanctions data.

Speaker D: Sanctions is probably somewhat exotic. We've got a lot more exotic than sanctions in there. Um, sanctions. We've got a few different sanctions data providers in the sanctions. IO is one of the main ones. Um, but that's super interesting. If you get to a place where you've found a person's name in an investigation or a company name and investigation, you can just say, okay, are they on any sanctions list anyway? Yeah, they're on an Iranian sanctions list. This company. You've Never heard of. And then you can say, okay, well tell me about other directors linked to this company. So you're going well beyond the normal scope of a CTI investigation. And then when you get into the, you know, 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 so I haven't got any money sanctions feeds.

Speaker A: Can you think of another exotic, uh, example of an exotic data source, something that people just wouldn't think about?

Speaker D: 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, uh, in the world. And again, typically ransomware investigation is a really good example. But um, if you got to a point where you wanted to know more about 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. Are they still, are there transactions coming in and out of that wallet? Um, and then tell me about exchanges that are linked to these transactions. You can start looking at where is the money going, start following the money. And more and more of uh, 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, almost a bit of a black box. And we've sort of removed the barrier to entry to doing that investigation because Ardents 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 you want to investigate? And maybe you want to look for cash out points as well and it will sort of hold your hand. So if you've never done a crypto investigation before, Ardents will point you in the right direction. You can just say, okay, that sounds good. Run, run that step for me. Me.

Speaker A: I, 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. Um, Simon Warren, this is very interesting stuff. Ardent, uh, from TRM Labs. Thank you very much for uh, joining me to uh, walk uh, me and the audience through it, uh, very interesting stuff. Thanks for your time.

Speaker D: Thanks, Patrick.

Speaker A: That was Simon Warren of TRM Labs rounding out this edition of the Snake Oilers podcast. Big thanks to to him for that. And big thanks to TRM for sponsoring, uh, a Snake Oilers slot. And that is it, uh, 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.