Aegis: Rethinking Kubernetes Security for AI Workloads

I've been working on something I've wanted to explore for a while: how do we actually secure AI workloads running inside Kubernetes?

Not just the containers they run in, but also the tools they can use, the resources they can access, the network destinations they can communicate with, and the things they do at runtime.

Think about an AI agent running inside a Kubernetes cluster.

It might need to read GitHub issues, communicate with external APIs, access internal services, or interact with other infrastructure components. These capabilities are useful, but they also introduce a different security challenge.

Giving an agent access to a tool is one thing. Making sure it only uses that tool within the permissions it was intended to have is another.

And this is where I started thinking about Aegis.

Aegis is an open-source, Kubernetes-native security control plane for AI workloads, autonomous agents, and tool-enabled LLM applications.

The idea is to bring different security controls under a common, declarative model.

Kubernetes already has powerful security mechanisms. We have RBAC for authorization, NetworkPolicies for network isolation, admission controllers for resource validation, and runtime security tools for observing workload behavior.

I don't think we need to reinvent those tools.

What interests me is how we can connect these security layers and apply them specifically to AI workloads.

That's the problem Aegis is designed to explore.

I approached the project by thinking about the different capabilities an AI workload might need and how those capabilities could be controlled.

At the center of Aegis is an AIWorkloadPolicy Kubernetes Custom Resource.

Instead of managing security requirements through completely separate configurations, the goal is to describe a workload's capabilities through a Kubernetes-native policy.

This provides a foundation for defining what an AI workload should be allowed to do.

The next layer connects the policy model to Kubernetes security mechanisms.

This includes network restrictions and Kubernetes permissions through NetworkPolicies and RBAC.

The important idea is that workload capabilities should be explicitly defined rather than relying on broad permissions.

This is one of the areas I find particularly interesting.

With AI agents increasingly interacting with external tools through the Model Context Protocol (MCP), tool access becomes an important part of workload security.

An agent might need to read GitHub issues, but that doesn't mean it should automatically be allowed to delete repositories.

These are different capabilities and should be treated differently.

Aegis dynamically intercepts tool calls: allowing github.issues.read while blocking github.repository.delete with 403 Forbidden.

Aegis explores how tool-level permissions can become part of the workload's security model.

A policy describes what a workload should be allowed to do. But what happens when the workload is actually running?

This is where runtime observation comes in.

I've integrated Tetragon into Aegis to explore kernel-level visibility into workload activity using eBPF.

This includes observing process execution and relevant system-level behavior associated with AI workloads.

Attempting to spawn an unauthorized /bin/sh shell inside the AI agent container is intercepted and terminated by Tetragon with exit code 255.

I find this layer particularly important because security shouldn't stop at deployment time.

One distinction worth making: eBPF doesn't understand an LLM's reasoning or identify prompt injection directly. It provides visibility into the system-level activity that happens when workloads execute.

That visibility can help identify suspicious behavior and provide another layer of security monitoring.

There are already excellent projects solving different parts of this problem.

Tools such as Kyverno and Tetragon have their own well-defined responsibilities. Aegis isn't intended to replace them.

The interesting part is the integration.

AI workloads introduce capabilities that span several security domains: network access, Kubernetes permissions, external tools, and runtime behavior.

I wanted to explore whether these requirements could be managed through a common security model, while still relying on established Kubernetes-native technologies for the underlying controls.

Aegis already has its core implementation and Kubernetes foundation in place, including its custom resource, Go controller, and runtime observation integration.

I've been developing it incrementally, and the next improvements are focused on extending its lifecycle and operational capabilities.

Some of the areas on the roadmap include:

These are extensions to the project, not a reason to wait before exploring or using its existing implementation.

I built Aegis because I wanted to work on a problem that sits at the intersection of Kubernetes, cloud-native security, runtime protection, and AI infrastructure.

It has been a good opportunity to go deeper into Go, Kubernetes controllers, CRDs, eBPF, and the security challenges that come with tool-enabled AI applications.

There are still plenty of interesting engineering problems to solve, and I'm looking forward to exploring them.

I'm sharing Aegis publicly because I'd like to get feedback from people working in Kubernetes, security engineering, and AI infrastructure.

If you find the idea interesting, have a different architectural approach, or spot something that could be improved, I'd genuinely like to hear about it.

👉 Explore Aegis on GitHub: https://github.com/KhalidNazih/Aegis

If you're interested in this space, feel free to follow the project. More technical deep dives and implementation details will follow.