Building an Agent-Based Vulnerability reporter for Kubernetes using kagent, kubescape, LiteLLM and mcp-proxy
- arunmudaliar
- Feb 24
- 8 min read
Updated: Feb 27
Note: This solution was developed as a submission for MCP_HACK//26, a hackathon focused on building innovative applications using MCP and AI agent technologies.
Introduction
Modern Kubernetes environments generate large volumes of security findings that are often difficult to interpret and prioritize manually. To address this, we combine automated cluster scanning with AI-driven reasoning to transform raw security data into actionable intelligence.
Kubescape scans the Kubernetes cluster by analyzing workloads, container images, configurations and RBAC policies against known vulnerabilities, security best practices and generates structured reports that are stored as custom resources. An intelligent agent can process these reports to correlate findings with specific workloads, prioritize risks and translate raw vulnerability data into contextual human-readable insights with remediation guidance.
This solution presents an agent-based vulnerability reporting system for Kubernetes that combines kagent for creating agents, Kubescape for Kubernetes-native vulnerability scanning, LiteLLM as a LLM Gateway with guardrails, and mcp-proxy for exposing Kubescape MCP tools.
Primary Goals
Enable natural language querying of Kubescape generated vulnerability reports
Identify vulnerable container images across the cluster
Identify affected Kubernetes workloads (pods, deployments, daemonsets, etc.)
Search and assess impact of specific CVEs scoped to a namespace
Reduce manual effort in interpreting raw vulnerability reports
Highlights
This solution enables natural language querying of Kubernetes vulnerability data by leveraging Kubescape generated vulnerability manifests and an intelligent agent layer. Instead of manually parsing raw yaml reports, users can simply ask questions like “Which workloads are affected by CVE-2026-XXXX?" or “Show all critical vulnerabilities in the cluster” and receive contextual, actionable insights.
Test Environment
Kubernetes Cluster (GKE)
kagent
Kubescape Operator
Custom MCP Server (mcp-proxy + kubescape MCP server)
LiteLLM
Gemini 2.5 Flash Lite
System Architecture
Installation
Kubernetes Cluster:
Deploy a standard Kubernetes cluster. I used a GKE cluster (v1.34.3) with 8 x e2-medium nodes.
kagent:
kagent empowers platform and DevOps teams to interact with their Kubernetes clusters using natural language, reducing the need to manually run complex commands. It accelerates troubleshooting and security investigations by automatically invoking the right tools and summarizing actionable insights.
I followed the helm installation method documented here with default settings.
Install the kagent CRD's first:
$helm install kagent-crds oci://ghcr.io/kagent-dev/kagent/helm/kagent-crds
-n kagent --create-namespaceNext install the kagent components:
$helm install kagent oci://ghcr.io/kagent-dev/kagent/helm/kagent -n kagent Verify if the pods are up and running:
$kubectl get po -n kagent
NAME READY STATUS RESTARTS AGE
argo-rollouts-conversion-agent-868459996f-fw9q5 1/1 Running 0 22h
cilium-debug-agent-7cf465879d-vmgj9 1/1 Running 0 22h
cilium-manager-agent-fc7f4cf64-wmfst 1/1 Running 0 9m3s
cilium-policy-agent-84b44c88c8-d48fq 1/1 Running 0 22h
helm-agent-76f649bf44-ls4tg 1/1 Running 0 22h
istio-agent-6c5cbd7b5d-gpr9z 1/1 Running 0 22h
k8s-agent-5dbc5c5558-t8mfl 1/1 Running 0 22h
kagent-controller-57667bbbc7-8dfhl 1/1 Running 0 22h
kagent-grafana-mcp-86766864c5-5ftbk 1/1 Running 0 22h
kagent-kmcp-controller-manager-6454bc76c5-6w7qr 1/1 Running 0 22h
kagent-querydoc-55859dc685-z8v82 1/1 Running 0 22h
kagent-tools-5d97d4f7c5-t4ntj 1/1 Running 0 22h
kagent-ui-766d578d59-s24vt 1/1 Running 0 22h
kgateway-agent-7bb46cd46-4rlp6 1/1 Running 0 22h
observability-agent-658b9bcc85-95r2w 1/1 Running 0 22h
promql-agent-57f9ff88d5-wx8l6 1/1 Running 0 22hKubescape Operator:
Kubescape is an open-source Kubernetes security platform that helps teams scan clusters, manifests and Helm charts for vulnerabilities, misconfigurations, and compliance issues. It evaluates the Kubernetes environments against industry security frameworks like NSA, CIS, and MITRE to highlight risks and provide actionable insights. This enables developers and DevOps teams to catch security gaps early, enforce best practices and strengthen cluster security across the development and deployment lifecycle.
The instructions to deploy the operator in a kubernetes cluster is available here.
$helm repo add kubescape https://kubescape.github.io/helm-charts/
$helm repo update
$helm upgrade --install kubescape kubescape/kubescape-operator -n kubescape --create-namespace --set clusterName=`kubectl config current-context` --set capabilities.continuousScan=enableVerify if the pods are up and running:
$kubectl get po -n kubescape
NAME READY STATUS RESTARTS AGE
kubescape-55765bf7dd-xkjbk 1/1 Running 0 12m
kubescape-scheduler-29532798-7gf5n 0/1 Completed 0 11m
kubevuln-68b6dc5644-l7vfz 1/1 Running 0 22h
kubevuln-scheduler-29532637-fx4qm 0/1 Completed 0 11m
node-agent-4j5jg 2/2 Running 0 12m
node-agent-54zlq 2/2 Running 0 13m
node-agent-625z6 2/2 Running 0 13m
node-agent-6xl2p 2/2 Running 0 13m
node-agent-88sjn 2/2 Running 0 13m
node-agent-8lz67 2/2 Running 0 13m
node-agent-pvpvb 2/2 Running 0 12m
node-agent-xhm29 2/2 Running 0 13m
operator-676696677c-9zbgb 1/1 Running 0 22h
storage-85485d88d8-c2r9g 1/1 Running 0 22hCustom MCP server:
Kubescape CLI includes an MCP (Model Context Protocol) server mode that exposes Kubescape’s security capabilities as structured tools for AI agents. When started in MCP mode, it allows agents to query vulnerability manifests, scan results, and compliance data programmatically instead of just reading CLI output. This enables natural-language driven security investigations, automated reasoning over findings, and tighter integration with AI assistants like Kagent. You can read more about this feature here.
Kubescape MCP server runs over standard input/output (stdio), which works well for local agent integrations but not for remote or distributed deployments. To integrate it with Kagent in a cluster setup, it needed to be exposed as a remote MCP server. This was achieved using mcp-proxy, which converts the stdio-based MCP server into an SSE/HTTP endpoint that Kagent can connect to over the network.
I built a custom container image that runs mcp-proxy to forward the Kubescape MCP server, exposing it as a remote endpoint over SSE and streamable HTTP for integration with kagent. The image is uploaded to dockerhub and the dockerfile is available here.
Clone the github repo and apply the manifests under mcp-proxy directory to deploy the custom image mentioned earlier.
$git clone https://github.com/cloudnativeguru/mcp_hack_2026_project.git
$cd mcp_hack_2026_project/mcp-proxy
$kubectl apply -f .
$kubectl get po
NAME READY STATUS RESTARTS AGE
kubescape-mcp-7999b4bf-5h7t9 1/1 Running 0 23hIn addition to the deployment, a service account, required RBAC's and a service to expose mcp-proxy is also created during above step.
Next, in order for the agent to connect to this mcp server, we have to create a kagent custom resource 'RemoteMCPServer'. The manifest for deploying it is available here and should be applied using below command:
$cd kagent
$kubectl apply -f remotemcpserver.yamlLiteLLM:
LiteLLM acts as an LLM gateway that provides a unified API layer across multiple LLM providers, abstracting model access behind a consistent interface. In our setup, it serves as a proxy between the LLM provider and our platform, centralizing authentication, routing, and observability. It also enables guardrails such as rate limiting, logging, model control, and policy enforcement to ensure secure and governed LLM usage.
To deploy LiteLLM with default settings using helm, follow the steps available here. Once deployed verify if the components are running:
$kubectl get po -n litellm
NAME READY STATUS RESTARTS AGE
litellm-6ffc656586-k4pvx 1/1 Running 0 24h
litellm-postgresql-0 1/1 Running 0 24h
Next, let's add the required model provider and set the guardrails from LiteLLM console. The default username is 'admin' and the password is stored as a secret. To access the Web UI port-forward the service as below:
$kubectl get secret litellm-masterkey o jsonpath="{.data.masterkey}" | base64 -d
$kubectl port-forward svc/litellm -n litellm 4000:4000Now access the UI at http://localhost:4000/ui .
Navigate to "Models + Endpoints". Fill in the "Add Model" form to add the required LLM service provider. The mandatory fields are Provider, Model Name and the API Key.
Test the connection to make sure it works and save the settings.
Next let's add some Guardrails. For demonstration, I added a guardrail to allow only required tool calls from the agent deployed through kagent. To add the Guardrail navigate to Guardrails > Add New Guardrail and follow the below steps:
Search for "LiteLLM Tool Permission Guardrail" in Guardrail Provider. Toggle "Always On" to Yes and click Next. Allow the agent to access only 2 tools provided by kubescape MCP server:
list_vulnerabilities_in_manifest
list_vulnerability_manifests
In the next page, add two Rules and set the configurations as below for each tool:
Once done click "Create Guardrail".
The final setting is to generate an API key that can be used by the agent to connect to LiteLLM. Navigate to "Virtual Keys" and fill in the form as show below to generate the API key. Make a note of the key when prompted as it will be required in the next steps.
Integrate kagent with LiteLLM gateway:
Follow the below steps to integrate the agent with LiteLLM.
First create a kubernetes secret that holds the LiteLLM Virtual Key:
$kubectl create secret generic litellm-gemini-key --from-literal PROVIDER_API_KEY="<litellm virutal key>" -n kagentNext create a ModelConfig object. In Kagent, ModelConfig defines the LLM connection details such as provider, model name, endpoint, credentials, and runtime parameters, used by an agent to execute prompts.
The github repo contains the manifest to create a modelconfig. From the root directory execute below commands:
$cd kagent
$kubectl apply -f litellm-gemini-model-config.ymlCreate an Agent using kagent:
The final step is to create an Agent in kagent. Let's do this using the kagent web console. We can access the UI by port-forwarding the kagent-ui service:
$kubectl port-forward svc/kagent-ui -n kagent 8080:8080Now access the UI at http://localhost:8080.
Navigate to Create > New Agent to add a new agent:
Fill in the form with Agent name, namespace, Agent Type and the description:
In the Agent Instructions field, use the prompt template provided in the github repo.
Under the Model list, select the model created in the previous step using the ModelConfig:
Next, add the tools required by the agent:
Search for 'kubescape' to filter out required tools and select only the two tools as in below screenshot. Once added click 'Save Selection'.
You should be back to the 'Create Agent' page, click 'Create Agent'. It will take few seconds for the agent to be up and running. The Agent runs as a pod in the cluster. Execute the below commands, to check the status of the created agent.
$kubectl get po -n kagent
NAME READY STATUS RESTARTS AGE
vulnerability-assistant-5875c88b57-fzd5b 1/1 Running 0 80mOnce the agent status shows as running, on the kagent web console, it will show up under 'Home', select this agent and now you can start interacting with it.
Testing the Deployed Agent
Case 1: We can ask the agent to provide a list of vulnerable images or workloads in a specific namespace. The response output has the list of the image names.
To get more details about the vulnerability, select an image name and provide it as an input to the prompt. For instance, I tested the first image name returned in the above list:
The agent then returns a properly formatted vulnerability report for the requested image. Note the tools call made and the format of the output which is easier to read and export for further use.
The output could be very useful when its being consumed by another agent in an A2A communication setup.
Case 2: Let's provide a CVE id to list the affected workloads.
I tested it for CVE-2025-11187 and the result was partially correct.
The response contained the correct pod name, but the namespace was incorrect and I believe it was due to the fact that the vulnerability reports were being stored in 'kubescape' namespace. With a minor update to the prompt template this could be fixed.
At LiteLLM end, you can track each LLM call, the count of tokens used and guard rails getting invoked.
Conclusion
This solution demonstrates how an agent-driven architecture can transform Kubernetes vulnerability management into an intelligent, conversational experience. By combining Kagent for orchestration, Kubescape for security insights, LiteLLM for governed LLM access and mcp-proxy for remote tool exposure, it creates a scalable and extensible security automation framework. The result is faster vulnerability investigation and a proactive cloud-native security posture.
References
Thanks to the community members of all the awesome projects included in this work.
Hope you enjoyed reading this article. Please drop your comments below 👍. Subscribe to our newsletter to stay updated on our latest articles and insights.
This post is intended for educational purposes only.
Comments