Bret: this episode couldn't be more timely because it just days
ago, like maybe two, two days after this episode was recorded, we heard
about the HuggingFace hack by OpenAI
on both ends of the spectrum, we're gonna need some sandboxing
and locking of this stuff down.
This episode is about agent sandboxes, or just sandboxing, sandboxing anything.
Hell, we've for 30 years have had sandboxing technologies that we could
label as a sandbox-type thing with jails and Chroot and Docker and VMs.
Like these are all isolation technologies, namespaces, cgroups, you name it.
There's been a dozen or more attempts over the last 30 years, and now we are
focused on agents and AI running amok on our local systems, but that's not enough.
This is about sandboxing, specifically with nono.
You can find it at nono.sh.
It's by nolabs, and I had the founder, Luke Hinds on the show, where we
went long on this one, and that's because there's a part of it where
we talk about nono, how it works.
It's a command line that you can wrap any binary on Mac or Linux.
On Windows, you would use WSL2 to run nono.
But it runs against the kernel primitives.
So unlike many other ideas around isolation technology that use VMs or
containers or both, this is focused on just using the native functionality
of the kernel and giving you a profile for each thing you wanna run in it,
You can use it for everything.
You can use it for kubectl.
You can use it for GitHub command line.
You can use it to run lots of other interesting things on your computer.
It can even work with GUIs potentially, as long as you can handle the sophisticated
approach that a GUI requires in terms of file access and all that stuff.
I'm very, very interested in sandboxing technology.
Docker is one of the major players here.
They have the, the Sandbox or SBX command, which is a VM that runs
Docker inside it, that then runs the agent harness inside that.
And nono tries to take a much more direct approach by using the kernel
primitives that are already there, and it's built by some really
smart people that built Sigstore,
So there's all sorts of stuff that we dabble in, but this show, I think, will
be essential learning for everyone using agent harnesses, which is essentially
every developer and DevOps and platform engineer on the planet, because of one
reason As we get tasked to use cheaper models, the hallucinations will increase.
And in fact, a cheaper model doesn't mean that hallucinations are more
likely, but we are gonna all probably at some point need to push the
envelope for how cheap can we get it.
In fact, I know teams that their egos reside on how little they spend on tokens
by using cheaper and cheaper models, using Haikus, using the GLMs and the Kimis.
And these models may or may not be more likely to hallucinate.
But as you push that envelope to how cheap you can get in a model, how old
of a model can you get, or how cheap or of a smaller a model can you get to
run some of your workloads and some of your automations in CI, you're gonna
potentially deal with more hallucinations.
So we've got it on both ends of the cheaper models are what we need, but that
may mean more hallucinations, which may mean you need to care about locking your
stuff down, or the models are gonna be so sophisticated that they might actually
go a little more rogue in just the service of doing what you asked it to do.
And if you leave them alone long enough, they may actually do something
bad in search of doing the good thing.
And so they're not necessarily nefarious, That's what happened with HuggingFace,
was it was just trying to solve a test.
It was trying to prove that it was intelligent, so it
went crazy and wouldn't quit.
And the sandboxing is an area where we've got lots of different options,
and I like nono for its simplicity and its ease of use in my day-to-day, and
I'm now very interested in how can I use it in my CI and other places as
well to sort of have a blanket approach.
And we talk about a lot of those ideas in this podcast, so let's
get to it
Bret (2): Welcome to the show.
We've got Luke Hinds here, the s- co-founder and CEO of nolabs.
Luke: Thank you so much for having me.
Enjoying this
Bret (2): So just a real quick background on Luke here, 'cause he's a humble guy.
He's probably not gonna tell you.
He's kind of a big deal.
He created Sigstore, which one of my favorite security projects.
Sigstore is very popular.
If you don't know Sigstore, if you don't know you don't know, go check it out.
it's there to help secure your code essentially and give
you some, some assurances.
OpenSSF, which I'm also a very big fan of, and we talked about at least
multiple times a year on this channel.
You were a board member?
I didn't know that.
That's very cool.
OpenSSF is a, what is it?
A s-security, software security foundation.
Is that
Luke: Yeah, you got it
Bret (2): Okay.
Luke: on the nail.
Bret (2): Yeah.
And, I love the, it's the rating system for how secure your supply chain is.
It's like a checkoff list.
I'm trying to remember what that, what's that called?
Luke: Go cards.
Oh, SLSA.
Bret (2): Oh,
Luke: yeah, they're both scoring systems.
SLSA has levels, so yeah.
Yeah
Bret (2): when I found out about SLSA a couple years ago, I, I kinda
got a little obsessed with it.
Like I, I wanted all of my stuff to be the highest number.
It's like points, And the nice thing is I think it's what this show tries to do,
and it's kinda challenging sometimes, is to get out of the esoteric, the theory,
and get into the actual implementation and where's our checkoff list, right?
And so I try to get into those weeds, 'cause that's just how my
brain thinks, and SLSA is that.
Like it is this wonderful standard.
Hasn't changed a ton, but it, it allows you this list of hardening
down all the different parts.
all the different parts a little bit of your supply chain, whether
that's the building or the provenance information that you need to have, your
artifacts you're building like Docker images, and sorta steps through all
the different parts you need to think about, and you kinda just rate yourself.
It's not something where you go and get someone else's opinion, but you go
through, But somewhere in here, there, you dig into the individual parts of it.
Okay, we've got the build track, the source track.
I like that these are broken out now.
And as you dig down into it, you eventually come to a list of steps that
I learned a lot from years ago when I think when it first came out, like wh-
when it was in pre-1.0 or something.
And I'm, and so it's cool to have you here 'cause I've never actually had someone
from the OpenSSF on the show, even though that's not what we're here to talk about.
we're talk, we're here to talk about sandboxes.
So tell me, how did you get interested in sandboxes?
Like where's the origin story for you in helping to lock down binaries essentially?
Bret AI July 2025: Have you been adding text-to-speech in your apps?
One of my late-night projects this year was creating a personal
podcast feed so I could listen to the changelog of my favorite open
source projects while I do my chores.
I needed a text-to-speech API to do that.
I also heard from a colleague this week who built an app for his kids to
turn their e-books into audiobooks, and he's using the Speechify AI developer
platform to do that text-to-speech
Speechify AI is a developer platform for real-time text-to-speech, and
they make their own voice models.
Their Simba 3.2 model ranked number one on the Artificial Analysis Benchmark
for conversational voice quality.
They've got a free plan, streaming and REST APIs, TypeScript and Python
SDKs, and if you wanna get fancy, you can use their SSML metadata support
to add emotion into the speech output
Whether you're shipping a weekend project or production voice agents at work,
you can start free at speechify.ai.
The link is in the show notes.
Thanks so much to Speechify AI for sponsoring this episode.
Luke: I'd historically worked with malware, especially malicious packages,
so obviously been part of the software supply chain focus, and I needed a way
to very quickly isolate potentially bad things from running on my machine.
Okay, so you can use, there's many technologies you can use
here, Dockers, VMs, but I wanted something very quick, okay?
So I had this little tool that I used where you could very
quickly isolate a process.
So what do I mean by process?
A process is a running application on a Unix-type operating system.
So you run PS and you see a list of all these processes, and this was something
that I had for a while, never really had any plans to go far with it at all.
And what happened was OpenClaw.
So the OpenClaw agent was released, and it was carnage.
The security situation was pretty bleak.
A lot of people were being compromised.
They'd never really had this level of exposure to a
technology this powerful before.
And so I thought, "I'm gonna just put my little project out.
I'm not gonna promote it much.
I'm gonna just put it out there to help people." It was kind
of a, an altruistic cause.
That's what it was.
And this thing blew up.
So I went to the top of GitHub trending, and suddenly loads of people converged
and started making issues and saying, "Can it do this?" and "Can it do that?"
And then I realized I've got something popular that's
really resonating with folks.
And I think, what really helped nono propel was it's a… You'll
see it's a very small CLI.
It's very fast.
There's no infrastructure needed, no hypervisors, runtimes, and
it's able to wrap anything.
You can wrap an agent in there.
You could wrap curl.
You could wrap LS.
You could wrap Wget.
It basically wraps processes.
It does a lot more than that now, but it was very unique for a sandbox
really, because a sandbox is normally, there's quite a bit of apparatus
built around them, and this was something quite new, and it seemed
to really resonate with folks.
Bret (2): It was my first sandboxing experience other than, like, all of
the other, Chroot and, jails and, like, all the other… We could argue that
w- what kind of sandboxing those are.
you could debate that whether Docker is itself a sandboxing tool.
But it's one of those things where we have been trying to manage and mitigate
the blast radius of a single binary as an ecosystem for 30-plus years.
We've been wanting to run more than-- Ever since we were able to
run more than one process, I guess.
Ever since the '60s.
I have a little mainframe blood in me, so I'm not quite as old as the '60s,
but we were using '60s mainframes in the '90s in the Navy, so I get
to go back, way back to the green d- screen terminals in my career.
We've had limited success, and I think one of the biggest
challenges is, like, UI/UX, right?
Like if it's too painful, we don't use it.
And in fact, my confession on this show today will be, like, right now, because
I don't really, I don't have any active consulting clients at this moment, I'm
just making pure content, so I don't have anyone that I need to, like, sweat it.
I don't need to sweat every command on my machine.
So the only sandboxing I use is either nono or sometimes the built-in, like,
Claude Code stuff, but I actually prefer nono simply because the other tools that
I've used, either I don't understand them or, like you said, there's a little
more pomp and circumstance to using them.
There's a little more formality, and I just don't, since I don't
need that, nono just works.
And I love the templating system, so I don't have to be an expert in
every… You know, if you think about, like, the processes, the networking,
the file system access, like these, all these different parts, n- none
of us really know when we use an app every day what it needs access to.
Like, I didn't realize until I started using nono how much Claude Code tries
to creep into my system, try to access my browser extensions, trying to
access different directories, and nono immediately helped me understand that.
And I think, like, the only other tools I've seen that do that are tools
that are more diagnostic in nature.
Luke: Mm-hmm.
Bret (2): Patrick Wardle.
he makes, like, some Mac utilities for security and firewalling and
file watching and stuff like that.
And then the famous Sysinternals, WinInternals on the Windows
side from Mark Russinovich.
Those have been around for 30 years, and those were really all about
tracking fi- You know, you could see the, every file it touched, did it
write, did it read, and you could sort of ex- But it didn't, it wasn't
meant as, like, a firewalling system.
So to have this kind of utility feels almost like a superpower, because if I'm
nervous about something, I can just throw nono in front of it, and it's gonna,
it's gonna not do nefarious things.
So, tell us a little bit about, like, the elevator pitch for someone today
who's… They're using agents, they're using AI, they're still at the shell.
they're a shell fan, and what would nono do for them?
Luke: Absolutely.
So I'm not particularly great at elevator pitches, but I'm gonna do my best.
You know, I'm notorious for
Bret (2): an engineering podcast, so don't… Yeah, this
Luke: yeah.
I kind of probably more of an escalator pitcher, if you see what I mean?
But no, with nono, you can get going incredibly quickly, okay?
So you s- pick whatever coding agent you want, we have a profile for
that, and it's as simple as nono pull, and the name of the profile.
That will pull everything down for you securely, and then you do nono
run, and you pass in the name of the coding agent, and you're off.
nono's in the background.
You need never do anything more, okay?
That's all you need.
So within just a few seconds, you can be sandboxed and just get on with your work.
Now, if you wanna go deeper, you absolutely can.
There's a lot to nono under the hood.
But it allows everybody… It's a big church.
People can come in, get going quickly, and then the experts, they can find
their way and go deeper and deeper.
Bret (2): Well, I guess the good point there is that, like even I was
early days, I feel like, for no-no.
actually thanks to my chain-- friends at Chainguard, because they
were bragging about you, telling me that I should check it out.
But my, my onboarding experience was like read one page of documentation
and then copy and paste the command, and I'm back in ch- and I'm back
in Claude Code or back in…
At the time, I actually think I was trying to use OpenCode, and I think you
all were just developing the OpenCode profile, and I think I was commenting
on an issue or two, about making sure that worked, because at the time I was
like kind of obsessed about OpenCode.
I've kinda moved over to the dark side with the walled garden of Claude Code,
but, it works in both and I also tinker with Pi and I've played with it there.
That was my first use case, but seeing all your demos of showing how I can
just wrap any other commands inside that and how I can control networking
or secrets with this tool has really made me realize I need to, I basically
need to spend more time with it because I have, I have like those 1.0 or those
v-vo.1 limitations in my mind, and I'm now like, "Oh, this can, this can
do, this can do more than I realized."
I need to start leaning into the, to the egress.
'Cause I, at least for me, that's the first thing I'm willing to let an agent
do, is I'm like, "Yeah, yeah, yeah," like as long as you're isolated in my system
somewhere, I'm just gonna let you access anything on the internet you wanna get to.
And, and I know that I probably should have a more understand- nuanced
understanding of like where does my agent actually normally go and where should I
care or should I limit it in that case.
is there like an audit mode where I can see things, like I can see the
tracking record, but I don't have to see the, It doesn't actually block
it, it just lets me know what it was trying to access when it accesses it?
Luke: Yeah.
So, we have two approaches there.
One is when you exit the session, anything that has attempted to be accessed and
is being denied, it will give you the option to add that to your profile.
And it will also guide you around.
If something is particularly sensitive and you want to add it,
then it'll ask you just to double confirm, like secrets and so forth.
The other system that we have is that there's an audit of absolutely everything
the agent does, every domain it calls, the path, the environment variables, the
binary, its fingerprint, SHA-256, the co- tools that it calls, the specific
tools, the flags, everything is audited.
And we have this model essentially where everything in the agent space sandbox is
untrusted, but there's an adjacent trusted side, which we call the supervisor, and
this is the one that captures all of the audit, and it's the one that feeds
in the, what we call phantom tokens.
So they're not real credentials.
It's not your real GitHub token.
It's a random string which the agent gets, and we essentially treat
the agent kind of like a prisoner.
Okay?
So if you think about you go to like a penitentiary You can't just
keep somebody locked in a room.
You need to give them a bit of authority.
They need to go make their phone call, go to the canteen, walk around the yard.
So we allow agents to do that, but we limit where they can go, and
we limit what they can have, and we still keep a good eye on them.
Whereas I think a lot of sandboxes, it's been more around lock them in
the room and never let them out.
But really for agents to be good and effective and to do all
these amazing things, you need to give them a bit of authority.
You need to trust them.
You need to allow them to have access to things that are a little bit
powerful, and we're able to carve out very, very safe paths around
what that agent can actually do.
So we have… With dogfood nono a lot, so things like the AWS CLI, we very much lock
it down around what environment variables it can have, the URLs that it can call.
we will limit it to just the get method, so it can't post, it can't change things,
it can only do read-only operations.
We do this with kubectl a lot.
I know you're a Kubernetes guy, so we prevent like, replicas from
being a large number and clusters being deleted and namespaces.
And this way we know the agent can just go for it, it can explore, it can debug
clusters, but we stop it from doing the dangerous stuff, and we do this
care of what we call tool sandboxing.
So with nono, you've got a main sandbox that each time the agent wants to
call a tool, we spawn a micro sandbox.
It's a very small, ephemeral, short-lived sandbox where it gets its
own unique policy, and if it's allowed a specific secret, it's allowed it,
but the rest of the sandbox doesn't.
So that way your AWS CLI can access the credentials, but Curl doing
a post and a file read can't, 'cause that's data exfiltration.
So, so I think this is where we're quite different to a lot of the other sandboxes.
Yeah.
Yeah
Bret (2): Yeah, I saw a couple of the demos on your YouTube yesterday.
I was checking out the channel
Luke: Mm-hmm.
Bret (2): I was really interested in how-- I mean, I use the GitHub
command line tool constantly.
Like, it's
Luke: Mm-hmm.
Bret (2): e- it's either me or the agent using it constantly.
In fact, I built a, this GitHub sec- security analyzer tool that I built.
It gets your token from the GitHub command line tool, to talk to the API, 'cause
I just, it's the easier way to do it?
less code on my side.
And seeing the demo of how the profile will limit the put requests to particular
URLs of GitHub as a way to… the way I looked at it was that this is a way
for me to use my existing login and not have to go create a custom PAT, 'cause
that's what I've been doing in some cases, where I go and I make this…
I mean, I've been making a lot of PATs this year.
Like fine-grained, personal access tokens so that I can have these nuanced profiles
and reali- and it's a tedious h- it's a-- And then I gotta store that PAT somewhere.
I gotta put that in 1Password, and then I gotta get that out into the thing I want.
you have all of this access," but you could actually limit
the agent in a different way 'cause it's all just HTTP, right?
I really, I like that approach, and I'm excited to see that sort of take on,
like to be more prevalent, because it, it feels like a scale, more scalable model
than 1,000 PATs for agents for every p- profile and every, Because if I have
three clients as a consultant, I'm, on GitHub, I'm always very nervous about
that because, some people, they work for companies, they create a separate user
account because that, the bifurcation of permissions in the PAT can be really
nerve-wracking when I realize my one PAT has access to a dozen organizations, and
my login on my local GitHub has way more authority than it ha- should have probably
for a single login on a single machine.
And it, your profile methodology around the URLs and whether it's GET versus,
POST and all that is it makes sense to me.
I like it.
So I've not used it a lot yet, but I watched the demos and thought,
"Now I gotta, I gotta learn this."
Luke: Absolutely.
And this is all discovered through our own pain really, using agents
and seeing things go astray.
It's, we realized that we wanted to really limit what the agent could do.
So, so we do L7 filtering, the path, the method, and so forth, but we also
do the arguments, because what will happen is an agent will try to use the
GH CLI command, and it'll try to use arguments, and then we will block it.
We'll say no, and then it will try to pipe raw GraphQL through, and
we'll pick that up, and we'll say no.
And then it will try to wrap it in a shell.
It'll do SH pipe, and we pick that up, and we go, "No." And then you
just see them give up in the end.
You know, it's, I won't name them, but certain Claude, s- certain agents
will be very, very persistent, and then eventually they go, I'm done.
You got no, no running.
I give up," essentially.
And this allows us to really kind of look after ourselves really,
We… Because we don't want agents posting to our organization settings.
We don't really want them posting, quite a lot.
the, the- these things will just create issues when you didn't want them to.
And, and, so we really sort of are able to… Somebody described it as zero trust
for the terminal, which I thought was kind of quite a good way of putting it,
Bret (2): Yeah, if you had that marketing arm, that's probably
what your website would say now.
Luke: Yeah, yeah, absolutely.
Bret (2): yeah, because it, it-- that sounds like a very
buzzworthy, zero trust CLI.
and I don't disagree.
I mean, it sounds like a good thing, like it's something I want.
I mean, I love every time I hear zero trust, I think, "Ooh, that's what the sa-
the safe kids do. I used YOLO mode." so c- if we back up a minute and talk about,
like, the unique design of this app.
Tell me how it uses the native kernel, 'cause this thing is
all running on my Mac directly.
Like, it's not creating some sort of VM or a container or some other abstraction.
It's just right there on my machine, and then it also works on Linux, which
is a completely different kernel.
I don't know if it works on Windows yet.
I think I saw the website where it said WSL 2 was the way to do it, but tell
me a little bit about how that works
Luke: So we use two native sandboxing technologies.
On Apple, we use one called Seatbelt, which has been around for quite a while.
If you look at Apple's documentation, they will say it's deprecated,
but it isn't because it's used by some really huge projects.
Chrome very much relies on it, so it's not going anywhere.
It's just not as well documented, and that allows us to do file sandboxing
and basic network sandboxing.
We also then have Landlock, which is in Linux, and Linux Landlock is, it's what
we call an LSM, a Linux security module.
So it sits alongside SE Linux and various sort of well-known security
primitives in the kernel, and this again allows you to do this, file-specific,
network-specific sandboxing.
Now, there are several approaches within Linux.
You'll hear namespaces, cgroups, kind of, full-on microVMs
like Firecracker and gVisor.
We actually went with Landlock because it suited us very well
for this tool-specific, very fast sandboxing, but also we don't
require any elevation of privileges.
You don't need to use root or sudo.
We run in user space, and this is really important for nono because this means
nono can practically run everywhere.
You can run nono in a Docker image.
We've mentioned Chainguard.
We use one of the stripped-down Chainguard Rust images, which we run nono in.
You can run nono on many different types of comp- computer.
It'll practically run anywhere, okay?
And it's very similar to the, I think the trajectory that Docker had.
I'm a huge fan of Docker, okay?
And how Docker went from this localized tool that developers
loved to this large-scale orchestrated system for workloads.
Now, what typically happens with nono, somebody will start off in
an individual way, like you are.
Okay?
They'll start to create their own profile.
They'll maybe check it into GitHub.
It becomes their thing that they curate over time, and then they'll find team
members, and they'll start to share these things, and they'll start to
set up more and more profiles for all the different environments they're in.
And then eventually it'll get to the point where they'll go, "Well, we could
just lift and shift this into a Docker file so the entry point could be nono
run profile agent." And then like, right, okay, we're on Kubernetes now, And so
it's got this very seamless ability to run anywhere, and that's where it's very good
for sort of walking the journey with you.
You can start off with never used it before, quickly isolate my coding
agent, and perhaps share a home folder and my development folder.
So you start off there.
You go on the journey.
You learn more and more.
You go down the rabbit hole, and then you start working in a team capacity,
and then you start looking at, right, okay, we wanna run this in production,
so how do we do that, and that's where, nono's experienced a good amount of
adoption essentially, 'cause it's got that kind of seamless deployability.
Bret (2): I saw that, you had a blog post, 'cause one of my questions was
gonna be like, where else is this used?
'Cause it seems like such a core utility, that if it could run on the
Mac kernel, it can run on Linux kernel, it's, where in the cloud is it running?
And I saw that you had this post, the GitHub Action supply
chain attacks are here, so stop giving CI your release token.
We just had, our previous episode that released on the podcast was about the new
GitHub agentic workflows, which does a lot of this hardening as an in an automated
way, where they're trying to egress, ingress/egress, like, read-only file
system, everything in a container that's got the inputs and outputs are filtered,
like there's all these different steps.
Tell me about, like, what are you seeing in CI?
Like, what is this, what are the advantages of using this in CI?
Luke: So we run nono in GitHub Actions.
we realized it was very effective.
So we can do native sandboxing, care of the fact that GitHub Actions,
the underlying host system is Linux.
And we then released a project called Runseal, where it's an action that
you can easily consume and use.
And then there's a, a simple YAML structure where you can set what domains
you want to allow that workflow to connect to, and you can do credential injection.
So the execution environment where the action runs, it cannot have a real token.
It gets a spoof token, a phantom token we call them, and you can
limit which domains it can call to.
So a lot of these sort of fork attacks that happen in GitHub Actions, typically
they look to exfiltrate a secret, a GitHub token, and they will look
to exfiltrate to a specific domain, and we can lock all of that down.
So we can lock down an action to just being able to talk to api.github.com.
All of the secrets are useless outside of that operating context.
They're only useful within that short session.
And we can also do a lot of supply chain stuff.
So we do a lot of Sigstore stuff in there as well.
So we do a lot to sign skill files.
You can do a GitHub Action provenance, like SLSA, of your skill files, and then
when the agent tries to access those skill files to read them in the sandbox,
we do a verification that the files as they exist in GitHub have not changed
at the moment that the syscall comes in and the agent tries to access them.
Because this is how prompt injections happen.
And a-again, that's one of the things we do that we're not very well
suited to telling folks about this.
we have full end-to-end supply chain security in nono as well, which is
something that a few people don't know.
Bret (2): Yeah.
I can see how I like the idea of signing my skills and then verifying
them, 'cause that's always the, that's always the, the part that everybody
skips, is the verification at runtime.
It's not always obvious.
It's sometimes hard, when you're pulling artifacts, like Kubernetes images.
Like I've been, for a decade, I feel like I've been talking about and
helping people understand, the signing and verification nature of container
images, and I l- I love the, I love that we have objects now that we can sign.
I can actually, build my apps and ha- have Sigstore to sign them and the-- But the
ability to guarantee that, that skill is indeed my skill, is I th- it's probably
one of those things where, like so many of the security tools on- there's very
few percentage of engineers, let's just say 10 or 20%, probably less, that are
really paying attention to that stuff.
And but I tend to, on this podcast, I tend to kind of try to shout
all this stuff from the rooftop of like, it's not that hard.
It actually isn't.
And you, and you can always start somewhere.
Like, it doesn't have to be end to end.
Like, if you just had one, one GitHub action that used, that you tried nono
with, and you actually signed, bothered signing a skill or something like that,
or you actually bothered limiting to the API egress, like that's a start.
And it doesn't-- You don't have to boil the ocean with these tools and
make sure, think that every single nook and cranny has to be solved.
Of course, agents I think are, are gonna make a lot of this easier.
I think I'm finding that one of my, my favorite use cases for agents is,
is not-- Obviously, we all started with like writing code in YAML.
mostly for me it was YAML.
Docker file is YAML, TOML.
And I find that implementing sort of like org-wide changes as a DevOps person
or as a platform engineer has always been problematic because you end up
having 100 re, repos that you want to make some sort of change to, or you've
got 50 Kubernetes YAML repos spread out everywhere, and you wanna make some
find, find, functional change in there.
And then you have to write your own scripts that would go
through and automate each one.
And I find that agents, agents make the implementations of a lot
of these things so much easier because the repe- repetitive nature
of a lot of the, the work that I feel like we do in the operations
space can be alleviated with this.
So I'm looking at this tool and I'm thinking, "Well, that's a change to
my workflows, and that's me tracking some URLs and extra things." Not
that much work, but once I've done it once, I kinda can just ask the agent,
"Please give me PRs for all of them.
We're gonna review them together, and then you're gonna implement the PRs." Where
else outside of CI, like what is… Okay, so you talked about Kubernetes production.
We started with the idea of local harnesses, which is, I think, where
probably a lot of us are getting started.
Then we realized it's str- it's for more than just our harnesses.
Then I realized, oh, I can put this in a CI and I can help harden, like the
fact that GitHub Actions doesn't even have egress filtering firewalls today.
I know it's coming, they're saying it's coming this year, but, like, we
don't have it yet, and, we haven't had it for the eight years or six
years that we've had GitHub Actions.
So, so people can start doing that, and they can start limiting the
secrets access into their apps, which we also can't very easily do
with GitHub Actions without using environments and other fancy features.
And so they start to get it into more of their CI, and then they
realize they might be able to harden some workflows, workloads in
production, particularly agents that we're all building with agent SDKs.
Is that-- So is that an area that you're, you explained that earlier, but that's,
is that, I guess that's a very common d- dev thing to do, is we're all trying
to build these agents, whether it's for our own automation or for a, a line of
business app, and we put these things in containers and we think we're done.
We think we're okay.
What, what does this do in a container?
Like, what's my, what's the argument for why I need this
in my containers in Kubernetes?
Is it because I could,
Luke: they?
Yeah
Bret (2): s- set a policy to lock down to non-root and all that in there?
Luke: Yeah.
So this, you're touching on a great point here to really kind of differentiate
nono from containers and microVMs, and it's not a one is better than the other.
They really complement each other well.
Okay?
So one of the things you're, that you're picking up with nono, it's
what we call a capability-based model.
It's fine-grained.
Okay?
So you're able to be very specific around individual files that can be accessed,
perhaps read or write or execute very fine-grained URL filtering, the secrets
injection, the skill attestations.
Now, with a Docker image, if you were to try to do that, that's
gonna be a lot of volume mounts that you're gonna be constantly…
Operationally it's gonna be very expensive to do that because you're
gonna have to maintain all of that, okay?
And so nono was built more for this new world of this very fine-grained
agent in its operating context, protecting the spaces there essentially.
And nono is not as good as containers and microVMs at complete isolation.
They are… It's, it's, it's, it's brilliant.
It's on, it's protected.
I mean, you get kernel exploits of course, but generally it's a very good
solid monolithic layer of isolation.
You know where you stand.
It's a safety belt.
Nono is more of a… Like I said, it's a very fine-grained,
very customizable thing.
And so we often say to folks, "When you run nono in an operational production type
scenario, run it on top of a microVM, run it on top of a, in a container," okay?
And then you've got the best of both worlds then, because I see microVMs,
containers, where they're really strong is the threat model is really about an
agent lets off, it executes something malicious, something bad, untrusted
code is executed, it's contained.
Okay?
Now, our threat model is partially to do with that, but we're actually
looking at agents that have good intent.
I know an LLM doesn't have intentions as such, but we've all seen this
thing where you d- go, "Claude, what, you've deleted the data?" And,
"Oh gosh, I'm frightfully sorry.
I should never do that again," and da, da, da, da, da.
Bret (2): You're absolutely right
Luke: They can hurt you while they're trying to do their job.
Do you see what I mean?
And that's the whole new threat model that I think you need something like
nono for, which is how do we let these things have a bit of power,
give them a bit of responsibility, like we spoke about earlier, give the
kids the cars, the car keys, they're going off to university, you start to
give them a bit more responsibility, but you want to keep it safe.
Do you see what I mean?
You want to have those guardrails there still.
So it's not around completely contained, lock you in a box so you
can't do anything, and then it's very difficult for you to do things.
And what we all love about agents is magic.
That it's incredible what they can do.
I'm not particularly good with OpenTofu and YAML and
I could learn it, but there's only so many things you can do in a day.
Whereas an agent can go off and can do that.
It can debug, "Why is this not deploying?" It can solve things really quickly,
but there's a lot of risk in that, because of if it goes off course, it
can really cause a lot of problems.
And so I think that's the kind of the key differentiator with us really is
we're fixing a, a different threat that we now have in our midst.
Bret (2): Like, the way these tools work is often very much
based on their origin story.
And for example, like Docker, Doc- whether it's Docker or Kubernetes,
it's all running containerd, y- 99% of the time anyway.
So i- in containerd, there is probably a way to look at system logs to see that
it tried to access a kernel primitive that Docker didn't allow, right?
But that is not a user-facing default thing that you're seeing in Sesh because
Luke: Mm-hmm.
Bret (2): the tool was designed in a world where we thought the code was good.
We weren't terribly worried about the good code trying to do weird
things with the file system that weren't necessarily trying to exploit.
It's just trying to get a job done.
It just wants to be helpful.
it's
Luke: Absolutely.
Yeah,
Bret (2): Yeah.
I, if I had another analogy for you besides the car key thing, it would
be like I could see Docker as being described as the butcher knife,
where it's a blunt instrument, and you're like the paring knife, where
I'm doing that fine detailed work on
Luke: Precisely.
Bret (2): And in fact, Do you see with these templates, and I haven't
checked, maybe you already have this.
Do you see where… Like, I'm imagining a workflow for me and my advice to
people eventually, especially part of this, this DevOps guild that I've
created, is we're really looking at patterns and practices, trying to
figure out where we can operate safely.
Like, what's the responsible way to use agents as an adult, right?
as someone who's been in this craft for decades, as most of the people that are
in the guild are a little bit of gray.
they've got some, at least they've got some experiences and some battle wounds.
And everybody's on a different end of the spectrum around, concerned
around security and safeguards and s- whether how many token- how many
paths do I have on my machine that it can get access to in Claude, right?
Or in, in Cl- Codex.
there's a lot of utilities that have a lot of logins on my machine,
across a wide spectrum of tools that could do a crazy amount of damage.
And I never have to worry about that until AI, because I was the
only one typing in my… we all worried about the front gate, right?
My password's strong.
I, my, you can't get into my code on my machine.
And, my, my d- my hard drive's encrypted.
I go, "Oh, I'm doing all the right things. I got my firewall on."
But I'm now running this very helpful thing that's a little too eager sometimes.
And so we're trying to figure out, like, what does the day-to-day look like
of someone who's op- running an agent locally, running a harness, they're
operating infrastructure, they're maybe writing some code and doing some PRs,
but they've got this blast radius where they technically could take down the
entire AWS cluster with a single command.
And that's on their machine, logged in by, you know, it's saved in a config file.
is it something where, like, you would have multiple profiles and I
would have… Like, I would bring up my agent for troubleshooting.
I got something g-going on in the cluster.
I got an idea of where I need to look, but I need to point the agent at it.
So I spin up nono with my OpenCode or my Claude Code or whatever, and I'm using
a sp- very specific profile that maybe I've named, like, Kubernetes Read-Only
or GitHub Read-Only, and I lot it, allow it to access certain things, certain
URLs, and it does that troubleshooting.
And then I realize, oh, this is a policy change that happened in
Kubernetes that I need to quickly undo, and I'm not a GitOps.
I'm not gonna do it the GitOps PR way.
I'm just gonna go right to kubectl.
But I want the agent to do it.
So now I've got to flip my nono pro- profile over to a writable profile,
but maybe I only want it for this one cluster because I don't want
it to have every Kubernetes token.
and so now I've switched profiles to one that's maybe specific to
a Kubernetes specific cluster.
It's got a specific key.
It's maybe given me a limi- I've given it limited write access in that profile.
Is that something where, like, there's a list of profiles
the team manages together?
Is that a thing you see?
I'm just trying to imagine the workflow of, like, the daily
efforts of a platform engineer.
Luke: So, with nono pro-profiles, they're JSON, okay?
And they are composable, so you can inherit.
So you could… there's a Claude Code profile which is available.
Now, if you wanted to extend that and add your own specific grants and
denies, you can just do extends, and it will pull that profile in, it'll
inherit it as a parent, and then you create your profile as a child.
So you've got this kind of composability.
So this sort of works very well in a, an enterprise setting.
We've got a bit, little bit more work to do, but you could have, like, your
kind of corporate thou shall not pass.
Absolutely never, never, never.
And then you can allow different teams to be perhaps a little bit
looser or access certain environments, test environments and so forth.
Probably would've been quite useful for the stuff that happened a couple of
days ago with HuggingFace and OpenAI.
And but yeah, we've got this, it's composable policy, okay?
Now, the interesting point, you really raised on a really good
point, which is what if I wanna swap profiles mid-session, okay?
Now, that's very difficult to do with a sandbox because it kind of breaks
the fundamentals of what a sandbox is.
They're, they're meant to be, you start them, they're immutable,
Bret (2): Right
Luke: then they exit.
Okay?
But we have come up with a really good solution where we're actually
able to expand grants during the sandbox's life cycle, okay?
And, and we do this with a, a lot of kind of trickery pokery with, with Unix
processes into process communication.
It's a, a lot of kernel stuff again, where we're able to, if a, an agent needs a file
that it doesn't have access to, we feed something called a file descriptor, which
is, it doesn't actually get the file.
When it gets the file access care of this supervisor.
And the supervisor, it's a little bit like the jailer, where we
spoke about the penitentiary.
So if you want something, you've gotta go, "Guard," and bang on the door essentially.
And so we are able to do that now and some people have been looking at using
this approval backend to plug into a policy system like, for example, OPA.
So some people have existing policy engines.
They're like, we really like how you've done policy in nono, but we've already got
a policy engine." So that's where these approval backends come in effectively.
And, and you can also do things like, I've seen folks, they
wrote a Slack approval system.
So when an agent gets stuck, it's, there's a web hook and it posts to Slack,
and then they can approve it in Slack.
Now, obviously, some people are gonna be more security stringent than others.
Okay?
They may not like the idea of Slack being an approval system for an
agent, but this system is… You can build around it effectively.
You can build around this interface
Bret (2): That is
Luke: And so a very long way of saying you can actually expand that runtime now, so
Bret (2): That is cool.
Is that a, is that a Linux unique feature?
Are you able to do that on Mac as well, or is
Luke: Yeah, it's, so with Linux you definitely get a lot more bang
for your buck, 'cause what we can do with the kernel, but it does
actually work on Apple with the tool execution, the sort of tool sandboxing.
Bret (2): Oh, right.
Luke: Yeah, so for example, like the GitHub CLI, if it wants access
to something that it doesn't have because it's not in the local
policy, the JSON, there is an order.
So if not local, then fall back to the approval system, and then
it can ask the approval system.
So I've seen people rig that into the, the Apple fingerprint
Bret (2): Hmm.
Touch ID.
Luke: We've done a lot of interesting work where we originally started doing a
lot of stuff around machine learning and training models, so we're looking to do
some work there around to make it easier for folks to understand what to approve.
'Cause there's this thing called approval fatigue where it's just kind
of, you just eventually you're just kinda hitting the tab or whatever it is,
Bret (2): You got like the,
Luke: And,
Bret (2): the little, wa- bird thing on your desk that just sh-
Luke: Yes, precisely.
Bret (2): the enter key this…
Luke: Yeah, very much, yeah.
You know.
So we're all engineers trying to use these agents, so we tend to
experience these problems ourselves.
They're pains for us, and we seek to solve them, and luckily that
works for others as well, you
Bret (2): Yeah.
The best products are always the ones that the, the builders are using
themselves to get their work done.
Luke: Yeah, absolutely.
Bret (2): do you think there will be a day where harnesses…
Like, when you talk about these approvals in session, is this an
extension of, I, I'm trying to think if I've experienced this.
I only remember experiencing it when I exited the, the Claude Code or whatever.
Is this something that you think would be, like, an extension into
the harness that would give it abilities for approvals through nono?
Is that a thing that's happening
Luke: very much, yeah.
Absolutely, yeah.
So, uh, w- we've got a, a, a video that demonstrates this with kubectl,
and it's running on a, an Apple Mac silicon machine, and there is, aspects
of the operations it needs to perform that aren't granted in the policy.
So we run a simple Python web server that's able to pick that up, and
then you can approve things like it wants to scale the amount of pods.
We don't allow that.
That's considered a kind of a write operation, but we allow it to go
to the apr- the approval system.
And so it's not something that comes batched in with nono at the moment, but it
is a, it's a programmatic interface that's there to integrate with essentially, yeah.
And so I mean, us, obviously we love open source, but I, I have a company,
a, a dog, a family to look after.
So eventually… we're building a product essentially, but we'll always
keep the open source powerful and free.
You know, that's the way I've always done things.
But that's where we will start to really introduce how this works
at a large scale effectively.
how do we handle thousands of engineers that are, and agents that are, that
need these very sort of multidimensional threat assessments around approving and
denying and what should be allowed and…
Bret (2): you've already kind of hinted at this, but I'm guessing that a lot
of this is like, it's almost feels a little bit like a cat and mouse with an
agent where you block, you block, you block, and then the more… when Fable
comes out and it tends to be a little bit more tenacious, it tends to be a
little more eager as a model, and so it tries different or new innovative
approaches to getting around the sandbox.
And so, is that, is… Do you feel like that it's a little bit of that, of
this, of like, "Aren't you cheeky, for figuring like, oh, you did that in Python.
I didn't think about that," or you did some weird HTML escape that somehow got
a… Like, I'm just, I'm sure there's some good war stories you've got.
Luke: Absolutely.
So what we do is we, we test where we lock an agent up, and
then we pipe lots of tasks in.
Okay?
And some of them are tasks that interpreted a certain
way could cause trouble.
Okay?
And then we, we make a cup of coffee, sit back and just watch it go.
And it's like, like D- Homer Simpson, "D'oh, d'oh,
Bret (2): Yeah
Luke: He just… And then eventually it's so satisfying it, it just
gives up, and it says, "No, you need to change your no-no policy, man.
I can't do this.
Bret (2): it's like you've won against a friendly Terminator.
You're like, "Okay, I, you admit defeat. I still can control the AI."
Luke: Ah.
it's funny.
Sometimes I'm like, "Seriously? You're gonna use Perl?" Like, is that how
desperate you're getting, you know?
'cause they are… Yeah, they're incredibly crafty,
Bret (2): Mine, mine, mine lately has started to get confused sometimes with
web, web searching and web crawling or web fetching tools, and it will resort to
bash calling curl sometimes for websites.
And, and I have to, like, stop it and l- like, "Okay, let's…
You're, you're going crazy.
This is not how we're gonna search the internet, by
Luke: Absolutely.
Bret (2): names and curling them."
Luke: and you just reminded me of something else there.
Of course, we can do this with MCP as well.
So, we can kind of, MCP is a set of tools, okay?
And, so we can kind of do a safe path around MCP execution, especially the
STDIO stuff, which is all localized,
Bret (2): Right.
Is that something where it's like an, it would be like a command line option
or it's just a part of your profile?
Like you have files and other things and there would be a section for MCP?
Luke: So I mean, like, if it's, stdio, typically people will do MPX, and
they'll pass in the name of the MCP,
Bret (2): Mm-hmm.
Luke: It's a kind of like… I guess it's like a JavaScript, compiled JavaScript,
and you then say what that is allowed.
You can give it a phantom token rather than it getting a real credential.
You can say what URLs it can access and… Because, that's another
tool that's incredibly powerful, but with, what is it they say?
With power comes great responsibility, and, and these
things don't have responsibility.
So that's where nono comes in.
Yeah, yeah
Bret (2): There, there's a couple of good taglines probably that, the future
marketing team could work out with that.
Luke: I mean, I'm not here to promote my company, but
that's why we're called NoLabs.
'Cause we thought, well, somebody's gotta learn… Somebody's gotta
be looking at how to say no.
'Cause we're all saying yes, and just yes, yes, more, more, more, And just
giving, more and more power to agents.
And we thought somebody's gotta look at the nuances of no.
When,
when do you say no?
So yeah, teach your agents when to say no.
Bret (2): Yeah.
I like it.
it gives you a very specific purpose, which my company name is
extremely vague, so it c- can do anything, so I have no purpose.
Luke: I was just gonna say, and we don't have a model, so
our interests are in saying
Bret (2): Right.
Luke: you've got a model, sometimes I'm not gonna… Okay, I've gotta be
careful here, but the more that model can roam, the more products it can find.
Okay?
So, no is no with us
Bret (2): Yeah, the incentives aren't
Luke: So yeah.
Bret (2): with model companies,
Luke: Exactly.
Bret (2): so what's next for nono?
like, what, what are you excited about for the rest of the year?
give us a… Can you give us a little preview taste?
A little,
Luke: Yeah.
So, do you know, it's, it's not very exciting, but it's essential.
Stability.
Okay.
So we are now really focused on… We've got an incredibly powerful payload, so
we're trying to just slow the roll a little bit when new features come in, and
really improve the documentation, give people lots of examples, really make the,
the user experience as seamless and as least brittle as possible, investigate
more ways of surfacing and solving profile denials and, and, and, and really
just starting to dial in the quality.
Because, a lot of people are starting to use this as their day-to-day tool.
They're running this in teams.
Some people are running production agents.
We have people using nono in production already, One of the things with
nono, we've been looking at coding agents, but this could quite easily
be Pydantic AI, LangChain, ADK.
You can run anything in there essentially.
So it could be nono run Python main.py, and it will, you'll immediately get all
that nono has to offer for your agent that you've developed essentially.
And so yeah, we're really looking at improving the quality around things.
And of course, as NoLabs, we're looking to build on top of this effectively.
Because again, to use Docker, I, it's… I'm just so fond of Docker and they,
they had this model of kind of the, the, the, the, the chef's kiss of developer
experience locally, but you needed a Kubernetes to orchestrate and scale this.
And, and that's where we're doing a lot of research at the moment.
How do we make nono operate, this policy operate across a diverse
large fleet of agents effectively and be able to track everything and
Bret (2): Yeah.
Luke: resolve all of these approvals and… Yeah, exactly.
Bret (2): centralized, logging and, policy generation.
I can see that, that, I can envision the management portal coming soon.
It f- it feels like the right approach.
I, I mean, it feels like a, a, one of those things where
it catches on in a dev team.
I've got some DevSec engineers and some security engineers in our, in
our dev- agentic DevOps guild, and they're all very much looking at the
sec- you know, not just the security of agents, but the security of skills.
Luke: Yeah.
Bret (2): they gotta pay more attention to NoLabs to see if there's anything
coming down the pike for, for them to administrate and, and manage centrally.
And then the idea of, like, s- signing skills, it's we're, we're kind of,
like, in our skills moment with, with the learning and, that we're doing
in the team, where we're trying to figure out centralized management.
It's-- None of this stuff is really figured out in the industry.
We've got lots of ideas, and we've got lots of walled garden proprietary
solutions, but a lot of what we do in open source is, like, well, we
kinda wait for them to figure out the market, and then we figure out if
there's an opportunity for open source.
And this feels like that moment where we've got the registries for skills, but,
like, the idea of signing it and then validating it on runtime, that feels like
Luke: Very much.
Bret (2): And, and so it feels like there's maybe an opportunity for someone
to make a, an open source project that could kind of be, like, the cloud native,
you know, we got the CNCF and the
Luke: Absolutely.
Bret (2): something there for skills as well as for sandboxes because, it feels
like we need-- We're, we're gonna need a little more formality in the standards
as the harnesses all sort of bifurcate
Luke: 100% agree.
Bret (2): Yeah.
Well, I definitely gotta use this more because I think it's kind of like agents
themselves, where I feel like nono is one of those things where you get a taste
for it and you get comfortable with it, and it starts to be-become something
that you're using more and more, and then pretty soon my vision of, like, all
these different profiles I'm extending, that I have ones for certain use cases
on my infrastructure, and I start to get more comfortable because I think like
a lot of us, I have been YOLOing it.
My Claude command line def- is an alias to Claude dangerously skip permissions.
And I, we have been lucky to rely on these super high-end state-of-the-art models
that mostly don't, at least this year.
Like, last year was crazy.
Last year it was trying to d- you know, delete my hard drive and I think at
one point it, I was trying to get it to build a SwiftUI app and it, last
year with, like, a Claude, like, it was like a Sonnet 3.5 or something.
It was determined that my Xcode installation was broken and it was
gonna delete the entire directory off of the system profile 'cause it
was like, "Oh, no, you, I can't…" The build was failing, but it wasn't
the fault of his code or its code, it was the fault of my build tool.
So it was trying to delete all the build tools and I
luckily caught it, last second.
Luke: Yeah.
Bret (2): I think some of us have gotten a little, more comfortable
with the models behaving better.
But what I'm now seeing, and this is maybe, I, I don't know if this is a
trend overall, but as people start to reduce costs because, like, Opus is
crazy expensive, so they start to try to see how cheap they can get the models.
Like, they, they sort of, we use skills testing and, and evals to try to see
how cheap we can get this token budget.
But in doing so, you inevitably, you, there's like this gray fine
area in the middle where you get just cheap enough and then it starts
to hallucinate, which means it's, I need, I now at that point I need nono.
And so what I'm finding in, in our guild is that as people mature and they
realize not everything needs Claude models, like you can use GLMs, you can
use some Kimis now, you can use some of these cheaper open weight models,
but Now, as you go down the rabbit hole of how cheap I, can I get it, and
there, I have a couple of teams where they're, they're now the inverse of
this token maxing thing where they're bragging about how little their spend is.
Like, it's sort of a sign of engineering expertise that I've been able to do all
this with a, with a super cheap model.
But I think that they're gonna need more guardrails and so this is almost like a,
a, a specialized use case of you could argue in a marketing campaign, use minimax
at, cents on the token comparatively to, at, at 5% the cost of Sonnet, but you're
gonna need some harness protection.
You're gonna need to, like, keep it on its rails, yeah.
Luke: Yeah.
And as you rightly put, we, we're completely agnostic.
You can run any agent, and, whereas, other sort of s- enterprise sandboxes
that are coupled to the, uh, the lab
Bret (2): Yep
Luke: They, they can't, they cannot be split apart effectively.
So you can, as the next new call Py OpenCode, whatever comes out,
Bret (2): Whatever's next.
Luke: You use your same profile, maybe adjust it a little bit
Bret (2): All right, last question 'cause we're running
long and I apologize for that.
Luke: I've so enjoyed this.
Mm-hmm
Bret (2): what about GUI apps?
Like, where's the rough edges on this?
Because at first I started using it and then I realized I maybe couldn't
run Mac apps in it, and I wasn't really sure if that would work, and
Luke: Hmm.
Bret (2): like
Luke: You can
Bret (2): are using the GUI harnesses,
Luke: Yeah, absolutely.
So you can use nono to isolate in a sandbox a GUI.
The real aspect to consider is if you've got something like an Electron app,
like Bun is one, quite often spray a lot of file access all over the place.
Okay?
So, you would be able to eventually write a profile for it, but they
tend to be, you know, they tend to kind of a little bit feely grabby.
And but we, we are, we are able to do that.
I've seen people get the Claude GUI.
I've seen people get VS Code running in nono.
And but then it starts to get complex when you've got all these different
extensions and, and, and I've heard of people trying to get nono to isolate
extensions as well, which is interesting.
And, but basically there's an entry point.
At some point, the rubber hits the road, you're gonna call an executionable,
a script, and it's going to execute
a process, and that's where nono sits.
So it's, there's a level of complexity that's involved.
If, like if you had something like a video editing app, you could
probably run nono in that, but it's gonna be very, it's gonna have a
very wide blast around what it needs,
Bret (2): Yeah.
Your Electron de- description, especially like with VS Code
extensions, I mean, we just recently had the big VS Code extension hack.
So it made everybody wake up and realize that, extensions are still code running
on your system and you don't, y- you, we all knew we shouldn't download
random ones, but also, like, even the reputable ones can also be attacked.
And that's why I've, I've, I love, I really like Go.
I love static binaries now.
Like, it's my whole thing.
I, I don't want a distributed code base that's to compile at runtime.
Like, I preach about this a little bit at conferences about, like, we've
got 40 years of programming languages we're all using, and they were all
created at different eras of technology.
And this is a little bit of a rabbit hole, but, like, we were optimizing
for the problem of the time, and now, like, the problem of the time is I
need five different Python versions.
That's, like, why Docker exists.
One of the reasons it exists is because we, we couldn't use the same s- system
library for every app, and we, we needed separate installs, but the
systems don't really account for that.
So then we have to come up with abstractions.
And here we are today, and I'm, I'm, like, all in on, whether it's Rust or, or Go.
Like, I, I want that single binary experience.
But I know that l- with a lot of these Electron apps,
it's dozens of node binaries.
It's, like with Chrome, you've got a process for every tab.
You've got extension processes in every tab.
Like, you've got a ton of stuff there, so I can only imagine how, how big these,
these profiles… So it d- it re- seems like it's gonna require a certain level
of determination to, to get it working, but it's, it's cool that it's possible.
I, I was assuming that it was just maybe something on Mac that wasn't
gonna be possible because of the way the, the notarization and…
Because there, there was already a security system built into Macs that
we as users see as pop-ups that are very user-friendly and, and weirdly
still tell you nothing about exactly what you're asking permission for.
And I've always assumed that that model, whatever that locking, system
lock model is, is, was a little bit different than shell tools.
Luke: Yeah.
We do stuff around, within profiles you can provide access to things like IOKit
and kind of Apple fundamentals like that.
we had to get in the ability to allow GPUs, which meant, there was a lot of sort
of, I didn't actually work on that, so I can't speak with any authority there.
But we had to kind of, there's these sort of Apple primitives
that we had to allow effectively.
So you can do that as well here.
And nono's developed in Rust.
So we… I love Go as well.
Wrote most of Sigstore in Go, and we went for Rust.
we're really strict around use of unsafe and unwrap, and we do lots of, we do
lots of security checks on the code and look for race conditions and So yeah,
yeah, we landed on Rust, 'cause it's… I don't wanna argue one's more secure
than the other, but it's, it's one where we, we knew where we stood really.
Bret (2): Yeah, it feels right.
It feels right for the job.
And I love that, I mean, most people that are… I don't know.
I know a lot of engineers that are fans of both.
Like, they use both,
Luke: Yeah, absolutely.
I, I, I, I adore Go.
Bret (2): Yeah
Luke: just a, it's a work of
Bret (2): Yeah.
Yeah, Docker was my gateway.
Docker and Kubernetes were my gateway to go to, and now it's like, it's,
it's like to me, to me it's like the replacement for Python as the
s- sysadmin, sysadmin language.
But hey, I, it's just a preference.
Like, I know people that spend their whole day in Python as a system
engineer or a, a platform engineer.
And thanks to Luke for being a, a, an awesome security
engineer making open source hits.
Let's hope this… I mean, this already sounds like this is a hit, but let's hope
it blows through the stratosphere and stays, stays in the top, top GitHub repos,
because I, I, as someone who likes to…
I'm always, like, security team adjacent.
Never really a, a dedicated security engineer, but always
that, that DevOps guy sitting next to them going, "Hey, let's work.
Let's hold hands." so I love when security tools are fun and easy to use
and, like, make me feel like an elite hacker, and that's kinda what this makes
me feel like, is like I'm, I'm paying attention to primitives, but I'm also
reigning in and ev- And any security engineer standing over my shoulder would
not judge me harshly for my, my, my dangerously bypassed permissions defaults.
Luke: Absolutely, yeah.
That's by design.
Security tools, it's hard to get adoption because you're normally kind
of scolding people, hitting them on the head, telling them they can't do things.
Bret (2): tell him what's wrong.
Luke: Yeah, so you know, I mean, Sigstore's one where we managed to
kind of make it almost seamless.
The developers liked it, 'cause it's rare that developers like a security tool.
And, and nono it's the same really.
It's, it's, it's out of the way if you want it to be.
Bret (2): Yeah.
And, I'm sure there's gonna be a dozen more use cases for it, so
we'll have to have you on again,
Luke: Absolutely.
Bret (2): talk about all the new use cases for nono.
'Cause I got a feeling that as we all start to venture out into the ether of new
models, other harnesses, building agent SDK model, harnesses, like we're all gonna
learn these lessons, I think, a little bit the hard way and look for solutions.
Hopefully nono's the one they pick.
So,
Luke: I hope so
Bret (2): gl- glad to have you on, Luke.
Everybody can get started over at nono.sh.
there's a really quick guide.
You can install it with Brew and all the typical utility ways to install.
And of course, because they're security focused, they, they, like
the Mac is, the Mac is notarized, like all the, all the good stuff there.
So, if you wanna know more about the, like the future of where nono
is going, maybe head over to NoLabs.
That's nolabs.ai, where they've got a couple other things they're
playing around with, it looks like.
You got, got some other ideas.
So I'm excited to see what comes out of the team.
And where, where else-- And I guess they can see you on all the socials,
and you have a YouTube channel for nono.
Luke: Channel, yeah, if anybody runs into any issues, we've got
a Discord that's pretty popular.
A lot of NoNauts, as we call them, in
Bret (2): NoNauts.
Luke: and you'll be able to find that on the, I think nono.sh and the GitHub repo.
It's got a link to the Discord.
And, uh, yeah, nono doesn't really have any other social channels apart from that,
Bret (2): keep it simple.
all right.
Thanks so much for joining me, Luke.
Luke: Pleasure to be here.
Thank you so much.
Bye-bye
Bret (2): Ciao.
Bret AI July 2025: Thanks for joining us, and I'll see you in the next episode.