Identity, Egress, and Credentials for AI Agents

Identity, Egress, and Credentials for AI Agents

Nov 6, 2026

Guest:

  • Christian Posta

AI agents can be used to rapidly diagnose incidents, but if they are given direct access to the production systems, then you've introduced a new privileged actor that can potentially go around all the controls

Christian Posta (Global Field CTO at Solo) makes the case that agents shouldn't be given credentials, API keys, or passwords.

In this interview:

  • How observability signals, audit events, and CI/CD changes should be correlated during incident diagnosis

  • Why AI should diagnose problems before it is allowed to change routing or security policy

  • How workload identity, on-behalf-of identity, and strict credential separation limit agent privileges

  • Why service meshes need to evolve with sandboxing, egress controls, and agent-to-agent communication

Subscribe to KubeFM Weekly

Get the latest Kubernetes videos delivered to your inbox every week.

or subscribe via

Transcription

Bart Farrell: Christian, welcome to KubeFM. For people who don't know you, who are you, what's your role, and where do you work?

Christian Posta: I'm Christian Posta. I'm the Global Field CTO at Solo.io, and I've been focusing on agentic infrastructure, security, and networking. All the agent stuff for the last few years, but before that with API gateways and service mesh and that kind of stuff.

Bart Farrell: If AI is helping troubleshoot a Kubernetes incident, what evidence should you correlate before making a recommendation? Which signals are easiest to misinterpret?

Christian Posta: It's going to depend a little bit on the problem that we're investigating. But for example, if a deployment didn't turn out well, or if an app starts randomly giving 500s, you want to look at the standard observability signals, logs, metrics, traces. You'll definitely want to correlate things like access to the system, changes, especially in your CI/CD pipeline, or other auditable events and then things that are easy to misinterpret. The agent is going off of probability, so it'll look in logs and it might find errors or telemetry signals that indicate errors, which might not be the core cause, but might be some symptoms to look into or might be completely red herrings. But that's why the AI going through and trying to figure out where to rule things out is very helpful to humans, because otherwise those things could take a lot of time and have in the past.

Bart Farrell: Now, where should the boundaries sit between AI diagnosing the problem and actually changing production traffic, routing or security policy?

Christian Posta: I think you should start with AI not changing routing, security policy, that kind of stuff. What we should do is leverage AI to accurately and quickly diagnose when things go wrong. I think getting access to those systems without making changes is the first step. The second step around making changes, especially in regulated environments, you have to follow the same controls that are in place for making those changes. Requesting privileged access and having approval processes. You can't circumvent that right now just because of AI. There are, at Solo, we build infrastructure to focus on that specific problem. We work with customers all the time in regulated environments to build authorization controls so that AI can, under the supervision of humans, potentially make changes to production and things that could be risky.

Bart Farrell: As teams start giving AI agents access to infrastructure and operational tools, how do you prevent an agent from becoming a new privileged actor that can bypass the same controls humans have to follow?

Christian Posta: We have a pretty interesting opinion maybe here at Solo.io. What we've been working under with our customers, which is you don't give agents access to anything. You don't give them credentials. You don't give them API keys, passwords, secrets, any of that stuff. You give them an identity and maybe if a human is involved, that can be represented as an on-behalf-of identity. But then when the agent is trying to do something, because it will need to make calls to systems that require some authentication and authorization, then any of that is applied as policy based on their identity. If there are credentials that you need to access external systems, they can be acquired or injected transparently to the agent, but the agent never holds those keys. The agent can't do anything unless it goes through an approved path that has authorization, has policy, potentially humans get prompted to intervene and decide on this is a risky operation, what kind of approval does it need? The agents have, or at least that's the approach that we've been taking, is that the agents have that strict separation between what it can do in the system and how it acquires credentials to be able to do that.

Bart Farrell: You've spent years working with service meshes like Istio to manage traffic, identity, and security between microservices. Now that AI agents are communicating with LLMs, MCP servers, and other agents, where does the traditional service mesh model start to break down? What needs to change to make that infrastructure ready for agentic workloads?

Christian Posta: That's an interesting question because what we see from the agent side: we treat the workload. With the service mesh side, what we've historically done is protect the service, the API that's being called. We can apply authorization policy about workload identity and user identity and that stuff for the service. We were protecting that. On the client side, we did helper things: how do we do load balancing a little bit better? Could we implement circuit breaking to protect the service, but from the client's perspective and so on. But agents shift that to now the actual workload, the agent itself is an untrusted thing. Now whatever it does, we do want to lock down the egress from the client, which is something the service mesh didn't really focus on. But both sides are part of the same coin. An agent, once it gets access to things outside or in threat scenarios where maybe it's somehow bypassed its sandbox, what can it access? You need that other side. You need to protect the service still, or even more now, I would say. The things that need to evolve from the way we looked at things in API Gateway and service mesh land is now focusing on: sandboxing, egress controls, identity as a first-class citizen, credential injection, credential brokering, that kind of stuff.

Bart Farrell: Christian, what's next for you?

Christian Posta: We're heads down here at Solo solving a lot of these problems. As we get organizations into production, new problems crop up, the models get better, the infrastructure that we're building gets more demanding, cross-boundary auth and discovery and permissions, all that stuff becomes very top of mind. We're heads down. We got some announcements coming up, of course, at KubeCon. Happy to share more.

Bart Farrell: If people want to get in touch with you, what's the best way to do that?

Christian Posta: LinkedIn, CE Posta. On LinkedIn, I'm in Discord channels for our open source projects, Agent Gateway, K-Agent. I'm in the CNCF Slack channels. Any of those would be appropriate.

Bart Farrell: Good. Relatively easy to find. Thanks so much for sharing your time and knowledge with us today and I look forward to crossing paths with you at KubeCon. Take care.

Christian Posta: Thank you, Bart.

Subscribe to KubeFM Weekly

Get the latest Kubernetes videos delivered to your inbox every week.

or subscribe via