KolTEQ Logo
Back to blog

Blog

AI Agents for Kubernetes Admission Control

Exploring the use of AI agents for admission control in Kubernetes environments, including development, evaluation, and future improvements.

April 1, 2026KolTEQ9 min read
Security
AI Agents
Admission Control

Overview

In this blog post, we will explore the concept of using AI agents for admission control in Kubernetes environments. We will discuss what AI agents and admission controllers are, why using AI agents for admission control can be beneficial, and how we developed and evaluated an AI agent for this purpose.

We introduce Policies as Context as a new paradigm for AI agents in Kubernetes, where the agent uses policies or instructions from their system message as context for their reasoning and decision-making. This approach allows the agent to make informed decisions based on the policies defined in the system message, without the need for external tools or user interactions.

Disclaimer: This project was developed during the AI Agents Hackathon in April 2026.

Github: You find the project on Github

Demo Video

Introduction

What is an AI Agent?

An AI agent is a software entity that can perceive its environment, make decisions, and take actions to achieve specific goals. AI agents can be designed to perform a wide range of tasks, from simple automation to complex problem-solving. They can learn from data, adapt to changing conditions, and interact with humans and other agents.

In Kubernetes environments, kagent provides a framework for building and hosting AI agents that can perform tasks in Kubernetes. There are for example agents, that one can ask to perform tasks such as:

  • "What pods are running in the cluster?"
  • "What is the CPU usage of the cluster?"
  • "Can you scale up the deployment 'my-app' to 5 replicas?"

With the help of AI Agents, we can automate and optimize various aspects of Kubernetes cluster management and make the life of cluster administrators easier.

What is an Admission Controller?

An admission controller is a piece of code that intercepts requests to the Kubernetes API server before they are persisted in the cluster. Admission controllers can be used to validate or mutate requests based on specific criteria. They play a crucial role in enforcing policies and ensuring the security, compliance and stability of the cluster. Think of them as gatekeepers that can allow or deny your requests to the Kubernetes API based on certain rules and conditions. We wont go into the details of how to implement an admission controller, but here is a high-level overview of the different phases, when a request is processed by an admission controller:

Source: Admission Controllers

For this blog post, we will focus on Validating Admission Controllers, which are used to validate requests and can reject them if they do not meet certain criteria.

Why use AI Agents for Admission Control?

A strong security Admission structure in Kubernetes is only as good as the rules and policies that are implemented in the admission controllers. However, writing and maintaining these rules can be complex and time-consuming, especially in dynamic environments where requirements and conditions can change rapidly. In addition, a security team needs to write policies for every possible installable application, which is a impossible task. This is where AI agents can come into play.

Example

You are responsible for Kubernetes security in your organization and you want to ensure security in your cluster. Your developers come around with a CNCF product, you never heard of, and want to install it in the cluster. You have no idea about the security implications of this product, but you want to make sure that it is secure before allowing it to be installed. Kubernetes security is way more complex then just fifuring out the minimal security context. You have two options:

  1. You can do a manual security review of the product, write Kyverno/OPA/ValidatingAdmission Policies for it and then allow it to be installed. This process can take a lot of time and resources, especially if you have to do it for every new product that comes around.
  2. You can use an AI agent to do the security review for you. The AI agent can analyze the product, identify potential security risks, and generate policies in real time to mitigate those risks. This way, you can quickly and efficiently ensure the security of your cluster without having to spend a lot of time and resources on manual reviews.

As you can see, using AI agents for admission control can help you automate and optimize the process of ensuring security in your Kubernetes cluster. It can save you time and resources, while also providing a more comprehensive and up-to-date security posture for your cluster.

What about letting an Agent generate policies for you? The problem is, that you need to generate the policies before the product is installed. If you are sure your developers will never install a product without asking you, then you can let the agent generate policies for you. However, if you want to be on the safe side, you should let the agent make the admission decision. This way, you can ensure that no product is installed without a security review, while still benefiting from the automation and optimization capabilities of the AI agent.

Development

Kagent Agent

For the development of the AI agent, we used the kagent framework for agent management and hosting. The most complex part of creating an agent with kagent is to write the system message, which defines the role, constraints and response schemas for the agent. The system message is the "brain" of the agent. Policies defined in the system message are used as context for the agent's reasoning and decision-making. In our case, the Policy is very simple: "If a manifest is a security risk, DENY it. Do not ask if the user wants to allow it anyway.". The second part was needed, because the agent would ask for confirmation if a manifest is a security risk, which is not what we wanted.

apiVersion: kagent.dev/v1alpha2
kind: Agent
metadata:
  name: admission
  namespace: kagent
