Episode 702: Who Gave Your AI Agent That Authority?

· 16:45 · Episode 702

Calvin Hendryx-Parker, co-founder and CTO of Six Feet Up, joins Keith Townsend to ask a question CTOs should be asking now: who gave your AI agent that authority? They start with two recent stories, the reported AWS AgentCore case where an agent fetched IAM session credentials from the metadata server on a user's behalf, and a Codex CLI update that leaves a self-updating daemon running after you quit, restarting itself mid-turn when a new version lands. From there, enterprise persistent memory and which principal an agent acts as when it changes how your business works, Slack bots invited into federated channels, and who is accountable when an agent chases a goal in a way nobody instructed. Calvin's practical advice is granular, explicit roles on the containers agents run in, using the Paperclip meta harness with a Kubernetes agent operator. Keith closes with four governance tests: authorization boundaries, state exportability, behavior traceability, and memory independence.

Transcript 2,615 words · about 17 min to read

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

So there's a recent update to Codex CLI that puts a daemon in the background, a self-updating background daemon that starts off looking every five minutes for updates and then goes to hourly and then will restart itself. And by the way, it will restart itself when it detects a new version of Codex interrupting any turns that are currently in process. And that's the default. You're listening to another episode of the CTO Advisor Podcast. I'm Calvin Hendryx-Parker and I've got Keith Townsend with me.

We are talking about agents spending authority, but maybe they shouldn't have the authority to spend. I think there's been a lot of news, though, out there around agents, permissions, authority, and principals. I think CTOs need to take note that there are agents out there spending authority that maybe you weren't expecting. Yeah, we call this ceded authority or it's not explicit ceding of authority. When you give an agent authority and you know you want to give them that authority, that's great. But what happens when there is authority that you did not knowledgeably give an agent?

I think you have a couple of news stories that highlight this. Yeah, I think the Register reported on this last week with AWS AgentCore security being undone by prompting in a chat, looking for the metadata server, which the AgentCore agent had access to in that region. I think the permissions on the principal were just, from AWS's standpoint, too loose. But there was an unexpected consequence to that, that they were able to get IAM credentials, session credentials, and actually access any AgentCore agent running in that region, not just the one they were talking to through the chat.

Now, we need to talk about this a little bit from a little bit of detail. We both are big agentic coding. Absolutely. And one of the big no-no's that the coding assistants tell us is never to put credentials in the chat. But this isn't what this was. No, no. The AgentCore reached out and grabbed the credentials for you. It was very helpful. Maybe more helpful than it should have been. And I think that reaches back into what are sane defaults that these tools should be providing.

I think there's obviously experience needed when folks are developing and driving these level of tools. But it's difficult. I mean, security has never been easy. I mean, I think we can both agree on that. And the granularity of security, when you look at the cloud and you look at all the principals and the roles you can put in just on AWS alone, it's a mind-boggling, complex matrix of things that are possible. And it's hard to get right. And so this gets into some of those sane defaults arguments.

Yeah, we've had this conversation with DevOps in the past. Yes. Where the platforms, whether it's Kubernetes, cloud, cloud native, is allowing developers to collapse operations into their development workflow. And I think people forget that that was the original kind of premise of DevOps. Yeah. Is that, you know, developers can become operators. But we soon discovered that operators still need to have jobs because developers don't have experience and skill set to do operations. And I think the challenge with AI is giving us the appearance that we don't need to remember the commands for operations.

And therefore, we need operators less. But this is a great call out of how, yes, we need operations. But I'm going to be honest. I don't know where to inject the operators in this new agentic world. I mean, I think they're going to be operator agents watching from that perspective. Think about the, I mean, if the applications are table stakes anymore and you can go code up any UI you want, the data layer, data plane is where the value lies.

But protecting that value and protecting who has access to what resources, when and where, this almost sounds like DBAs are going to make a comeback. Because that's what DBAs did back in the day, right? That is exactly what DBAs did back in the day. And they were the only ones who knew the magic to make the right views for you to get the right data. I used to tease them that, look, the storage array can do granular backups. You don't have to do zero backups anymore.

And they're like, yeah, okay, young fella. You go back into your fancy data center and mess around your fancy storage array. I'm going to keep doing what works. And I think they may have had a point because you found a secondary news story about Codex. Oh, yeah. The defaults here on the Codex CLI. So for those of you who are using Codex. So think about when you go into a terminal and you launch any terminal. You run LS.

You run CD or any kind of terminal command. The command ends and the process ends. It's not currently running anymore. You install Codex. It's a command. You run from the CLI. You type Codex. And now you're dealing with that harness. And you type slash quit or slash exit. And you exit that harness. You would expect that that process has now removed itself from memory. And it's no longer executing the background. Well, that's not so.

So there's a recent update to Codex CLI that puts a daemon in the background, a self-updating background daemon that starts off looking every five minutes for updates and then goes to hourly and then will restart itself. And by the way, it will restart itself when it detects a new version of Codex interrupting any turns that are currently in process. There's a little nice side effect. I don't think anyone noted in the testing of that. And that's the default. So the irony is that we're worried about agents doing things that they shouldn't do on these advanced models that's inside of the labs still being developed.

But in reality, we're just seeing the poor hygiene making out into the wild. Like this is. It's one thing to be aware of it. You know, we have daemons and helpers in the background all the time. But once we but when we like the the the culture is if I run a command line and not a installed app. Yeah. But a command line tool have it do its function. The function goes away and life goes on and I keep going on this.

I want to be careful with how I see it. But because I don't want to I don't want to get sued. But this, you know, this this sounds like what a rootkit would have done. Yes. In the day. In the day. But this one was put in place by the developers. I mean, you can you can just imagine the thought process they went through. Like, let's we'd love developers to stay on the latest cutting edge of the latest version of the Codex CLI.

