AI Agent Sandboxing with Nono

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.