Hard Code vs. Soft Code: Securing the Agentic Era

Hey everyone, we're back here at SUSECON. I guess it must be around lunchtime because there's a lot of people milling around, but hopefully you hear us well and it's all coming out. Let me introduce you to our two next guests.

I'm going to start on my far right with Rick Spencer, who's with SUSE. That's right, yeah. Rick, I'm going to come back to you in a second.

Let me first introduce our guest of honor on this one. It's Craig McLuckie. And Craig, welcome.

How are you? Thanks for having me on. Thank you.

Rick, I introduced you first, tell people what you do with your role at SUSE. At SUSE, so I'm the general manager of engineering. That means I run the engineering teams for SUSE Linux, for SUSE cloud native products, including Rancher, including our Kubernetes distributions.

We have SUSE AI, SUSE Edge. I'm sure I'm missing something. So there's- We could look it up ...

all of product engineering. Beautiful. And Craig, give people a sense of who you are.

Hi, I'm Craig McLuckie. I'm the founder and CEO of Stacklok. I've been working in the infrastructure space for quite some time.

I was one of the founders of the Kubernetes project and bootstrapped CNCF, and I'm now doing my second startup in the infrastructure technology space. I love it. So, from Google, Tim, who was one of the other founding team members?

Of Kubernetes? Yeah. Joe Beda, Brendan Burns.

Brendan's at Microsoft, and Tim is still at Google. Oh, I've interviewed him so many times. Yeah.

Do you know who our- It's good people, yeah. An illustrious group. Yeah.

Well, that little group, they've all gone on to do great things is beyond just Kubernetes. They're all good folks. Yes.

So we're here at SUSECON, right? And look, it's not just SUSECON. No matter where you go, we're talking about AI, and the conversation, if I'm the guinea pig in this experiment the conversation has moved from generative AI, which I was having a ball with up until about November, December.

Then sometime around January, agentic AI became real in my mind, right? Because last year, though we spoke about agentic AI and agents, I played with them, and I wasn't really happy with what I got. But a light switch.

The switch turned in, as I say, January or February, and even here at Techstrong, though we cover tech, we're not a tech... I guess maybe we are. But in the last month and a half, we've turned our business around upside down with using agents and agentic.

We have folks running OpenClaw and Perplexity and of course, the Claudes and everything else. Craig, are we out ahead of the pack, or is this kind of the thing you're seeing? It's coming for everyone.

And we're at SUSECON now, and I think the kind of topic du jour is really how do we bring AI to infrastructure? And I'm a longtime kind of systems guy. I'm a geek for the kind of infrastructure technology.

And this really is promising for the first time, the ability to produce self-healing, self-optimizing, self-annealing infrastructure. And we're sort of at this cusp where the quality of service, the capabilities that are going to be derived from the infrastructure technology space, are just fundamentally more robust because we are able to now bring agents into that ecosystem. Absolutely.

Rick, I assume you've got to be seeing this as well, yeah? Oh, yeah. So, we were actually pretty early to agentics, but we came in through, we had this vision of MCP powering natural language interfaces where people would, instead of sitting in front of the GUI, clicking around Rancher or clicking around Multilinux Manager, that they would be chatting with their infrastructure.

That MCP technology and all that code base of MCP servers that we built for all of our infrastructure management tools, turns out MCP kind of became the USB plug, as somebody put it, for agentics also. So we're just being pulled right into the center of the movement for, we call it agent-assisted infrastructure management. So, I've seen a lot of stuff back and forth with MCP.

Yeah. Right? And it's funny, I guess, what was December of 2024 is when we first started really seeing MCP come out here.

And now a year and a couple of months, within three months, it became the de facto standard for how agents were communicating. Yeah. I don't know if I've ever seen something happen that a standard just arise like that, that quickly.

We spoke last, I think it was a week or two ago, the AI Foundation, which I think is like a daughter- AI, yeah ... foundation of the Linux Foundation, had an MCP event in New York that was very, very well attended. We had folks from Techstrong there.

Yeah. Why? It's a fair question.

Why has it become the standard so quickly? It's almost like, have we done our due diligence here? Have we really thought it through?

Yep. Well, I think, when I look at what the promise of an agent is, an agent is a system that can take data and turn it into knowledgeTake that knowledge, form a decision, take that decision, and create action. That's what agents do.