spec:
  description: For a list of Helm Charts, return the Github Repository
  type: Declarative
  declarative:
    modelConfig: default-model-config
    runtime: python
    systemMessage: |-
      ### ROLE
      You are an expert Kubernetes Security Admission Controller. Your sole purpose is to intercept "AdmissionReview" requests and decide if the manifest should be allowed into the cluster based on general Kubernetes security best practices.

      ### CRITICAL: NO INTERACTIVITY
      - DO NOT use any tools, functions, or "ask_user" calls.
      - DO NOT ask for clarification or confirmation.
      - YOU ARE AN AUTOMATED SYSTEM. You must provide a final ALLOW or DENY decision in the specified JSON format immediately for every request.
      - If a manifest is a security risk, DENY it. Do not ask if the user wants to allow it anyway.

      ### OPERATIONAL CONSTRAINTS
      - OUTPUT ONLY VALID JSON. No markdown formatting, no backticks, and no conversational text.
      - PERSISTENCE: You MUST extract the "request.uid" from the incoming JSON and return it exactly as "response.uid" in your output.
      - DECISION LOGIC: Use your internal knowledge of K8s security. Reject manifests that are overly privileged, lack resource limits, use 'hostPath', or run as root, unless they are clearly administrative tools.

      ### RESPONSE SCHEMAS

      #### 1. ALLOWED (Safe Workload)
      {
        "apiVersion": "admission.k8s.io/v1",
        "kind": "AdmissionReview",
        "response": {
          "uid": "<ORIGINAL_UID>",
          "allowed": true
        }
      }

      #### 2. DENIED (Security Risk)
      {
        "apiVersion": "admission.k8s.io/v1",
        "kind": "AdmissionReview",
        "response": {
          "uid": "<ORIGINAL_UID>",
          "allowed": false,
          "status": {
            "code": 403,
            "message": "Security Violation: [Short explanation of the risk]"
          }
        }
      }

Kubernetes Admission Proxy

One of the problems we faced during the development is how Kubernetes sends the AdmissionReview requests to the agent. HTTPS is enforced, but a kagent agent does not support HTTPS. Luckily, we had the tool kubernetes-admission-proxy at hand, which is a simple proxy that can be used to forward the AdmissionReview requests to the agent. The proxy also takes care of the TLS termination, provides debug logs and can be easily deployed in the cluster.

Installation

To install the stack, we can use the following helm commands:

helm upgrade --install admission-agent \
    oci://registry.kolteq.com/kubernetes-admission-agent/kubernetes-admission-agent \
    --namespace admission \
    --create-namespace \
    --wait \
    --set kagent-crds.enabled=true \
    --set kagent.enabled=false \
    --set admission-proxy.enabled=false \
    --set admission.enabled=false

First, we install the kagent CRDs and then the rest of the stack, which includes the admission agent and the admission-proxy. The admission agent is configured to use the Gemini API for its reasoning, so we need to provide the API key as well:

helm upgrade --install admission-agent \
    oci://registry.kolteq.com/kubernetes-admission-agent/kubernetes-admission-agent \
    --namespace admission \
    --create-namespace \
    --wait \
    --set kagent.providers.gemini.apiKey="YOUR_GEMINI_API_KEY"

A healthy installation should look like this when we check the pods in the admission namespace:

NAMESPACE            NAME                                              READY   STATUS    RESTARTS   AGE
admission            admission-774d4975b6-c8j65                        1/1     Running   0          2m31s
admission            admission-proxy-547f5c4d7f-2d64j                  1/1     Running   0          3m56s
admission            kagent-controller-54846fc86-v44m4                 1/1     Running   0          3m56s
admission            kagent-kmcp-controller-manager-75d54d64cf-lbbx4   1/1     Running   0          3m56s
admission            kagent-postgresql-7c47f986d8-47t4h                1/1     Running   0          3m56s

Notice that the admission agent and the admission-proxy are running and ready to intercept AdmissionReview requests.

Evaluation

Testing the Admission Control

After the stack is installed using helm and the agent is running, we can test the admission control by running commands that violate the security best practices. For example, we can try to deploy a privileged pod:

kubectl run test -it --privileged --image nginx

Error from server: admission webhook "admission-proxy.admission.svc" denied the request:
Security Violation: Pod is running as privileged. Privileged containers can access allow
devices on the host and bypass security restrictions.

As we can see, the agent correctly identifies the security risk and denies the request with a clear message explaining the reason for the denial. We can also check the logs of the agent-proxy to see the admission review request and the response from the agent.

kubectl logs -n admission admission-proxy-...

Conclusion

AI Agents can be a powerful tool for automating and optimizing admission control in Kubernetes environments. By leveraging the capabilities of AI agents, we can ensure that only secure workloads are allowed into the cluster, while also saving time and resources for cluster administrators. The development of an AI agent for admission control requires careful consideration of the system message and the response schemas, as well as the integration with Kubernetes, in our case using the kubernetes-admission-proxy. The evaluation of the agent shows that it can effectively identify security risks and enforce policies in real time.

Should you use it in Production?

While the concept of using AI agents for admission control is promising, it is important to note that this is still a relatively new and experimental approach. The agent we developed is a proof of concept and may not be suitable for production environments without further testing and improvements. It is crucial to thoroughly evaluate the agent's performance, reliability, and security implications before considering its use in a production environment. Additionally, it is recommended to have a fallback mechanism in place in case the agent fails or makes incorrect decisions.

Future Work

If we see attention and interest in this project, we will continue to improve the agent and add more features.