By AI agents and MCP servers are being introduced into Kubernetes environments before the access control foundations are ready. Without appropriately scoped RBAC and policy as code, an autonomous agent with write access to a production cluster is an uncontrolled blast radius waiting to detonate. The platform engineering practices that should have been standard for two decades are now the only thing standing between safe AI adoption and systemic infrastructure failure.
In this interview on TFiR, Corey McGalliard, Engineering Manager at Akamai Cloud, walks through how his team is deploying AI tooling responsibly inside platform engineering workflows, the access control architecture required before enabling agents at scale, and where the industry sits on the spectrum from cautious read-only access to full agent autonomy.
Guest: Corey McGalliard, Engineering Manager at Akamai Cloud
Show: TFiR
Here is what every platform engineer and SRE needs to know.
Technical Deep Dive
Q: Is AI actually transforming platform engineering right now, or is the industry still figuring it out?
Corey McGalliard, Engineering Manager at Akamai Cloud, is direct on this point: anyone claiming certainty about where AI is taking platform engineering is not being truthful. What is visible is that recent AI-related zero-day findings are forcing teams to confront reliability and resilience practices that should have been standard for 20 years. The industry is not discovering new requirements; it is being forced to implement the ones it already knew.
“If anyone tells you they know the answer to this, they’re not being truthful.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Q: What platform engineering fundamentals do you need before enabling AI agents in a Kubernetes cluster?
McGalliard identifies two non-negotiables: policy as code embedded in the stack and appropriately scoped RBAC. These controls are what make it safe to allow AI agents and MCP servers to push changes into a cluster. Without them, enabling an AI agent is functionally equivalent to granting unchecked cluster access to an unknown operator. With them, the access model is no different from onboarding any other actor, whether an intern, a senior developer, or an SRE.
“Having policy as code in your stack, having appropriately scoped RBAC, these things are what’s going to allow us to feel comfortable allowing AI agents and MCP servers inside of our stacks.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Q: How is Akamai using AI inside its platform engineering workflows today?
McGalliard’s team is running two practical AI integrations today. First, AI code review acts as an additional set of eyes on every change being pushed, supplementing human review without replacing it. Second, when failures appear in the end-to-end testing stack, AI reads the logs and surfaces the relevant errors, eliminating the manual work of scanning thousands of log lines to locate a failure. Both integrations reduce engineer toil on diagnostics without granting any write access to production systems.
“We have AI reading these logs and kicking it out to us. That’s really cut down a lot of time of my engineers going, where’s the error?” — Corey McGalliard, Engineering Manager, Akamai Cloud
Q: What is kagent and how does it fit into a Kubernetes platform engineering stack?
kagent functions as an agent gateway, providing a chat interface that allows users to ask questions about a Kubernetes cluster. It connects to the cluster the agent is running on and integrates with MCP servers, while keeping the AI models and agents themselves outside the cluster boundary. This separation means kagent can surface cluster state and log data in response to natural language queries without placing any agent runtime inside the cluster itself.
“It gives you the ability to interact with agents, give it access to the cluster it’s running on and also tie into MCP servers. So it gives you a chat interface to be able to ask it questions about the cluster.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Q: Should AI agents have read-only or read-write access to a Kubernetes cluster?
McGalliard takes a deliberately conservative position here. Some teams in the industry are already granting AI agents and controllers full read-write access to clusters. His team is not. The current goal is read-only access: gaining the visibility and diagnostic benefit AI can provide without exposing the cluster to autonomous mutation. The reasoning is that the industry is still learning, and granting write access before the tooling and practices are mature introduces risk that outweighs the speed benefit.
“Let’s have read access. Let’s get the benefit out of visibility and then we can grow and learn as the industry does.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Q: How does Akamai’s platform handle end-to-end testing and failure diagnosis at scale?
McGalliard’s team has built an end-to-end test workflow that provisions a full cluster, runs a test cycle, and tears the cluster down. When failures occur, the volume of log output makes manual diagnosis slow. AI is integrated into this pipeline to read the logs automatically and return a clear summary of what failed, reducing the time engineers spend searching through thousands of log lines and letting them focus on resolution rather than discovery.
“We test our platform end to end, we’re able to build a cluster and tear it down, and the goal is to have a very clear understanding of what failed during our testing cycle.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Q: What role did KubeCon play in validating the kagent approach for Akamai?
McGalliard attributes early internal momentum for kagent to a demo his team ran the day after KubeCon the previous year. The demonstration generated enough conviction within the team to begin working on a full implementation. It illustrates a pattern common in platform engineering: conference-adjacent demos from practitioners rather than vendor keynotes driving adoption decisions at the team level.
“Day after KubeCon last year they demoed this and it was amazing. And so we’ve been working on implementing.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Resources & Documentation
- Akamai Cloud, cloud computing and platform infrastructure provider
- kagent, agent gateway for Kubernetes enabling natural language cluster queries via MCP server integration (implementation in progress at Akamai; refer to upstream Kubernetes ecosystem for current project status)
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: One thing that I’m going to ask is, which may not make sense too much is AI, you know, so talk a bit about how is AI changing, transforming, whether for better or for worse, the whole platform engineering discipline right now.
Corey McGalliard: I think if anyone tells you they know the answer to this, they’re not being truthful.
Swapnil Bhartiya: Not truthful and tell me the answer.
Corey McGalliard: Sure. I think more of it is like, what am I seeing in the industry? And the reality of it is during the keynote yesterday here, they talked about what AI and the zero day findings that we’ve seen over the last few months really highlights the practices that we need and reliability and resilience that we’ve done for, should have been doing for 20 years are just getting highlighted. And so this is true in platform engineering. So having policy as code in your stack, having appropriately scoped rbac, these things are what’s going to allow us again to basically feel comfortable allowing AI agents, MCP servers inside of our, inside of our stacks, pushing changes to it. Right. Because everything’s appropriately scoped, it’s no different than giving an intern access to your cluster. No difference to giving a senior developer access or an SRE access to your cluster. Right. And so that’s kind of the mentality is having the appropriately scoped system so that when you start enabling these services, you can feel comfortable.
Swapnil Bhartiya: How are you folks using AI, you know, internally to build a platform or of course, Akamai serves a lot of customers, so how are you also building the platform to serve AI workloads?
Corey McGalliard: So today, my team, I’ll speak from a today standpoint, right. But there’s some ideas we have that are kind of propagating, that are going to improve things. But today we have AI code reviews validating what we’re doing. It gives us a second or a fourth set of eyes on everything we’re pushing out. We have the ability to see if we see failures in our testing stack. We have AI reviewed those logs and so we test our platform end to end. We’re able to build a cluster and tear it down. And the goal is to have a very clear understanding of what failed during our, during our testing cycle, we have AI reading these logs and kicking it out to us. That’s really cut down a lot of time of my engineers going, where’s the error? Because you have thousands of lines of lines of logs and then it helps them find exactly kind of what’s, what’s going on. So those are two really practical examples of where AI is working. And then a thing that we’re working on is using a service called kagent. I’m not sure if you’re familiar with this, right. To extend the ability to have an agent interact with a Kubernetes cluster and have someone in a more of a support role be able to ask you questions, hey, what’s wrong with this cluster? Can you give me feedback to this cluster? And that’s all really, really new and very, very well. And the challenge we worry about is being well scoped, having appropriate rbac, right? We don’t want it to touch the cluster. We just want it to be able to give us information out of the cluster at this point. And I think that’s kind of where a lot of people are sitting, right? Like some people are really bullish and they’re like, let’s go ahead and put controllers and agents inside the cluster and let it have read write access. I’m more conservative in saying let’s have read access. Let’s get the benefit out of visibility and then we can grow and learn as the industry does.
Swapnil Bhartiya: And what is key agent mission, kagent.
Corey McGalliard: How do I explain this? It’s basically, I want to call it an agent gateway, right? It gives you the ability to interact with agents, give it access to the cluster it’s running on and also tie into MCP servers. So it gives you a chat interface to be able to ask it questions about the cluster.
Swapnil Bhartiya: It kind of becomes a bridge between agents and MCP server so that the
Corey McGalliard: agents and the models all run outside the cluster. And it just gives you the ability to say, here are my logs, go look at it. Well, here. Yeah, no, I’m probably explaining that poorly. I’ve got very, very smart group of people who work with me and day after Kubecon last year they demoed this and it was amazing. And so we’ve been working on implementing.