And so the question is, well, if I want to, for instance, deploy an agent into my infrastructure to debug my Kubernetes crash loop back off. You know, like, what would happen today? Well, something like that would happen.

Someone would get notified. They'd be operating in human time. They would look at the text on their phone.

They would then log into their console. They'd try to debug it. And, between one and three hours later, maybe they've resolved the issue.

We're now moving to a world where an agent can take on that onus, that responsibility for the person. You know, by the time you get a text, it can already have figured out the problem. If you get to a point where you can trust it, it could already have put together a remediation that you just need to accept as an operator so it can get deployed.

But for that to happen, it has to be connected. It cannot do that in a vacuum. You need to be able to connect it to the operating environment so that it can access the logs, it can access the trace, it can access the code, it can access all of these things.

But this is an unthinking, unfeeling system, so you need to be able to do that in a very controlled, thoughtful way. And that's really what MCP does. It brings a way to start thinking about that connection between this landscape of existing technologies and these agents in a way that enterprises can understand and accept, and that is very powerful.

I agree. Let me play devil's advocate a little bit. I've heard people say, "Why do we need an MCP?

It adds another layer. " And I have my own feelings on this. Well, you look like you want to say something.

But I'm going to let you guys go first. Rick's an old friend, and- Yeah, I had a visceral reaction to that. Like, what Craig was alluding to...

So first of all, the nice thing, one of the reasons that I believe that MCP took off is it's actually a fairly simple concept. It is. It's a server that you run that creates a JSON file.

And so you can actually inspect it and a human can verify it. This matters because you can have a human intelligence create your MCP server that constrains the way that the agents can interact with the system. So that extra level, that extra layer, as you put it, it's not extra, it's vital, because you can't just let an AI just run rampant over the API.

And also you need a human to be able to design. A well-designed MCP server gives the right context to the LLM so the LLM is making the right decision as they're extracting that. So that's my opinion.

I'm interested in Craig's view, though. I couldn't agree more. The way I think about it is you need to separate the world into hard code and soft code.

Hard code is the code that we run in production today. It's code that we have developed, we've peer reviewed, we've linted, we've scanned, we've run it through version control, we've unit tested it. This is hard code.

This is the systems that run today's enterprises across the world. And then you have soft code. It's the code that an AI system generates on the fly.

" Soft code is, you know, it's soft. Soft. Hence the name.

It's the name, right? So, the question is, are you as an enterprise okay with enabling an agent, an AI system, unfettered access to your API surface area using a set of permissions that were grounded and really oriented around different classes of technology? And if you're a serious enterprise, the answer's probably no.

No. You probably aren't okay with that. But that doesn't mean you can get away without actually building a narrative around a connected agent.

You want to tap into all of this power. And so I think MCP is really two things. It is telling us what the future looks like, as Rick was alluding to.

It's pointing to this world where AI native applications use these large language models as the presentation and view model layer for applications, creating amazing new experiences. But the flip side of the coin is it's also the way that you start to observe, reason about, reconcile, and control those systems' access to your existing world of data. So, let me give you my opinion, as long as we're all chipping in.

All right. Yeah. I get the feeling that the API is the wrong tool for the right job.

Because, just my own- Yeah. This is my own personal experience. A lot of times, I'll hook our agent in via an API.

Now, in larger organizations that offer APIs, they do a good job of an API hierarchy. This API only is good for this specific task. This API gives you access to this specific thing.

And from an agent point of view, I don't want to give it carte blanche across all. I only do want it to be very specific. But it gets so specific that it's like navigating a regulatory maze or something, and I can't find the right API to get the goddamn job that I want done.

Where to me, an MCP server kind of connection, from my limited experience, is it's made for working with the agent. It's... The right tool.

It's the right tool, but it requires work. I think this is the thing that people... You see a lot of blog posts like, "MCP is dead.

" Ah, that's always marketing. And there's a lot of that. It's like, no, MCP isn't dead.

It is hard, and it is hard for a reason. But it's also incredibly necessary. I agree.

Because the things that I think people are missing is we have these agents, and they're sharp tools today. In six months, those tools are going to be a lot sharper and a lot more dangerous. And so investing now to get the right capabilities, the right abstractions, the right containment apparatus in place, as agents get more intrinsically powerful and capable, is going to be very important.

