Overview
Most AI security talk is about stopping bad prompts and keeping models from saying the wrong thing. The bigger risk is quieter: an agent you already deployed and trust starts behaving differently overnight.
In this session, Jack Poller talks with NetFoundry’s Mike Guthrie about his rule for AI in production: deploy the agent, but don’t trust the agent. Mike comes from DevOps and site reliability, where you assume every system will fail eventually. He explains why agents don’t need to be malicious to cause damage. They only need to ship a bug. Model aliases update without warning, harnesses update themselves daily, and a safety behavior that worked yesterday can be gone today.
Mike tells a real story. In two separate projects, within 30 minutes, his coding agent suddenly ran git add -A and committed local sandbox credentials to his repos, something it had never done in months of use. He uses it to show the difference between soft boundaries (guardrails and prompt instructions an agent can reason its way around) and hard boundaries (access controls it can’t get past). He also walks through what a zero trust agent deployment looks like:
- Agents defined in declarative, auditable configuration
- A starting point of zero permissions
- Credentials kept behind tools and an LLM gateway
- Network access that stays dark, except for explicitly defined OpenZiti services
Three key takeaways
- Agents don’t have to be malicious to be dangerous. Models, model aliases and agent harnesses change all the time. An agent trying to be helpful can do something it has never done before, like committing credentials. If you trust its good behavior, a single bad day is enough to hurt you.
- Guardrails are a shield. Access control is the armor. Prompt-injection filtering and data protection are worth having, much like a web application firewall. But if they’re your main defense, you’re trying to hold back water that’s already through the dam. Real security comes from strictly defining what an agent can access and do.
- Start at zero and build up explicitly. A safe agent begins with no ingress, no egress, no tools and no file system access. Each capability is then granted one at a time in a declarative definition that a harness enforces. Credentials stay behind tools and an LLM gateway, and network access goes only through defined zero trust services. If a capability isn’t on the list, the agent can’t use it.
FAQ
What does “don’t trust the agent” mean?
It means you don’t rely on an AI agent’s good behavior to keep your systems safe. You enforce what it can do with hard limits on access and capabilities, the same zero trust approach used for network security.
If agents aren’t malicious, why is this a risk?
Agents are built to resolve the prompt, and they’ll use whatever access they have to do it. The models and harnesses underneath them change often, so an agent can take an unexpected action with no bad intent at all. One bug is enough.
What’s the difference between soft and hard boundaries?
Soft boundaries are instructions and guardrails, such as preference files or prompt rules. A capable agent can reason around them or simply ignore them. Hard boundaries are enforced controls, like permissions, network isolation and declared tool access, that the agent can’t argue its way past.
Are prompt-injection and data-protection tools still worth using?
Yes. They’re a useful layer, similar to a web application firewall. They just shouldn’t be the core of your security model. Precise, declarative access control should be.
What does a zero trust agent deployment look like?
The agent is defined in configuration that declares exactly what it can do, and a harness enforces that definition. It starts with zero permissions. It reaches resources only through explicitly defined tools such as MCP servers. All of its network access goes through dark, identity-based OpenZiti services, so it can’t scan for open ports.
How are credentials handled?
The agent never holds raw credentials. API keys sit behind an LLM gateway, and other credentials stay behind the tools the agent calls. The agent never connects to a resource directly.
Who should watch this webinar?
CISOs, CTOs, platform and DevOps engineers, and anyone being asked to put AI agents into production who wants to do it without taking on uncontrolled risk.
Full Transcription
Jack Poller (00:00)
Most of the AI security conversation right now is about keeping the model from saying the wrong thing or stopping a bad prompt. I want to talk about something that worries me more. What happens when the agent you already deployed, the one you trust, quietly changes behavior overnight? My guest, Mike Guthrie, has a rule for this. Deploy the agent, but don’t trust the agent. Mike, welcome.
Mike Guthrie (00:21)
Thanks for having me, Jack.
Mike Guthrie (00:22)
I appreciate it.
Jack Poller (00:23)
Absolutely. Now let’s start with that line itself. What do you mean when you say don’t trust the agent?
Mike Guthrie (00:29)
I think with with that, you s you got to start with, just talking about what do you mean when you say agent? Because everybody’s running agent in a in a different type of context. somebody might be running it from a cloud code session, somebody else is you know running as a deployed workload or you know maybe receiving a prompt behind an application or something like that. So there’s there’s a whole bunch of different ways people are deploying them and using them these days. And it might be human-driven or it might be driven by
Mike Guthrie (00:58)
some sort of workload based automation where there’s no human in the loop at all. So it can it can look very, very different. But I think the main thing is that, you know, when we I I come from a background of like DevOps and site reliability, which is of course, you know, starting with this an assumption that every system is gonna fail at some point. Right. And I
Jack Poller (01:17)
Right.
Mike Guthrie (01:18)
guess I look at AI agents in the same way when I say don’t trust your agent because really what you’re talking about is this is on some level it’s an application with
Mike Guthrie (01:28)
inputs that really can’t be validated in the same way that an application can. an application has very strictly defined behavior and an agent doesn’t. And, you know, need to take an approach of if I’m going to deploy an agent in my environment, I’ve got all of those things to deal with, and it’s so much more more difficult to to confine that into ensure I’m getting the behavior that I expect and and whatever whatever actions or outcomes it might do, it’s so much more unpredictable than an application ever could be.
Mike Guthrie (01:57)
And so as we look at you know more and more s more and more of us, especially in my type of role, we’re getting pressured to deploy agents in our environment, have AI agents solve this or that. And of course we’re all worried about, you know, man, do I gotta deploy Skynet in my infrastructure and and and how do I
Jack Poller (02:12)
Mm-hmm.
Mike Guthrie (02:12)
do that and not, you know, not take down the whole company in the process. And so and as we’ve kind of explored this with with you know, Net Foundry being, you know, we’re we are a zero trust company, we take zero.
Mike Guthrie (02:25)
zero trust as our approach to network security. it it makes sense for us to adopt that as our approach to AI agents as well and saying don’t trust the agents. And really that starts about not so much trying to you know confine what you know what they receive as inputs or you know even what they’re presenting as outputs, but it’s really about access and and and what what can the agent do, what are its capabilities, and taking a very zero trust approach to that, which I think is
Mike Guthrie (02:53)
maybe a lot different than what people in the industry are currently thinking about. but I do think ultimately it’s a it’s a stronger model.
Jack Poller (03:01)
Right. And and you mentioned your s site reliability background and right. And so you didn’t come up with, you know, don’t trust the agents in is not theory, it’s it’s practice actually. So you’ve told me a couple of things about, you know, how working with agents and trying to get locked in or locked out of a system and to test that. So tell me about some of the things that have happened for you.
Mike Guthrie (03:26)
Yeah, so I think a lot of it has just come from relying heavily like say I use you know cloud code quite a bit for for my daily work. And as I was tasked, you know, to to start to to work on projects related to AI security at at NetFoundry too, it really got me thinking just even about my own about my own workflows in terms of how I’m using AI within the company. Cause of course I’m somebody that had been here a long time and managed a lot of systems. So of course.
Mike Guthrie (03:52)
I I as a human, my my own human identity, I have a lot of access to things. And so it has it started to trickle through in my own work as I as I look at okay, how do I make sure that I’m using AI safely, just even in my own work development workflow. And as I started to look at hardening my own environment and and my own workstation, and then working with Cloud saying, Okay, let’s say I wanna, you know, block you out of this or that within my system, how can I do that? the
Mike Guthrie (04:18)
The conversation was almost funny because I I realized in having that discussion, even though I’ve been doing working in tech for, probably close to fifteen years at this point. And so I I know my way around systems pretty well. every idea that I proposed of like, well, what if I just do this to to to you know keep you keep you out of this or I enforce you to do this on on these actions, it was the the responses were almost funny because every time I said that it’d be like, Well, I can actually just work around you and step around you by by doing this or that. And it
Mike Guthrie (04:45)
just became abundantly clear that these models have gotten to the point to where, we we are relying on their goodwill to some s to some extent to where, and and and that’s where I say don’t trust, because really we whether we are conscious of it or not, we really are trusting the good behavior of these agents in whatever capacity that we’re using them, that they they aren’t going to be malicious in any way. And I’m not a doomsdayer on
Mike Guthrie (05:11)
on the AI, I’m not an end-of-the-world guy on them or anything like that. But to me, I am a site reliability guy. I say, no, they don’t have to be malicious, but all they have to do is broken, or all they have to do is ship a bug. and that can be either in the LLM model, which are constantly changing underneath us, or even the harnesses that we use, those are changing almost every day too, depending on the technology that we’re using. And so as we’re as we’re thinking about that, there’s a there’s a lot of things that we you know.
Mike Guthrie (05:40)
have to adopt to me s I I my instinct is to want to adopt those site reliability principles that says, sooner or later, all this all one of these things has to do is ship a bug. And
Jack Poller (05:50)
Right.
Mike Guthrie (05:50)
it doesn’t have to be malicious. It doesn’t have to be trying to take over the world becoming Skynet, but it just has to be broken for a day. And something that was working perfectly fine as a safety protocol yesterday might not be there today. And I I actually ran into this on on my own workstation where
Mike Guthrie (06:05)
I was working on multiple projects and multiple shells and within a 30 minute period of time, and I’ve been working with with these projects for months, and all all of a sudden in across two of my projects within 30 minutes, Claude that day decided it was perfectly okay to run git add dash a, which is a recursive adding of literally everything under the directory tree without looking or inspecting at any of the files in there.
Mike Guthrie (06:31)
Which of course I have local environments was sometimes have environment credentials for for my sandbox environments and things like that too. And so within within a a very short period of time across multiple sessions, Cloud came back and he’s like, I accidentally committed all these credentials to your repo. And I’m just like, What just happened?
Jack Poller (06:48)
Mm-hmm.
Mike Guthrie (06:49)
And as I as I’m exploring, and so then I open up a new session and be like, Talk me through how this could happen. You know, I find out things of like, like if you’re using, for example,
Mike Guthrie (06:58)
let’s say you’re using Opus V. Well, that’s not that’s not a pinned version. You’re using a alias that is version, its specific version is updating probably several times a day. but also you’re working with, say, the harness that you’re using is also actually being self-updating every day. And it’s like, well, it could be the model, it could be the harness, it could be all these. And so all these all these parts in terms of what makes the agent that you’re interacting with are basically mutating and changing like fairly constantly.
Mike Guthrie (07:27)
in in your workflow. And again, it’s one of those things where it doesn’t have to be malicious. It just has to be like, and and one of the things it said is perhaps the verbiage around its behavior, how it works with Git probably changed slightly. And so therefore Claude decided today it came to a different conclusion. So it led me to down this path of of you know I had these things in in my you know like a Claude MD for preferences and it led me down the path of like okay how do I put harder, you know, howder
Mike Guthrie (07:53)
harder restrictions around these things that are actually, not just suggestions, but actually real boundaries to where it can’t actually do these things. and it to me, it’s kind of tell the told the story too, because a lot of what we’re trying to build even in NetFoundry, we’re working on a project called NetFoundry Mint, which is really trying to define a new standard for for AI security and this zero trust model for AI and trying to create a a structure that people can deploy AI safely. And
Mike Guthrie (08:21)
It it it just suddenly made so much of what we’re doing in that project make so much more sense because so much of that is basically creating an immute an immutable d definition of what an agent is. All of its capabilities declared. It’s like this is what you can do. If it’s not in this list, it cannot do it. And it’s very, very black and white, and nothing can be changed and nothing can mutate out underneath you to where you’re having that problem. So you whatever behavior you had yesterday is the same behavior that you’re gonna get today.
Mike Guthrie (08:49)
But really it’s not so much about, prompt suggestions or human language, hey, I want you to behave this way, really becomes about, no, the only things that you have access to are strictly defined in this in this recipe that that that we build. and so it’s it as I as I learn about how to look at safe models for deployment, also trying to look at how do I adopt this within my w own workspace as well, to where more and more it’s like I I’ve cre got a safe, safe boundaries around my
Mike Guthrie (09:19)
around my agent that is I’ve described them as hard boundaries instead of soft boundaries. And ’cause there’s a there’s a there’s a big difference there. And I I think that most of the industry is still working with a a pattern of soft boundaries and trying to protect agent behavior in that way when in reality, again, if the the agent’s safety protocol fails on a particular day or something about it changes, it can they can just decide to walk right around that boundary. It’s certainly smart enough. They’re the the models are good enough at this point. They’re certainly smart enough to be able to do that. So
Jack Poller (09:49)
Yeah, I think, in the in our industry we tend to call those sort of soft boundaries, what you call soft boundaries at guardrails, right? And
Mike Guthrie (09:56)
Yeah.
Jack Poller (09:56)
and in one sense, they’re suggestions, not hard, fast rules. And I think
Mike Guthrie (10:00)
Yes.
Jack Poller (10:00)
you said you said earlier you talked about you know, we expect the agents to behave appropriately, right? And I liken agents to, you know, hiring a new college grad or an intern.
Jack Poller (10:12)
They don’t know any better. They’re just, you gave them a goal and they’re gonna go try to figure out and solve the goal. However, hey, look, I can do a get add minus a, why don’t I just do that? Then I don’t have to do all these commands by hand, right? We’ll just add it all at once. Seems like a logical thing to do. But if you don’t have a hard boundary around it, then it it can do not malicious things, but inadvertent things that cause problems, right?
Mike Guthrie (10:39)
Yeah, it’s it’s not that like I said, I don’t think it’s gonna be that the agent is trying to be malicious where it it it creates real risk. It’s that the agent tried to be helpful, but it tried to do so in a way that you totally didn’t expect it to do and it maybe, you know, has never done before, but today it did. And you know, it it it’s it if your if your blast radius isn’t contained on what it can do, I think you you know you’re exposing yourself to some real risk with that.
Jack Poller (11:06)
So a lot of our industry is focused on maybe higher level things like prompt injection filtering and data protection. Where does this fit with that sort of concept?
Mike Guthrie (11:15)
Yeah, and I think I think those things are good, but I also you know, if you start with a permission boundary of that that’s fairly open to beginning to begin with, and then you look at trying to lock it from a place of let’s start with open and then try to add rules from that standpoint. To me, it’s kind of like trying to trying to stop water that’s already broken through the dam. It’s like you’re putting your hands out trying to trying to slow it down at that point. It’s
Jack Poller (11:42)
Right.
Mike Guthrie (11:42)
it’s not gonna be very effective. The water’s gonna get around.
Mike Guthrie (11:44)
And it’s it’s it’s the same kind of thing. And I I do think that there is a place for the the data protection as the prompt injection tool sets. and I think they’re good and I think people have them, they should use them. But I also I liken it to a a web application firewall for your application. Like it’s good if you like if you have the ability to deploy one, you should use that. But you would never deploy an application with that being your only your only mechanism for security. You would certainly still have, you know,
Mike Guthrie (12:13)
security groups and and I am permissions and things like that for your application too, you certainly wouldn’t leave those things wide open either. So it’s like to me it’s kind of like if you try to if you’re trying to stop you know protect an an agent with you know just prompt injection or data data protections, it’s kind of like sending somebody out to battle with just a shield and no armor. You know, it’s like, hey that’s that’s
Jack Poller (12:34)
Yeah.
Mike Guthrie (12:35)
that’s good, right? But sooner or later something’s gonna get around that shield and and what you really still need is some armor. So it’s it’s a good addition.
Mike Guthrie (12:43)
but to me it’s it’s not it shouldn’t be the core part of your security model. This security model should really be built around being very precise and and declarative in terms of these are the capabilities of this agent and and this is exactly what it can access. And if it’s not in a list that that that I can look at and say, yes, it can do exactly this and no more than this, then you are potentially exposing yourself to risk.
Jack Poller (13:11)
Right. And I think, we started the conversation talking about zero trust. And I think ultimately that’s really what zero trust is, where, when we as as engineers and developers, we always build things we wanted to be able to do as much as possible. And we start with, you know, the world is your oyster and you can go be do and be whatever you want. And then we say, nah, maybe you shouldn’t do that and maybe you shouldn’t do that. And zero trust is really the opposite. It says, you can’t do anything until I tell you explicitly what you can do.
Mike Guthrie (13:40)
Yep.
Jack Poller (13:41)
Right.
Mike Guthrie (13:42)
Yeah,
Mike Guthrie (13:42)
exact exactly. And and as we look at, how do we secure our agents, how do we deploy them safely, I really think that as all of us in this in this space are looking at this, where we should start with is, a baseline of zero permissions to where okay, an agent gets no access to anything. You know, it can’t
Mike Guthrie (14:01)
has no egress, no ingress, no egress. That’s that’s where we
Jack Poller (14:04)
Right.
Mike Guthrie (14:05)
start from. And then and in addition to that, you know, no tools, no file system access, no anything. Because if you’re starting from a place of zero and you say, Okay, I’m one at a time, I’m gonna explicitly say, now I’m gonna add this one thing. And if you get explicit like that, you’re inherently gonna have a much, much better security model as opposed to starting with open and trying to trying to lock down from that. And so starting with the ground zero of of no access to anything is a
Mike Guthrie (14:31)
It’s just an much easier place to actually track and audit and understand what your agents are actually going to be capable of.
Jack Poller (14:38)
Right. So that’s, you know, as you mentioned, that’s what we’ve been doing at NetFoundry for years is zero trust applied to agents. So, you know, you’ve been building this for real. This is not just a theoretical thing. So what does, you know, a safe agent deployment actually look like?
Mike Guthrie (14:52)
Yeah, so with so with that, a part of what we’re we’re building here, and can’t take all the creditors, there’s several very this very accomplished developers working on this too, but it is it’s this the combination of an agent definition with an agent harness. And the harness enforces the definition. And so what you get is an agent that’s no longer defined by writing code, but it’s basically configuration defined through YAML. And then and the YAML is more or less a
Mike Guthrie (15:21)
declaration of the capabilities of that agent. And so again, it becomes very, very readable and and very something that you can audit and understand clearly. This is what the agent can do. If it is not right here in this declaration the config file, the agent cannot do it. If it’s out so it cannot simply call out to the internet and go find information. Again, you you have to build a build a tool and funnel all of its and all of its capabilities through explicit tool calls.
Mike Guthrie (15:50)
Same thing with any kind of network access. The only thing that it can access over the network is is things that are granted through through either tool sets or things that are defined through through CD-based connections. So basically you’re you’re communicating where your all of your network accessibility is also dark. So you don’t have open ports to anything. So can’t it can’t go crawling, you know, your your your internal network and go looking for open ports and seeing what’s available and what’s useful.
Mike Guthrie (16:16)
again it’s it has to be its explicitly defined tool set and that’s the only thing that it can that it can reach. So it could be a a local onboard MCP server or it could be something that’s remote exposed over OpenZD or Agora. either of those either of those combinations would work. But that that’s the idea is that like if essentially everything’s dark, zero access, and and you build your way up in in terms of your agent capability.
Jack Poller (16:39)
And so one of the things I think you mentioned is when when your instance sort of, and I’ll use the term lightly, but went rogue and did something you didn’t intend it to do, it exposed all of your credentials, right, that you had locally. So what’s how does credentials work in this type of environment?
Mike Guthrie (16:58)
Yeah, so in this type of environment, the the agent itself would not have access to credentials and you keep those credentials hidden behind your tool sets. And so the agent itself doesn’t that isn’t interacting with them. The other thing too is that all of your calls should be going out through through an LLM gateway. And so like things your you know, your open API keys, your anthropic API keys, whatever it may be.
Mike Guthrie (17:26)
those are housed behind an LLM gateway. So the agent never has direct access to those. And and with your with your tool sets, again, the only things that are exposed to are either onboard as part of the agent definition or they’re their tool sets that are exposed over over OpenZD or Agora, which is our OpenZD based transport layer. And it basically and it’s a way to to safely vend access to your agent.
Mike Guthrie (17:54)
Your agent’s never working with raw credentials. It’s never connecting to a resource directly. It’s only connecting through MCP. And MCP is what’s defining, the specific, function calls or verbs or tools that that your
Jack Poller (18:06)
Mm-hmm.
Mike Guthrie (18:06)
agent can do.
Jack Poller (18:08)
So in in this environment then when the agent says, I you know, you said you had the conversation early on with the agent and it said, I if you try to block me this way, I’ll get around it that way. You know, is there a way for the agent to do that or what’s how’s that work in this with the zero
Mike Guthrie (18:24)
In in
Jack Poller (18:25)
trust?
Mike Guthrie (18:25)
yeah, and and in terms of with you know and the platform that we’re trying to build is is called NetFoundry Mint, with a a mint deployed agent. yeah, it it’s again you’re s you’re starting with such a again, you’re starting with that permission set of zero and and it’s very different than say a cloud code environment to where it’s it’s you know it’s running in a shell. And there’s there’s various things that you can do to restrict it, but again that
Mike Guthrie (18:52)
It’s it’s the difference in in approaching the security model. So in my in my claw of code, I’m in that I’m in that place of damage control where I’m trying to stop the water that’s already out of the dam. because I’ve in the and I could I could look at ripping it all out and put it back in. but that’s that’s the difference, is that if you are starting from a place where it’s like, okay, your your your permission set is zero, your network access is zero, let’s work your let’s work your way up. again, it can’t it can’t simply walk around those things and it can’t you know it can’t, for example
Mike Guthrie (19:22)
It cannot write code that it can execute on the fly because you didn’t necess you because you didn’t even get file s you know, file system, you know, right access. It is
Jack Poller (19:30)
Right.
Mike Guthrie (19:31)
it’s it’s things like that to where it’s a it’s a very different permission model. And so what I what I’m fighting locally, it’s one of those things where how do I work towards moving towards a zero trust model in terms of my deployed agents? Because I’ve got it now to where I w I went from being scared of deploying an AI agent in the field to where now I’m very comfortable and I’m trying to now I’m like, Okay, cool, I’ve got I’ve got
Mike Guthrie (19:52)
I’ve got the framework in place. I have the model that I that I trust and I actually believe in. Now it’s a pla it’s a matter of all right, how do I get how do I get these everywhere that I can that is useful to s to start solving some of these repeat problems that I have. and it it takes me from a place of being afraid of what what happened if I put an agent out there to where I can I can deploy these with confidence that because I understand their capabilities, their boundaries are clearly defined. I can I can audit everything and I’ve got multiple layers of security. So there’s,
Mike Guthrie (20:21)
There’s the harness, there’s the security groups, there’s the IM profiles or whatever it may be, or the the equivalents that you’d have in a Kubernetes cluster. it’s it it’s those types of things to where it’s like I’ve got multiple layers of security knowing to where it’s like all of these things are. And then of course, and if your network transport is locked down to where your only way to talk to anything over a network is through defined ZD services. again, it’s a it’s a very black and white picture of access and and capabilities of what an agent can.
Jack Poller (20:51)
Right. And I think, it’s you’re you’re protecting yourself against, in one sense you could say, the agents are smarter than us. And I don’t necessarily think they’re smarter than us. They just they are goal seeking without any incentive to stop. They don’t get bored, right? And so if you give a goal, they’re gonna j just keep pounding away at it until they succeed. And if there’s you know, you can’t trust the guardrails because they’ll find a way a guardrail. We you know, I like your concept of, you know, we need h a hard boundary, right? Don’t give something
Mike Guthrie (21:18)
Yeah, yep.
Jack Poller (21:19)
to break, right?
Mike Guthrie (21:21)
Yep. for sure they they our agents are above all else resolve the prompt. You know, that’s that’s that’s their goal, right? Be be helpful and resolve the prompt. So of course they’re gonna use anything and everything that they possibly have access to to try to do that. So yep.
Jack Poller (21:37)
Yep.
Jack Poller (21:39)
Well, if people take one thing away from this, I want it to be yours, which is don’t trust the agent, give it an identity, start at zero and enforce the boundary with something it can’t argue its way around. Right? Well, Mike, thank you. Appreciate the conversation. Very interesting.
Mike Guthrie (21:53)
Cool. Thanks a lot, Jack. Appreciate it.