Insecure Agents — Episode 53: Luke Hinds, Founder of nolabs and creator of Sigstore Podcast: https://insecureagents.com Listen: https://open.spotify.com/episode/65YVqcYLSEq9AMHhmzOmBq Transcript (auto-generated, lightly edited for clarity). Allie Howe: All right. Welcome to today's episode of the Insecure Agents podcast. I'm your host, Allie Howe, and I'm super excited to have Luke Hinds on today. Luke is the founder of Nolabs and has spent his career on open source security infrastructure. Luke is also the creator of Sigstore, the industry transforming software supply chain, and now AI/ML model security project, protecting billions of software artifacts worldwide. Now he's working on Nolabs to give agents enforceable boundaries at the kernel level. Luke, would you like to introduce yourself? Luke Hinds: Yeah, and thank you for having me, Allie. It's really good to be here. As you said name is Luke Hinds. Always been a software engineer, predominantly worked in open source. I was at a few different companies over the years, but I guess Red Hat was one where I got to get my hands on a lot of open source code. And, I've worked in all areas of the stack really, originally the kernel, and some of the hardware stuff. Like some of the security folks will know trusted execution environments, trusted platform modules, all this kind of silicon-based trust and kind of cryptography, Sigstore. That was a kind of a big project. That was one of the ones where you try this enough times, eventually one's gonna stick, you know. And, and so that was one that certainly stuck. And started looking at agents and AI about a couple of years ago. And, so we're having a lot of fun at Nolabs now. We're building Nono. And, I'm a fan of the show. I watched a few episodes and so yeah. Yeah, thanks for having me. Allie Howe: Awesome. Yeah, super excited to have you here and super excited to have all your expertise and security open source software here with us today. I'd love to, before I-- You know, super excited to chat about NoNo today, of course. But would love to touch on Sigstore as well 'cause that s- was so successful. It's really impressive that that's now protecting billions of artifacts and has moved into the AI model signing world. Can you tell us more about Sigstore? Luke Hinds: Absolutely, yeah. So Sigstore's initial problem, okay, its, its sort of targeted area to solve was cryptographic signing of artifacts. So an artifact could constitute a, a binary, a container image, an AI model, essentially any chunk of bits that can be signed. Okay, and what I mean by signing, so signing you'll have some cryptographic... I mean, this is-- obviously this is a lot of folks are ent- identity-based that'll be watching this, but just to kind of get everybody on a, a level playing field, we're talking about key cryptography, a key pair, private key, public key, and you're able to attest and have non-repudiation that the source giving you an artifact has effectively signed that so that you know it's not being tampered with in transit, and you've got guarantees of who it came from, as long as that person's not lost their key. Okay? And we looked at the software supply chain. It's huge. So you've got all of the package managers, PyPi, npm, Crates, et cetera, et cetera, and none of them were able to get cryptographic signing off the ground, and it gives you a lot of guarantees around security. So we looked at why that was and came up with the idea of Sigstore. So I, I was, like I said, I was originally working at Red Hat at the time. The CTO there said, "Is there anything we can do in this area?" 'Cause it's it was causing a lot of pain. I mean, like about five years ago, it was, it was the cool kid on the block. Everybody was talking about software supply chain security. And so I thought about this for a while, and I, I kind of really, I guess, you know, you always stand on the shoulders of giants, and I looked around and I thought, "What's worked before?" 'Cause, 'cause getting developers to adopt security is really not easy. Okay? I mean, they, if kind of like asked in a crowd, they'll say, "Yes, absolutely. It's really important." But there's all these productivity boosts and kind of, you know, shiny things that are getting your attention that are gonna make you move faster and the latest framework, the latest sort of, protocols. So security is generally, it's cumbersome. It tells you no all the time. It's frustrating. It breaks your code. People generally don't flock to it. So I've, I realized really this will live and die on the user experience, and the old cryptographic technology, GPG- I wanna speak fondly of it. It's like, you know, kinda you don't wanna speak bad about your grandfather. It's, you know, it was wonderful for the time, but it was very brittle. It couldn't adjust to kind of the new distributed world that we lived in. So I got a lot of inspiration from Let's Encrypt, okay? And folks will know Let's Encrypt from HTTPS and, you know, they were effectively able to disrupt a, an industry that was very cumbersome. Ex- there was, you know, there was an expense involved. If you wanted to get a HTTPS certificate, you'd have to go to a provider, give them a copy of your driving license, have a credit card. They would send you a bundle of certificates, and then you'd be spent, like there's no AI agent, so you'd spend two days thinking, "How do I get this to work in Apache?" You know, eventually you would get it working, and it was a really not a nice experience. And Let's Encrypt came along and they said, "We're gonna make it free, as in beer, and you just run something and it'll run on a cron job, and you just never need to worry about it again." And then what happened was the adoption or the proliferation of HTTPS just went through the roof. So we went from like 30% of sites to something like 90, 97% were then running secure certificates. And that meant, that meant the browsers could then eventually ring-fence around, kind of circle the wagons around people not running HTTPS. So you'd visit a, a blog that would be on HTTP and it would kind of feel a little bit icky, like, am I gonna get a virus here? You know, the browser would warn you with all these red You know, stay away, there may be dragons, it's dangerous. And it made it socially unacceptable to run HTTP really, you know? And I thought it, it'd be wonderful to do that for software. We get it to the point where software, to accept software where there's no credible attestation and provenance should feel a little bit icky really. And, and so that's where Sigstore was kinda based on, on, on that idea really. And we realized it had to be something that developers would like. So we started with the CLI, really simple CLI ergonomics and trying to keep as much of the hard work in the infrastructure, in the actual services hidden away from the developer. And it took a while to get it cracked, you know. I spent quite a while speaking to people 'cause, you know, we had all these technologies like a transparency log and a, which is kind of like an immutable ledger, and I was trying to socialize this idea with other people, and I think they were just... they just didn't get it. They're thinking, "What's this guy going on about?" You know. You know when you're talking to somebody and you know their eyes are going over to Slack 'cause that's more interesting than this nonsense that you're rambling on about, you know. But eventually I think really when we started to show the user experience, it really started to take off and, and we got a lot of traction with containers initially. There's a, a guy came into the community called Dan Lawrence. He went on to create s- Chainguard, he's the CEO of Chainguard, and he wrote this really cool CLI called Cosign for signing containers. And then suddenly GitHub rigged us into their actions, and we became a default action, which was crazy 'cause suddenly like there was just thousands and thousands of requests going through the system, which we weren't quite ready for at the time. And it just went on and on from there. You know, eventually Google got involved, and it's now found a second wind with model provenance. So the idea is that you have component parts that are part, you know, a model has a data set, weights, training parameters. Can you have guarantees around the provenance of those? So you can understand by looking at a model what was the supply chain behind that model effectively. And, yeah, and, and so, you know, that was the big learning from Sigstore really was, you know, it has to be a good developer experience. They've gotta understand the value very quickly, and then you've gotta be out the way after that. And I, and I think that's why we're getting some traction with NoNo 'cause we managed to sorta replicate that special sauce again really. Allie Howe: Yes. Amazing. You know, I totally agree with that, that in order for, you know, developers to adopt security, there has to be some sort of win for them beyond just security, like productivity gains making that super easy for them to hopefully that super important and very cool that you were able to do that with both Sigstore and now with Nono. How are developers seeing that win with Nono? 'Cause it's really interesting for the folks maybe that aren't familiar with Nono. Nono helps you add policy around what your, like, coding agent can and can't do in, in terms of, like, what folders and files it's able to access, and I'm sure, like, please expand on that, Luke, the explanation of Nono given that you, you're the one that founded it. But, super interesting to think about the wins that they're seeing. Why would a developer come seek out Nono? What's in it for them beyond security? Luke Hinds: Very good question. Okay. And security is the main payload. That's the main feature set, so I'll def- definitely base it around security. And so here I think people actually wanna do security, okay? They, they definitely do. You know, people are aware of agents, that things can go a little bit squirrely around your data and the access. They can be a little bit wayward, un- unconstrained, uncontrollable. And so people are naturally concerned. But there's this, always this, this kind of battle between the amount of time that you invest in something and the value that it unlocks for you, okay? And I think that's a key... It's a re- real key ground. If you're a security developer that wants to get traction in developer tools, you've really gotta be aware of that. And so with Nono, we made it so that you didn't have to install any namespaces or runtimes or hypervisors. You just download a binary, you run it, and then it immediately sandboxes a process. So whatever you put on the end of the command, whether that be Claude or it be Python main.py, or it be even htop or curl or LS, they're all processes. It's all Unix primitives. So we effectively just wrap a process into a sandbox. So it's a very sort of familiar CLI, I guess, ergonomics, if that's the right word. It's nono run. We have a nono PS to see them running. So it's, it's kind of quite Docker-esque, okay? And so most people will start with just a couple of flags. You know, they'll do nono run, profile Claude. We will then pull in all the files that are needed for Claude policy And then they're enclosed, and they can't see NoNo. You, you forget NoNo's even there until something is denied. Okay? And what will happen is the, the sandbox will inject some context back to the model saying, "No, you can't do that because of this, this, and this." And then obviously models, when they get some context, they are able to articulate with that as reference. So you get that magic where the model... Sorry, the agent will say, "I, I can't do that. No- NoNo's blocked me. But if you need to allow NoNo to do this, you can grant it this extra permission." And and so yeah, really it's again, it's that sort of simple, very easy to get going very quick really. You know, y- you've got like a, a 10-second, 20-second window to, to really kind of capture people and get them in, you know? I always kind of compare it to you can look at a toothbrush, okay? The value and the, you know, the, the, the value that's derived and the cost is hardly anything at all. Okay, right. Let me reword that. I should start that again. A toothbrush costs you a buck, okay? You put it in your mouth, you move it around, and your teeth don't fall out. Why wouldn't you do that really? You know, it's really not complex. Then you've got something like solar panels. Pretty complex to install. I couldn't do it. I'd make a total mess of it. But then if you do do it, you get free energy. Free, you know, you're not paying money for electricity. So there's a big value there. So even though there's a cost to adopt, the value that is released is, is really tangible. Now, I think a lot of security tools, it's very, you know, there's a lot of friction to learn them, to onboard with them, and then the value is at some point in the future, something bad may happen, and then you're pleased to have us there, but we cannot guarantee it. Okay? So then it becomes a little bit like motor insurance. Everybody gets it because they have to. And then when they, when the car does have a, a kind of a dent, you know, like the Walmart trol- trolley goes into it or somebody goes into the back of you, you're happy you got your insurance. But nobody thinks, "Oh, yes, one week and I get to renew my car insurance. I cannot wait." Do you see what I mean? It's, you know... And so that's what you face as somebody developing security tools and, and I'm kind of sharing all this because I, I figure a lot of security developers are, you know, will be watching this, and it's been my, my kind of core learning experience. So again, with Nono we meet people with a very simple entry. Get them going, okay? And then from there, they can start to go deeper. They can start to construct their own policy, okay? And they tend to start off with a single ta- tool sandbox. Sorry, a single sandbox for the agent. But then it's discovered that we actually do isolation. We do these micro sandboxes for every tool execution. So the agent tries to run a core util CLI tool like the GitHub CLI. They love grabbing hold of that to look at PRs and issues. We can spawn that within its own isolated sandbox, where only that tool gets the use of the GitHub token, not the entire agent surface. And so then they realize, right, I can start to build logic around a particular tool, and then they, they go deeper and deeper, you know. And, and then eventually they'll get to the point where they'll go, "Well, we need to run this on Kubernetes." And then you've got a nice lift and shift, because you've already carved out your policy. You've got things how you want. And so Nono Run becomes like an entry point in a Docker file. Same sort of thing. And then your agent's running on Kubernetes or, or, or some sort of infrastructure environment. So yeah, it was really designed around, you know, what is gonna work for d- for developer adoption here? And I, and I think, you know, that the advantage that we had there is we're all developers that happened to run a lot of security over the years, you know. And, and so I think that's, that's one of the things that's definitely helped Nono get some, some traction. Allie Howe: Yes, definitely. 'Cause I imagine that engineers that are able to, you know, go to leadership and say, you know, "Here's the security guarantees that I have now because of, of NoNo so we can feel more comfortable shipping this agent into production 'cause we have some boundaries around the agent when it takes an action maybe it's not supposed to because of a prompt injection or who knows what," that there is something in the way of s- of stopping it, either because, you know, we've got something in a sandbox and also just because what it, what it sounds like also is with these different tool sandboxes that maybe that particular sandbox that you said there was the, the example with GitHub, if it's the GitHub one, it's not gonna be able to request a token for some other tool, only for GitHub. And that helps a lot as well. Luke Hinds: Absolutely. And, that's a, that's a really good point to raise 'cause one of the I guess, differentiators or differences with NoNo as a sandbox, 'cause we've got this category sandbox and there's, there's several different types in there. There's a kinda like serverless one where you, you kind of have code which is loaded into a function, goes up to the cloud, executes, okay? There is a microVM, which is a full virtual machine, okay? Like Firecracker, gVisor. You got Docker containers. That's another type of isolation. And we're actually doing something different. We're doing something that we call fine-grain capability-based sandboxing, okay? So we don't claim to be as absolute solid as a microVM around escaping to the host. You know, they're very well-purposed for multi-tenant scenarios. What we do is we provide sandboxing in the operating context of the agent, okay? So our thinking is that a microVM solves a really good problem, solved it very well. I'm a huge fan. But you, it's, you can't just lock an agent in a box. You need to delegate some authority to it. It needs to be able to access APIs. To do that, it needs some credentials. It needs to work with sensitive files. It needs to run powerful commands. So we're providing that very fine-grain sandboxing at the point of execution, which is where we are different, not better, but we're very different to a microVM, which I c- I almost don't really think of as an agent sandbox. I think of it as a host isolation solution, which is a very important technology to have in the stack, but it's about protecting the host from the guest and tenants from adjacent tenants. Should untrusted code execute that is malicious, it's contained, it's locked in a box, you know? And so we've really built this around the agent. What can the agent, what is it capable of doing? We know these things are incredibly smart. We've seen that with the OpenAI Hugging Face attack. How do we secure agents that are free-roaming on systems where there are There's suites for them to pick everywhere, essentially, you know? H-h-how do we do that? How do we set up least privilege, zero trust within an operating context? And that's our real focus at NoNo. So, you know, if anybody's kinda like trying to evaluate sandboxes, I, I'd say those are the kind of three main ones at the moment. Your kind of serverless one, your kind of host isolation microVM, and then really what we do with NoNo, which is kind of a, a new category in many ways, you know? But we don't have a name, and I'm really bad at names, so yeah, yeah. Allie Howe: Yeah. Na-naming is surprisingly very difficult. But no, that's a-... fantastic overview of the different types of sandboxes, and something I was going to ask you as well-... just 'cause I'm generally curious about that to see, like, how the space is evolving. 'cause the past guests that I have on, have had on have said to me that microVMs are one of the strongest, like, sandboxes you can have because then you're not, like, sharing a kernel with, with another individual. And so if, like, their agent-... gets compromised, it's not going to affect yours. Of course, if you've got like a, a kernel vulnerability, then you're in, in trouble per se. But- Yeah... that's one of the stronger VMs that you can get access to. It- Exactly... yeah, it was super interesting to, like, read-... on your site. I love, like, the transparency-... around like, "Hey, like, here's the security guarantees you get with, like, running NoNo alone," but then also you can pair it with a microVM. So you can do both. Luke Hinds: Absolutely. Absolutely, yeah, yeah, very much. They, they, they compose very well together, you know, 'cause it, different threat models. It really is different threat models. A, a microVM, like I say, it's around containing bad things that explode, okay? If anything is a payload, a malicious payload, code is executed, that is contained, okay? We're really always, you know... O-our threat model, the actor is not necessarily malicious, and everybody's gonna understand this when I say this. You've all seen this thing where, "What did you do? You d- you've deleted my database." "Oh, I'm incredibly sorry. I, I really didn't mean to do that. I will..." You know, and, and it will start scolding itself, you know, and kinda writing to its memory, "I, I, I shouldn't do that." And it will do it again, invariably. But they're so smart and, you know, and, and, and that is a threat. That is a security risk, you know, 'cause data exfiltration, compromise, all of these sorts of attack vectors are surfaced. But it's very different to pure isolation. You know, I always kinda use the example of Consider like a state penitentiary, okay? You have some, like, high-level security prisoners. You can't just leave them in the cell. They need to kinda come out and telephone their relatives, go around the exercise yard, and go into the canteen, okay? So you have to kinda make sure that when they are walking to the canteen and they're coming down the staircase and they're going out to the exercise yard, you need to plan around those situations. You can't do that if they just stay in the cell, okay? So we're, we're really doing that, you know. We're, we're trying to... It's, it's a bit like, you know, when somebody young flies the nest, goes to university, they're gonna get their first car, they're gonna... You know, there's lots of risks introduced. You can't just say, "Well, no. You're gonna have to just stay home." So you start to plan out what is the safe path, what is the kind of, you know, the preparations that we have in place there. And that's really where it is something very different. Not better, it's just, you know, microVMs solved a particular problem very well. But They're not solving all the problems that agents introduce, really. You know, and, and I'll put out a desk somewhere with a white banner and, and argue that if I have to, you know? Allie Howe: Yes. No, absolutely. Yeah, I, I agree with that for sure. So yeah, I feel like there's more to agents than just containing, like, a, a bound piece of code per se, because they, they need the autonomy and the capability to call- Ab- absolutely inside that you didn't project when you created it, and that's, that's really the power of the agent. So if you take that away, then you lose sort of the whole thing you set out to do in the, in the first place. And so we're left with this problem of like, okay, we can't predict everything it's going to do, every action, everything it's going to need to access, every tool and resource, so how do we give it the security or the authorization, the policies, the identity, such that we can make decisions at runtime around what this agent is or is not allowed to do? Luke Hinds: Exactly, yeah. And, and we firmly believe that has to happen in the runtime. It can't really be on the endpoint, you know, the, the periphery of the network. Or it's really gotta be where the rubber hits the road. And there's, of course, I know you're gonna get onto this, I don't wanna kind of preemptively take away your points, but there's just a really lovely combined story with identity here, really, you know? Which is accountability contingent upon identity, you know, which I'm sure we'll chat about a bit later. Allie Howe: Yeah. Yeah. No, for sure. Yeah. Happy to jump into that 'cause I definitely feel like identity is a big part of this conversation as well. Because you get that extra context around like, you know, who authorized or is, was trying to get this agent to perform this task. And based on-... their permissions and also the permissions of the agent, should this action be allowed to go through at runtime? How do you see NoNo as part of that solution, or how do you see it interacting with identity? Luke Hinds: Yeah, absolutely. Yeah. So, so in several key areas, I think as a, as a, as a primitive, NoNo is able to capture a really good black box recording of everything that happened. 'Cause we've got this low-level syscall-based tracing of all of these commands that execute. We generate a, like an immutable ledger. It's a Merkle tree. I'm always playing around with Merkle trees, same as Sigstore. And we actually build this Merkle tree of all the total executions, so the environment variables, the full path to the binary, the SHA256 all of the d- the domains that we'll call, the L7 paths. There's just so much information in there. We capture all of that around a single tool execution. And we write this outside of the sandbox. So again, using good old Unix technology. With NoNo, we first of all create a process which spawns another process, and that process is sandboxed. So you have this process, which is like the parent- And that is able to intercept all of the tool calls, file operations. And this is all inter-process communication. It's nothing that I invented. It's all kind of stuff that's been in the Unix kernel for, for many, many years. And so having this adjacent process supervisor, we are able to write all of these actions, this kind of audit log outside of the sandbox, so the agent cannot tamper with that What we're also able to do is within Nono, we do so much more than sandboxing as well. We have a, a whole sort of credential system where you can inject tokens, secrets, but they are phantom, they're not the real ones. So the agent can't even get its hands on a real token. When the agent posts a request, for example, we'll flip it out to the real one, again, using this process which is outside of the sandbox, and that process will actually integrate with a key management solution. So like on a engineer's laptop, it could be Keychain or it could be a, like a Kubernetes secret or one password or Bitwarden, possibly in time a YubiKey, HashiCorp Vault. You get the idea. And one of the ones that we've been exploring is there's a Spiffe, SPIRE workload identity that we recently did a, like a, some of our folks showed that off on, on a webinar. And of course starting to look at very early, but looking at AAuth and the stuff that Dirk's doing, that's incredibly interesting. And so really, you know, at present, we're able to mint an identity into that audit log and then have the kind of cryptographic foundation so that you know that that is tamper-resistant. It's not been, it's not been-- The agent hasn't tried to cover up activity. You've got that kind of black box record of everything that's happened. And I think from here it gets really interesting around the kind of the scope of an action and then how that ties to an identity. So you have an i-, you know, typically a, some sort of authorization system will have a concept of scopes. These could be actions that that agent is allowed to perform, and I would love to marry that to the runtime effectively so that we can... Everything that that scope specifies is absolutely cast iron guaranteed at runtime. So, you know, that would be really interesting. And, and I've always been really interested in agent delegation as well, kind of time-based sub-scoping to different agents to perform different tasks and, and how can we do that with Nono? And I think Nono is well positioned here because it's a very sort of a very fast zero latency, very adaptable process wrapper really, you know. So, but you know, the, the kinda second half of what I was talking about, that's, that's a little bit more kind of a yet to build, yet to figure out type stuff, so. But I, I, you know, I- really interested in seeing how that plays out. Allie Howe: Yes, absolutely. And there's-- The, that space is evolving so quickly, and- Yeah... I'm sure you saw we had Dick Hardt on the, on the podcast before. Yeah. We did a deep dive with Dick, and really excited about what's going on there with AAuth. But I feel like, yeah, the context you get from that is, is so powerful around here's our cryptographic identity for the agent, and then also here's the agent's mission-... which allows you to sort of do a diff around, okay, this is what it set out to do originally, and this is what it wants to do now. Like, does this make sense? So I feel like that will definitely, that context will be so powerful for runtime security tools. Luke Hinds: Absolutely. Yeah, yeah. It's it's essential as well, really, to have that credible record of what has happened. You know, it's you look at, like I say, last week or maybe two weeks ago, you know, they've been doing the, the postmortem, but the whole Hugging Face and OpenAI, incredibly complex attack. And the Hugging Face folks have done brilliant. Their write-up is just fantastic, you know. But the more of a credible, immutable, trust implicit record that you have, the better. You know, you-- It's it's really important understanding what's gone wrong. Allie Howe: Yes. Yeah. Absolutely. No, for sure. I think that's a very real highlight in the Hugging Face incident. -... would love to chat more about that. Obviously, like, a agent escaped its, its sandbox to be able to take part in that attack. Could Nono have helped prevent the Hugging Face incident, or what, what's your take on that? Luke Hinds: Yes, it, it's an interesting one. Now, it would, but I'm saying that retrospectively, so I'm basing that on an attack that's happened, okay? So preemptively knowing all of the nuances that can happen in a com- an attack as complex as this that's a different, that's another matter. I mean, security vendors are notorious for ambulance chasing and saying, "Oh, if you used, you know, kind of widget X, this would never have happened." But it's, you know, it's... But, but we would have to a degree with this full sandboxing, okay? So one of the, you know, I'm still sort of trying to lodge into the memory the actual specifics of the attack, but it was compiling C code constantly on the fly, from what I understand. And we are able to gate S- C Clang, all of these sort of C compilers really limit their access, you know, completely shut down many, many components. So you can really set sort of a zero trust privilege-based confinement around them. But then you would've had to have done that first. You would've had to have understand that this is a threat, and then you would've needed to have put the policy in place, okay? And, so, so I wouldn't want to... It's easy for, for me to say, it's easy for everybody to say after an attack, "Oh, you know, why didn't they think of that? Why didn't they do this?" You know. But you never know how these things are gonna unfold, and I, I'm just astounded. It's just reading about this, it's just incredible, you know. And I think another thing a- around the, the sandbox, an interesting aspect here, okay, is so it was modal, okay? And, any of you guys listening, I'm about to stick up for you, you know. They have again, a different type of sandbox. It's like a, a serverless. Effectively, you sort of execute code. And the the agent somehow, there was a customer system which, which was not set up properly, and so the agent effectively got root on the execution of these sandboxes. And so it was able to use that as a execution point to launch out to another attack. So it kinda did escape a ca- a sandbox, but it kinda had like the master key or a Swiss Army knife, you know, and, and like the world's knowledge of locks in its head really. So, so when people say it escaped a sandbox, it didn't a sandbox is only as strong as the access that you grant to it. Do you see what I mean? It's, you know, like we always say when, when when we do due diligence or postmortem on an attack, I, you know, I've, I've, I've worked around sort of vulnerability management for quite a while. Used to be on the, the security response team for Kubernetes, like we ran the bug bounty program. And then as soon as you read something, it was like the attack that the repro was sudo to root or login as root. It's like, well, ch- you know, you've got root. Do you, you, you own the, the world. Do you see what I mean? So saying that there's a sandbox escape when somebody's literally got the keys to the kingdom, it's sort of, it's not really part of the security model of a sandbox, you know? It assumes that these things are protected and looked after, so yeah. But fascinating attack. I mean, like, just, it was just like for three, four days, just constantly writing code and compiling and deploying and compiling and deploying and spawning VPN connections over and over and over, and it just fascinating and, and, and scary. Really absolutely scary, you know? Yeah. Allie Howe: Yes. Exactly. And yeah, that's a good point to touch on the fact that, you know, the wording around like it escaped the sandbox. So it had the access and the credentials to be able to do that in the first place, so it's only as strong as you make it. Which kind of aligns with something in the postmortem that said like, you know, don't-- They said, "Don't prioritize or solely rely on external controls such as a sandbox." Which I think circles back to our original conversation around like-... you know, like identity, authorization, extra context from like maybe like AAuth in for, in, for example. Like this all is so layered- Absolutely... and there's no one solution. Luke Hinds: Absolutely. Defense in depth- Yeah... is what we've called it for years, you know? And, and we learnt this going back t- to the military. You know, if you had like some sort of little kind of, area where your platoon was, you set up layers of traps. You know, you didn't just rely on one. You had defense in depth, and it's exactly the same principle. You know, this is all stuff that we've, we've known about for years, absolutely. Allie Howe: Yeah, very much. Yeah, it's really interesting to see it all come together now in terms of not only just like, you know, new technologies, but things that we've had before that we're repurposing, like, you know, software verification comes to mind. 'cause we're thinking about like a hot topic right now that was featured heavily at AI Engineer World's Fair earlier this year, is this concept of like software factories and how do we enable coding agents to safely and securely ship code with as little of our involvement as possible. But in order to do that, we have to circle back to, you know, software verification. You know, you know, Sigstore comes to mind. We also need like i-identity for coding agents to be able to say, "Okay, like, you know, this person authorized this agent to like approve this PR," or, you know, there was a comment in this thread that said there were people who were really gonna be introduced, like, "This is the agent, this is the person that said, 'Hey, this is okay. I wanna merge this anyway.'" We need that audit trail like you talked about. We also need like sandboxes as well to make sure that different areas of the agent, different tools are contained, like you talked about. -... so, so much of this is, is coming together at once. Like, what's your take on, sort of like the future, how all of this involves, how all of this all comes together to enable a-to autonomous software factory? That, that's the long-term goal. Luke Hinds: Yeah, really good question. And, you know, my, my view changes weekly really- Yeah... you know, as more is revealed, you know. And, but I, I think you touched upon it really, which is, you know, the, the-there's some fundamental principles that should be at the heart of it. If we're talking about security, you know, zero trust, constrained execution, isolation accountability, transparency, tied to identity a- you know, agent identity is, is obviously that sounds like an obvious thing to say, but, you know, if, if we look at how we work at the moment, we've got GitHub. You know, there's like a user avatar and, you know, it-- but it's typically an agent that's behind this, you know. So, so we know that there is a whole load of rethinking that needs to happen there, you know. And I, I wasn't part of the conversation, but I'd have loved to have been around the software factory and y- yeah. Yeah, all of what we've discussed really is, is just a good starting ground, you know? And, and yeah, you said it well, defense in depth. You know, never let perfect be the enemy of good. If there's a small change you can make to make things harder for an attacker or a wayward agent, then you do that effectively. And, yeah, you know, I think it's all out there really. All the tech is out there, it's just about bringing it together and and purposing it for this actual new threat paradigm that we have. And I think one of the things with security, perhaps not so much the identity folks, well, perhaps in some ways with some of the older authentication protocols, but certainly within a lot of the runtime security and endpoint and, and, you know, DPI, all these sorts of technologies, they're retrofitting old security technology to a new threat, which is, it's just it's fighting a new war with old weapons, you know? And, I, I know the identity folks went through this. I'm always careful when I say this 'cause, 'cause someone'll come after me, but luckily Dirk will back me up. Now, OAuth 2.0, you know, we knew that that just was not cutting the mustard really for agents, you know? And that, and that's fine. That's okay. Technology evolves, you know? But there was obviously, you know, that was a, was a is a very, very deeply ingrained protocol that's been around for many years and has had a lot of retrofitting to apply to different new stacks and paradigms that have happened in compute. So yeah, you know, we, we, there's a lot that we can use there, but, but we can't just sort of duct tape stuff on, you know? And, and we need to sort of, really rethink things, you know? And, it's gonna be busy. We're gonna be very, very busy, you know, because this goes-- I mean, you can take this down so many layers really. I mean, computing as a paradigm and agents. I always just find it incredible that we have agents that will require on technology that was made for like lumps of jelly, optical eyes, like a browser. So you've got this thing going, taking a screenshot of a browser to then chunk that down into tokens Because it's working with a technology that was made for like biological entities like us, you know, like a keyboard, like lumps of flesh hammering plastic buttons. And so th- all of that's gonna be disrupted as well. Do you see what I mean? So who knows? Do you know what? I think if anybody says they know what the future looks like, they're just, they're lying, you know? Yeah, don't trust them with your car keys really, you know, 'cause it's... The whole thing's gonna be it's just gonna be constant disruption, I think, really, you know? And, yeah, and I, I mean, we've seen that happen so much really, you know, where AI's first started. I s- I always speak about the, the great squashing it. Do you mind if I kind of unfold that? Allie Howe: Sure, yeah. Yeah, yeah. I was actually really interested to, like, m- maybe, like, after this, like, really interested to touch on, like- Yeah if the future's evolving so quickly and, like, no one can predict it, like, how do you know where to in- invest in terms of like, if you're a security practitioner, if you're a CISO, like, what tooling do you invest in? What do you say, "Okay, this is the thing that's gonna be, like, around or, like, long enough," or, "This is the thing that, like, I feel confident is, like, worth my time and energy to adopt. It's gonna really move the needle in terms of my security posture." Like, what are those, like, one, two, or three things? Luke Hinds: I think really, okay, so, so the stack. Are you, are you locked in in any way, okay? With, with, you know, the current tech stacks that are around or agent harnesses, you know. Have you got that ability to kind of float above these things? I think that's, that, that's definitely a good first step to have in place before you worry about what the future's gonna look like. You know, coding harnesses change very quickly. You know, I mean, we've had consistently pretty much Claude and Codex kind of battling it out at the front. But if you look at the sort of personal assistant-type agents, there's been OpenClau and then Hermes, and there's a flavor of the month. Yeah. You know? It's, it's changing all the time really. And so I would say really don't lock into any particular ecosystem too much. If, if you can abstract, you know, effectively try to make your application and not be tied too much to the current trend is a good place to start. That's one of the things that we did with NoNo from the beginning. We didn't wanna become deeply ingrained into some coding harnesses concept or hooks and then be totally reliant upon that because, you know, these, these things change really. So I think that's a good place to start. And like we said earlier, you know, we, we always had these kind of fundamentals, these primitives, like we spoke about, you know, transparency, zero trust, defense in depth. These things will persist. Allie Howe: Absolutely, yeah. Absolutely. No, I agree. That's a good point. I, I derailed you. What did you wanna get into before? Do you remember? Luke Hinds: Oh, the squashing in. Yeah. So this is another one that, that kind of caused a lot of people to come after me. So you know, originally when AI really lifted off, okay, all of us builders, software engineers that are building stacks for ages, we started to kind of build a lot of trappings and skeletons and frameworks around AI, okay? And, and that sort of made sense. And I think initially it was the agent frameworks, okay? And then- Effectively, it became obvious that AI models, large language models, love to engage directly with a service. Okay. So they don't always wanna go via a function, set parameters, you know. They, they, they, they like kind of going direct if they can. So we then started to build MCP, Model Context Protocol. Okay. So it introduced lots of structure and spec and, you know, kind of formalize everything, and everything is mandatory and, and then, you know... So I, I can't speak for Anthropic here, I've gotta be careful, but you know, they're obviously the folks that launched that. But then I think there was a realization that actually if, if you get all that out the way and you let the agent just get its hands on the operating system, it's very good. They are very, very good, you know? And so there's this realization of like, eek, this is interesting, you know? If you remove this, then the agent is, is, it, it, it can roam and it can discover and it can find novel approaches to problems. You know, that's where the, the magic started to really happen. And, the, the kind of the squashing in was just squashing all that down to a skill file effectively, you know, a piece of markdown But who would have thought Markdown would be something that would be so important, you know, going back five, 10 years ago, you know? So five, 10 years from now who knows really, you know? Allie Howe: Yeah. Yeah. So true. Yes, absolutely. If folks want to try NoNo, where's the best place to go for that today? Luke Hinds: I would go to nono.sh. On there, you'll see there's a, a quick start, couple of commands when you get going, and and from there you can kind of go deeper into the docs. We've got a Discord that you can join, come in, you know, friendly group, always willing to help each other out. Lots of discussion going on there. And you know what? The one thing with NoNo, like I said at the beginning, is it predominantly used a lot for coding agents, 'cause coding agents are the kind of, I guess, as closest as what we've had to a killer application with AI around sort of utilization, leverage, adoption, wide usage. But you can run anything in NoNo effectively. You know, you could have developed your own agent. You might have you may have written something in Pydantic AI or LangChain or s-some framework, and that will run in NoNo. And then for free, you'll get all of the audit that we spoke about. You can plug in identity, you get credential injection. We even have software supply chain security and there's sigstores in there. Oh. So we, so when the agent accesses a skill file, we sense the sys call come in, and then we tie the provenance all the way back to the source of origin, so that way you can guarantee that skill files are minted from a particular GitHub organization or a particular commit SHA effectively. So, so yeah, there's a lot more in NoNo. We started off as a sandbox, and that was important to have that kind of ground zero primitive source of truth to build on top of. But we do so much more than sandboxing now. There's there's a lot of really interesting features in there. Allie Howe: Interesting. Yeah. Very cool. Yeah, I feel like-... developers would definitely be interested to check that out and seems, like, very helpful. And also seems like it's a good way to incorporate multiple different layers at, at once, like the software verification, the sandboxing, how we talked about it, it's, it's layered. It's really interesting that you're, you know, building NoNo in that way to be layered as well. I'm so excited for folks to check that out, and it'll be interesting to also just, like, continue to monitor the space with you and see how it evolves. And, like we said, the future's changing so rapidly, and it'll be interesting to continue to follow all the amazing work that you're doing. -. And yeah, thank you so much for coming on the show today. I really appreciate it. And then last question is, where can people connect with you if they want to continue the conversation? Luke Hinds: Yeah. So, li-like I said, nono.sh is a good entry point. You can get into our Discord from there. I have, like, a really old handle, decodebytes, which I think I've got on Blue Sky and- and, and X and LinkedIn, sort of typical places really. You know, I leave a pretty good paper trail around so people can normally find me. And my GitHub is Luke Hinds as well. You can find a lot from there really, you know. And o- of course, Know Labs, knowlabs.ai. So come and check us out. We've, we built KnowKnow. We are now building the enterprise scale orchestration control plane on top of that effectively. So you could look at like KnowKnow like Docker. We're building the Kubernetes to sit on top of that now, so. Allie Howe: Excellent. Yeah. Amazing. Well, thank you so much. And we'll catch you next time. Yeah. Thanks, Luke. Luke Hinds: Thank you. Bye-bye.