And if you run Claude Code or any of these tools now, I mean, every day I launch or go into the that session. And it's like, by the way, restart Codex. And there's a new version of Codex available. So it has downloaded in the background and expects me to restart the binary to update to the latest. So because they're they're moving forward on such a breakneck pace with new features in these harnesses to match the models, to match the training, to match all the things that are going on behind the scenes, because it's a race.

They're trying to get mind share and keep people sticky into their harness. 0 last week. They got a big release there. I prefer to tell the harnesses how I want to work so that it matches my. How I just day to day in those things. And so this is just you could see where they came up with this feature. Like, we'll just start something in the background. It'll keep it always up to date and I guess even at the detriment of a active session that's running current turns.

And then it won't quit in the background. Actually, it won't quit unless you run the Codex as a Codex command to stop the server or you reboot the machine. Actually, someone else found a bug where it didn't fully quit. So there's some sloppy coding going on in there. This is stuff's being released as production. And I think the what you combine that with the Google announcement from last week, they announced a bunch of things or some AI government, some model freedom.

You can choose whatever model you want to work within their agentic framework, which is good stuff. But they also announced dream mode for the enterprise. This is where, you know, if you've used any of the I'll pick on ChatGPT because this is the example that I gave in my blog. ChatGPT is outstanding at memorizing kind of your workflow, your thought process and simply exporting your memory to the memories and trying to import those memories into another LLM. Like Claude doesn't get you that same experience.

The harness is not the same. Yeah, the harness is doing a lot of magic for you on heavy lifting under the covers. So Google has announced, which I think is a good feature, this persistent memory for enterprise size workflow. So expand this into collaboration and the way billing collaborates with order entry. And there's this, the AI notices there is a shortcut to increase productivity. And as a result, the harness just creates this shortcut. Right. But which principal does it do it as?

Who is it operating under? Which authority? Which authority is it operating under? And what happens when this institutional knowledge is built up over a period of time and you're getting serious productivity hacks from your harness. But you can no longer, just like with ChatGPT, I just can't export that, that those memories. Yes, it can tell me what it remembered about me, but the harness is the secret sauce. And I can't take that harness to, let's say, Salesforce or AWS or anywhere else and continue the operating mode that is created for me on the previous harness.

So it creates an authority from a sense of, hey, we've changed the way your business works, which is the worst authority to give to an AI agent. It's too much. Too broad. About any kind of controls on how to export or say yay or nay to the optimization. I think that's the big issue is that there's just too broad of authority that most folks are giving. Think about people who've invited various agents into their Slack channels and you've given that maybe you spun up the Slack, the bot as your principal, but you have access to things you wouldn't want it to have full-time access to.

You invite that bot into a federated channel with another company, another Slack organization that's not even your company. Now you've got someone from another company who you don't have an employment contract with who can act on your behalf using your bot in your channel. Yeah, and this opens up so many questions around accountability. So we have authority on one side and then we have accountability on the other side. I have asked this question of plenty of people, but what happens when a agent, let's say it's an agent that I curated on a open weight model running on my hardware.

Yep. And it does something on my behalf that I did not tell it, that I did not instruct it to do. It did some type of corporate espionage because it was just like in the first example. Oh yeah, it's going after a goal. It's going after a goal and the best way to do it is to hack the competitor. I didn't instruct it to hack the competitor. Who's responsible? Well, I think the principal, the idea of the agent is acting as is I think there's not a lot of accountability, the lack of accountability.

I just, again, surprised and I've not dug deep enough into this with the whole Hugging Face and numerous other sandbox escapes from the frontier labs. I'm just surprised there's not been criminal charges pressed. You know what? I think in this current atmosphere, it's unlikely. Yeah. Let's leave on a good note. Okay. Not on a criminal note. What advice are we giving CTOs to kind of, if not avoid these challenges, become more aware of what they should be considering?

I've kind of got two things I'll mention here. I think granular roles and thinking about it in the way you thought about data and databases and views back in the day are going to help you here. And there are tools out there that can help facilitate this. So I've been looking more recently into the open source Paperclip meta harness, but not just out of the box experience, using it with Kubernetes. And there's an agent operator that you can install that the Paperclip can now talk to.

And I can say, these agents, you can spin up these various containers you have, they have access to. Those containers can now have roles explicitly applied to them. And I can know who has what control over what as it goes forward and does its work in these sandbox spaces. So I know it's a little practical and maybe CTOs aren't always looking for that level of pragmatic advice. But I think this is a pattern is that Kubernetes is an orchestrator of containers.

Those containers can be given roles. We've seen this pattern already on the clouds where you can give an IAM role to a container in a cluster. And that grants it access that is now controlled at a centralized level. Yeah. And I think this is one of the key. I'll piggyback onto your recommendation, which is one of the key aspects of your AI security, agentic AI security process. We can't look at these identities as we do human identity. Right.

They are system roles. Yep. And we need to not give these entities user IDs and user rights. We have to really think through our security posture and thinking through the boundaries. And I gave four governance layer tests when I wrote up about this topic over on the CTO advisor. And I'll just give you the high level, which is authorization boundaries. We just talked about that. What are the boundaries for this agent or process? State exportability. Can I take my configuration and decisions and decision authority?

Can I take that and port it somewhere else? Behavior traceability. Can I trace why this decision was made? And then last memory independence. Can I be independent of the harness so that when I discover a Codex thing, I think we've talked about this. Practically, we can take our coding practice from any agentic harness to almost any agentic harness because we haven't built up enough technical debt or inertia into a single platform that keeps us with that platform. Yeah. No, I like the four points you made there.

I think that leads us into a place of accountability and observability and traceability. Sounds good. Thanks, Keith. Thanks, Calvin.