You just brought up the other thing, though, is we're starting to hear a lot about security implications of MCP servers. Have we thought through the security, the lockdown, the controls? Do we need a...

What's the right word I'm looking for? Not a version two of MCP, but a further refinement of this. I would like to think you need a platform for the hosting and reconciliation of MCP servers.

You need to think through the supply chain. So, hey, it's a piece of software that you're running. Is it being built by someone reputable?

Do you have the right-- Are you actually running the server you think you're running? Is it actually performing as advertised? There's annotations in, say, MCP.

Are those actually accurate so that you can start to reason about them? Can you then apply policy as code against the MCP abstraction? Can you run it in an isolated environment so that if you wanted to provide access to an HTTP endpoint, the MCP server can be authorized to only access that specific endpoint.

All of these are considerations, and this is something that we've been working on at Stacklok with our Tool Hive project, which is basically a platform to make MCP a first-class construct in the Kubernetes environment so that enterprises can operate it at scale, dealing with authentication, authorization, observability, the supply chain dynamics, all of those kind of enterprise UKEY 101s that need to be in place. So I do think there's a lot of work to be done there, and that's something we've been very excited to work on. I agree.

I recently read, Rick, about an MCP repo. You probably have seen this, yeah? A repo.

A registry. A registry- Yes ... where you can download different...

Yeah. How do you feel about-- Because look, I think that's part of the open way, right? We tend to do that, but- Yeah ...

I've also seen people download a lot of bad software from repos. Well, that is why SUSE is pretty selective about the partners that we choose to work with and the repositories that we host it in. Right.

Which is just a blatant setup for Craig to talk about Stacklok. Yeah. No, we believe that, too.

And so we have been building a registry, a repo, recognizing that enterprises want to be very exacting about the set of tools that they can consume. So those tools need to be reviewed, scanned, hardened, signed, published in an appropriate and grown-up way. And we've been very excited to work with SUSE to make sure that as they're building these excellent MCP servers, we are in fact publishing them through our registry.

The registry. And the intent here is not to displace these, sort of like the GitHub or the completely upstream registries, but to provide a view on those registries of the set of servers that are in fact hardened, that we can refutably prove the origins of, that we have high confidence that they're not necessarily carrying malicious payload. So if you've got to upset them to do it, do it, is my advice.

I've for years wondered why we don't have, why don't we hold these registries, repos, responsible for hosting crappy code, for hosting malware, for hosting soundalike? Well, because we're not paying them. You can only hold someone accountable if you actually cut them a check.

But like- Well, there is that. You're right ... the problem is all these repos are being hosted for the public good.

And I'm not here to throw the NPM ecosystem under the bus. These are hardworking people that really care. Yeah, I get it.

But they're just not funded to- I would just say, you have to choose some humans that you can trust. Craig says these open source contributors, they're all good people volunteering their time. But as an enterprise, you have Stacklok, you have SUSE, you can be confident we're doing the due diligence to create, as he said, a view onto those ecosystems.

So yeah, I can tell Craig is objecting to the- Well, no. I think the problem is- ... to the premise of your question.

No, I get it. But here's the thing. It's time for a business model change here.

These maintainers of open source projects, these maintainers of the repo, it's no longer going to be satisfactory to say, "Hey, what do you want? " The world is riding on this. Yeah.

We've got to change the economics of this. And it's interesting because there are two things that are true. One is, I think there is recognition that this is the case, right?

And if you look at the way that Anthropic is rolling out the Mythos project- Yeah ... is a recognition that making it available to good actors first to harden the ecosystem is important. And there is a lot of work being done by the Googles, the Microsofts, the Nvidias, the Anthropics, and others to kind of harden these ecosystems, and that's one thing.

But the second side of the house here is we also need to recognize that the cost economics of maintaining software are just collapsing. These agents themselves are actually very effective at maintaining software. And I think that we will start to see the ability for an organization that really cares about this to actually use agents to start to curate the software in a much more fine-grain, accurate basis.

I love it. All right. I'd love to talk to you all day about this stuff because it's something passionate of mine.

Yeah, you better go. I got to go. We got to go.