TRANSCRIPTION 🔗
speaker-0: AI agents are becoming part of our working lives and helping us accomplish more and more every day. They've been put to use quickly, even by the speedy standards of the tech industry. And while agents hold great promise, we should also have a solid grasp of what they are and how they work before handing them the keys to our most sensitive systems. Today we have Derek Carr, Senior Distinguished Engineer here at Red Hat, to talk about the inner workings of AI agents and how much has changed. Less than a year. Welcome to Technically Speaking, where we explore how open source is shaping the future of technology. I'm your host, Chris Wright. Hey Derek, great to have you here today. Thanks for joining.
speaker-1: Thanks, Chris. Good to be here.
speaker-0: So we'll we'll spend some time digging into agents, we'll we'll demystify. But before we get there, this isn't the first time we've been talking about agents, and and I've joked, transitioning into this year. This is the year of agents again, this time for real. but it's less of a joke now. It is quite real. There there's a lot of conversation and even a lot of activity, so much activity that it feels like by the f time you finish talking about agents, the technical landscape has changed. So before we dig in, there there's a lot happening. How how are you managing to keep up with all this stuff as a as a person who's mastered the nuts and bolts of of what agents are?
speaker-1: Yeah, it's not easy. So as you said, my my background has been in the Kubernetes and broader CNCF, ecosystem for probably the last decade or more. And traditionally I've been trying to think about how do we support all the world's possible computing applications on things like Kubernetes. You know, in the beginning that was dealing with things like distributed web applications, then moving to stateful workloads with databases. and eventually to things like performance sensitive applications and package processing and telco. I think what has been interesting is in the last few years the emergence of of a whole new class of application, like an agent. What is it? How do you treat it? How do you control it? How do we evolve platforms like Kubernetes and the adjacent ecosystems to go along with its development process? I see the way we build software is changing, right? You had Static apps, very deterministic, you understood what they were going to do, and you had existing ceremonies to deploy them into production. the world is changing, right? We're leaning on more AI agents to write our code. Sometimes that code is written live on production systems and run without ever being reviewed, right? And and in in that in that operating environment, what do ecosystems need to provide to run these things securely with appropriate policy and oversight? So for myself, my interest was basically asking hey, how do we responsibly operate this type of software? What types of primitives are missing across the industry to support that?
Load full transcript
And that led me into working together with some of our friends at NVIDIA on a new agent sandboxing project for Open Shell. And then from that, having to learn what agents actually are attempting to do. And then from a security standpoint, how do we actually control that, constrain it, and not diminish their power at the same time?
speaker-0: I guess it begs the question, what is an agent? it it's a it feels like a buzzword at times. It it's not always clear exactly what agents are. I so th there's there's an LLM involved, there's some code involved. How would you define an agent?
speaker-1: So at the end of the day, an agent is an application. it does lean on AI to achieve a goal, but the way that that application runs is different. So oftentimes you'll hear folks say, Well, well, what's the brain behind your your AI application? And in that case, it's, what is the model you're using? you might hear terms like LLMs, and things like inference, which is just a fancy way of describing how your application speaks to that model. And then you you depend on your brain to kind of tell you what what should be done, right? But a brain alone is not too powerful. You need you need hands to give agents agency. And so from that standpoint, an AI agent often is empowered with tools to drive an outcome. That could be doing a web search, that could be running a a shell command, that could be invoking some remote service in your company, like say an MCP server. Beyond that though, agents are evolving to have things like memory. so like Each of us, we have a particular context window we can hold about this conversation, but we also hold long-term memory and remember, our past conversations and and what we've done in our lives. Agents are kind of evolving in that same sense. You have a short-term memory, which is what your LLM is holding into context at that point in time, and then you have a long-term memory, which you might call back to to kind of reinforce your your present awareness. Finally, you'll hear about things like an agent orchestrator or an agent harness. And that's just kind of like a fancy word for basically the nervous system that stitches all of that together. What what connects the brain with the hands, what connects the hands with with the communication channels by which you can speak to your agent. but personally I I like to think in terms of of those anatomical perspectives of an agent.
speaker-0: It's certainly a a great analogy. It really brings it to to life, so to speak, and gives a real intuitive understanding of of the components of agents. maybe we could dig into how agents work. there's you know, a little bit of what agents do. You you talked about agency, we touched on autonomy. so so how do you see an agent sort of operating?
speaker-1: so there are a lot of different types of agents that people might want to operate, whether they're traditional maybe commercial off-the-self agents that we run on our laptops today, things like Codex or
Cloud or Open Code, that type of thing, or Hermes or OpenClaw. those applications have a lot of capability. They have channels, you know, the the the mechanos by which you invoke them. they have an agent loop, basically that communication flow to and from the model back to their tools. and then different capabilities around memory and that type of thing. When operating these agents, you know, typically when you're wanting to move them from a a laptop to a data center environment, you get introduced to new enterprise challenges, right? It's one thing to run things on your laptop and then no it's just you speaking to that agent. It's another thing to deploy it as a shared service somewhere in your company. And you can introduce to interesting questions. So for each body part of the agent I described earlier, you can imagine a new unique challenge occurring. So we could just pick on a few of those. So if you think about things like an agent that has tools, you want to ensure those tools are used within non-good policies. So if you give an agent the power to to access the network, you want to restrict where on the network. can speak to. If you give an agent memory, you might want to control what goes in long-term memory versus short-term memory. you might want to filter out certain conversations from other conversations, just like we want to do in our normal day-to-day life. Particularly with memory, you introduce unique data retention challenges. Like oftentimes enterprises have very unique constraints on what it means to hold data and for how long. And memory is one of those things like It's a new novel thing to think about in this space. And then finally, when that agent is, not running on your laptop and running in a in a in a corporate environment, you start to run into identity questions. So not only does an agent have all these body parts, it also has an identity, a name, right? And is that agent acting on your behalf? Is it being you, or is it a unique identified system in your company or organization? And then therefore, how do you give that agent identity? And then how do you track who it acted on behalf of? All these are interesting challenges that are coming up in this space.
speaker-0: It's pretty tempting to think of an agent as an AI enabled application. the laptop to data center question is just toss it in a container. but there's there's definitely more to it. you're describing some of the touch points into the enterprise, some of the artifacts that are left behind from agents, memories as an example, that open up new questions around what is the security boundary, what are what is trust look like in this context? The the identity question. Seems like there's some great lessons we've learned in Kubernetes, but also some important ways that we can bring agents into this application world.
speaker-1: A lot of people stuck from that perspective of I just want to deploy my agent on Kubernetes. What's different about it? What do I need to
be concerned about? traditionally, you ran a an application on Kubernetes, you gave it your secret. The process was trusted, you understood what it was gonna do. immediately once you deploy an agent, you're like, Ooh, I'm unsure I want to give my agent my keys. how do I have some degree of separation there? oftentimes the network policy that you would choose to deploy applications to on Kubernetes was not as deny by default as as one would desire in the space, nor were they flexible enough to allow you to organically evolve them based on like emergent agent behavior. so projects like OpenShell provide a nice enhancement on top of the Kubernetes ecosystem to allow you to one, have a way to describe the credentials that your agent needs. The network endpoints that that agent should be able to use those credentials to speak to, and basically policy boundaries that say, How can I communicate over the network to achieve my outcome? And then rather than having that policy fixed at deployment time, can it evolve at runtime based on the emergent agent's need? So for example, traditionally, when you deployed your application on Kubernetes and you assigned a network policy to it, that network policy never evolved, right? Because you knew what your app was going to go do. Now, once you took these agents that could express like organic behavior in response to a unexpected prompt, which might be totally trusted, right? You might be asking your agent to go and search something on your behalf. you can't have such a rigid approach to policy. And you need a way to organically evolve. what you permit your agent to do and maybe for how long you allow it to do that outcome. So OpenShell in particular allows you to basically have a flexible set of network policies that you wrap that agent with so that by default before it does something novel, you can deny it, or you can choose to be notified and approve it.
speaker-0: And the trust me here might be the the the primary agent loop considered trustworthy. It's actually code you can inspect. Yep. Launching something that's going to generate code and execute that code where you're not even sure what the code will look like before you've launched it, you might want to put in a more restricted sandbox at as an example. Is that a a reasonable way to to look at it? Yeah.
speaker-1: Yeah, exactly. So if you if you go back to our our body, brain, and hands analogy, you know, if if you can speak to your agent over something like Slack, keeping that long running gateway component running in a trusted compute zone to take incoming Slack messages, you you want that always available. And so you'd put it in that trusted sector. Now when that message is handed to your your agent harness and its main loop. To then potentially go and do a tool invocation, you would put that in your untrusted zone, right? And you would heavily policy confine and match that. As agents evolve, though, like we kind of see two classes of agents emerging, right? You have agents that have like a single process or a single trust envelope. And you have to basically black box treat it as an entirely untrusted entity. And when you do that, you can't quite leverage all of the capabilities that. that particular agent or harness might offer because you almost don't trust any element of it. so where we see the community going forward, as well as projects like OpenClaw is they're breaking up the agent into distinct trust boundaries. the parts of the agent are harnessed that can be trusted, and then the parts that need to be looked at with a sense of distrust. And as a consequence, like Rather than sandboxing the agent, you might see novel architectures evolve where agents ask to consume a sandbox on demand just when doing the untrusted action, but then being able to run the long running components of their agent in a trusted compute zone, with the appropriate least privilege one would expect in the enterprise. Some of the interesting things that are happening with these harnesses is they start to innovate with new user experience paradigms and become more of a of a multi-user system. And so as people look to deploy these agents on remote setups, you start to open up new opportunities to make them accessible to more than one user at a time. and then the interesting challenges that come forward with that, which says like, how do you restrict who in your enterprise can speak to it? How do you restrict who it can speak to in response? are really interesting, but I think the benefits are really strong. When more than one person can collaborate with an agent and see that session and the output together, you can s deduplicate the token expense that comes when we're prodding prompting every one of these agents in isolation. so it's an interesting new dynamic that's happening, particularly as you look to move these agents onto centralized infrastructure.
speaker-0: As you're going through those details, a little bit of OpenClaw connection with OpenShell, how OpenShell works. I'm reminded of the fact that these are very young projects. we're talking less than a year old, in the case of of OpenClaw, and even less for OpenShell. OpenClaw got viral attention. part of that viral attention was just Total enthusiasm around personal agents. Part of that viral attention was a negative focus on security concerns. If this thing has access to my credit cards, my identity, who I am, it and can do whatever it wants, it's it's a lot of risk. Open Shell doesn't have the same level of visibility. It's kind of a different type of project, it's deeper in the stack. but they they're they're growing into each other, and there's a real intention around. integrating them together. seems like we're at a point where it's worth stepping back with you know OpenClaw 2.0 and the OpenClaw Enterprise Architecture to think about a reevaluation of the security concerns associated with the projects. These harnesses move so quickly. I always tell
teams internally something that you thought wasn't good yesterday, you have to reevaluate the next day because it could have changed substantially. Feels like there's something Something like that happening right here.
speaker-1: agree with you that open claw was an example of an AI agent that could really do things. It showed the art of what was possible. And with that came a lot of immediate attention. And you know, as like a a long term open source contributor myself, that type of viral response can be both, you know, positive and negative. You know, people build firm opinions on an early iteration of a project before it has been able to even harden its use case. I think together OpenClaw and OpenShell maturing in a way to to support that security hardening is is very important. So if you take the two together, it it seems like it's a good moment to to to reevaluate and and ask if old biases still hold true. so in particular, as as OpenClaw itself like looks to evolve to support enterprise deployment patterns. one of the things I'm really excited about is the the project's recently announced open claw enterprise effort, right? And so that's that's basically taking open claw as you know it, but then putting in a an enterprise grade control plane around it. so you can deploy your agents with multi-tenancy, hard security boundaries, and standard agent primitives. it adds governance and auditability so you can know. exactly how your given agent was configured and how it evolved over time. You can pick and choose which harness you want to run, which model you use in which particular scenarios. And then at this point, control how you want that agent to be sandboxed using technologies like Open Shell. So I I think it's an interesting moment to to kind of evaluate both projects together and looking forward know that communities are doing what communities do best, which is leaning on each other to provide a a secure, trusted and and safe option.
speaker-0: Another great example of the power of open source communities and collaborative development. and I I like how you drew to the foreground that the importance of of evolving together, e building a sandboxing capability, absent a harness that needs to be sandboxed doesn't guarantee that your sandbox does the right thing. And obviously having a harness with no sandbox means it's uncontained. So building these things together, You drive the use case, you understand the risk profiles. something that we've experienced even internally as we've rolled out some of our own agents within Red Hat. It's really important to have concrete examples of where data is accessed, where tools are called, what needs to be protected. so I I love that vision of these two projects complementing each other and can even imagine how we evolve that into low level hardware support for. further separation, isolation and and containment as we've seen in in application architectures with separate control planes that sit in you know inside the server or you know in the AWS context, something like Nitro as a security architecture. Imagine that applied to to agents. So I think there's a lot of of potential in this space, which is important because as you mentioned, we're trusting agents to ha be autonomous and have a brain and have hands to go do things in the real world, with identities that are reflective of work that we're asking the agents to do. So we might hold some accountability. So the trust is really important here.
speaker-1: Yeah, yeah. I I think in general, as a goal, no one community is gonna have the answer to every deployment problem to getting agents running in repeatable patterns in the enterprise. And so y one community will lean on another. and then in many ways those communities will lean on advancements in hardware infrastructure to get to a state where It's more normalized for what it means to onboard a new agent in your enterprise. And it's not as much of a risk concern, the same way it's pretty normal today to deploy a new application in in your enterprise environment. until we get everybody at that same sense of shared comfort. I think everyone will be held back a little bit on wanting to roll out agents. and so as a consequence, it's really urgent that we get communities working together to you know mitigate those concerns. at both the deployment topology of physical hardware as well as the deployment of of the software that runs on top.
speaker-0: Yeah, I think that's a great observation. And we've we've seen that initial enthusiasm around personal agents with the launch of OpenClaw. we've seen hardened attempts at that from new providers all the way up through a real massive adoption from a consumer side around personal agents like like Muse. so we can see the value that's there and we can see how protection helps unlock that value and you're really working to make sure we can bring that into the enterprise and take that same value unlock into enterprise data and enterprise tasks and workflows. So I guess what you're saying is this really is the year of the agent.
speaker-1: Hopefully it is. And if it's not this year, hopefully next year and the year ahead can continue to move that line forward because there is a lot of potential here and everybody wants to unlock the capability that is is laying.
speaker-0: Well, Derek, thank you so much for demystifying and and explaining the details of of the agent landscape, confinement, security, and the architecture that will successfully bring agents into the enterprise.
speaker-1: Thank you, Chris. Great.
speaker-0: AI development is a fast-moving sector with new tools coming and going every day. Their capabilities are vast and the opportunities enormous. Like all frontier industries. There are a few growing pains along the way, especially with security. But with the hard work and years of experience brought to bear by the open source community, those projects can go from cobbled together to enterprise ready in a matter of months. Thanks for joining the conversation. I'm Chris Wright, and I can't wait to see what we explore next on Technically Speaking.