Kubernetes policies like Kyverno are your last line of defense, but they should never actually be triggered. By storing business policies in a searchable vector database and using AI agents with MCP, developers and AI can be guided to do the right thing before hitting policy violations - turning the "bouncer at the door" into a preventive knowledge system.
Most developers experience Kubernetes policies as a bouncer at a club door - they write manifests, apply them, get rejected, fix something, apply again, get rejected again, and repeat until they finally pass all policy checks they never knew existed. This brute-force approach is frustrating and inefficient.
The real policies in any company exist in scattered places: Slack messages, wiki pages, Zoom call recordings, informal discussions. Someone decides "we only deploy databases in US-East-1" during a meeting, and that becomes an unwritten rule that eventually gets encoded into Kyverno - but the knowledge gap remains.
When you ask AI to generate Kubernetes manifests, it behaves exactly like a developer would - it creates something, you apply it, Kyverno rejects it, AI modifies it, apply again, reject again. It is the same brute-force loop because AI does not have access to your company's internal policies.
"What we really need to figure out both with people and with AI is where are all those policies really? They are in Slack, they are in doc wiki pages, they are in Zoom calls."
Viktor demonstrates a system where policies are stored in a vector database with semantic search capabilities. The workflow has two parts:
The demo uses Claude Code with a custom MCP server that wraps a specialized agent. The agent:
For a cluster with approximately 1,000 resource definitions, the initial indexing takes about an hour. Most time is spent dealing with etcd (which is slow) and converting schemas into meaningful keywords.
The goal is that Kyverno policies are never actually triggered in production. They exist as the final safety net, but because both humans and AI have access to searchable policy knowledge, they always generate compliant manifests from the start.
"Kyverno might never be used in my company and that's the ideal situation. You should have it but it never ends up being used."
"Kubernetes policies are not a way for you to know how to do the right thing. They're a way to prevent you from doing the wrong thing, which is very very different."
"AI has amnesia by the way. The moment you finish working on something, it forgets everything you did. So it needs to be taught every single time."
"I tried infinite number of combinations to teach AI what is the good thing what is the wrong thing. It never ever works unless it can actually search through the database by itself."
"I personally stopped using anything but Claude Code. For the last maybe half a year I was a big Cursor user. I really disliked the idea of Claude Code and then I got used to it and now I cannot do anything else."
| Time | Topic |
|---|---|
| 00:00 | What are policies really? |
| 02:15 | The bouncer metaphor - last line of defense |
| 03:00 | AI behaves like humans with policies |
| 04:30 | Where policies actually live in companies |
| 05:00 | Kubernetes is horrible for AI discovery |
| 06:00 | Demo: Creating a policy with Claude Code |
| 10:00 | Loading Kubernetes schemas into vector database |
| 12:40 | The ideal: Kyverno never gets triggered |
| 13:35 | Demo: AI-guided database creation |
| 19:00 | Policy violation demonstration |
| 20:15 | Q&A: Exporting etcd to vector database |
| 22:30 | Q&A: MCP implementation details |
| 24:00 | Preference for Claude Code over other tools |