The Migration Toolkit That Now Runs AI Agents Inside Your Cluster

Konveyor v0.11.0 is here, and it quietly ships the plumbing for AI agents that migrate code by themselves, locks down its network by default, and hands you the keys to your own identity provider.

That is a strange sentence, so let us unpack it. Because underneath the modest version number, this release plants three flags: autonomy, security, and ownership.

What Is Konveyor, and Why Should You Care?

Imagine you inherit a warehouse full of furniture. Some of it is antique. Some of it is held together with duct tape and hope. Somebody hands you a catalog and says: “modernize this.”

That is application modernization, and Konveyor is the crew that shows up with scanners, labels, and a plan.

Concretely: Konveyor is an open-source toolkit in the CNCF sandbox that analyzes large estates of legacy applications and figures out what it takes to move them to Kubernetes and cloud-native tech. It maps dependencies, flags trouble spots, and even has an AI assistant called Kai that suggests actual code changes. Platform teams facing a “move 400 apps to the cloud” mandate use it to turn a guess into a plan.

And v0.11.0, published September 30, 2026, is interesting for one big reason: it is the release where Konveyor starts wiring itself into the emerging world of Kubernetes-native AI agents (PR #596). Not a chatbot bolted on top. An actual controller that runs inside your cluster.

Think of Kai as the advisor who tells you what to fix. The new agentic controller is the contractor who moves in and starts fixing.

What Is New in v0.11.0

1. The Agentic Controller: Opt-In Autonomy

The headline feature. Konveyor can now deploy an agentic controller as an optional component, wired to the Agent Sandbox CRD (sandboxes.agents.x-k8s.io) — a Kubernetes community effort for running AI agents in controlled sandboxes. It is a deliberate first step: AI agents that can analyze and transform your migration targets under Kubernetes supervision, instead of chat windows and copy-paste.

You opt in through the Tackle custom resource:

apiVersion: tackle.konveyor.org/v1alpha1
kind: Tackle
metadata:
  name: tackle
spec:
  agentic_enabled: true

Three things make this release the real deal rather than a checkbox: the agentic images are now part of the release itself (PR #600), default content gets installed (PR #604), and tackle-hub gets the RBAC permissions to talk to agentic resources (PR #614). Note the guard rails: agentic_enabled defaults to false, and the controller only deploys when the Agent Sandbox CRD is already on your cluster.

2. Network Lockdown by Default

Old behavior: Konveyor’s namespace-isolation NetworkPolicies restricted ingress only. Egress — traffic leaving the namespace — was wide open. New behavior in PR #620: default-deny egress. Pods can only talk to cluster DNS, each other, and outbound TCP on ports 80/443/6443/8443.

This is textbook zero-trust, and long overdue. But it came with an immediate plot twist the maintainers had to patch in the same release cycle: Konveyor’s analyzers download Java dependencies from artifact repositories, and Sonatype Nexus defaults to port 8081 while JFrog Artifactory loves 8081 and 8082 — none of which are on the allow-list. Analysis jobs started failing with silent connect timeouts.

PR #624 added 8081 and 8082 to the allow-list. The lesson travels well beyond Konveyor: when you default-deny, you will find every undocumented port in your estate the hard way.

3. You Own Your Identity Provider Now

PR #581 adds deployment-time auth settings: configure your primary identity provider directly, with optional token lifetimes, authentication cache duration, and key rotation. The flip side: Keycloak is no longer managed by the operator.

This is the “you are the driver now” moment. If you relied on the operator babysitting Keycloak for you, plan that migration before upgrading. If you always wanted to point Konveyor at your existing IdP instead — this is your release.

Security: A Real Vulnerability, Actually Fixed

v0.11.0 fixes CVE-2026-11332 — argument injection in ansible-galaxy role install leading to arbitrary code execution (PR #599). The flaw lives in ansible-core: when installing a role, ansible-galaxy reads a meta/requirements.yml file and passes its src and name fields to git clone without a -- separator, letting a malicious role file inject arguments. The fix is an operator-sdk bump from v1.37.1 to v1.42.3, pulling in ansible-core 2.16.19+.

It is rated CVSS 7.8 (High) in the GitHub advisory — see also the NVD entry. Who is affected: deployments that install roles from sources that could be attacker-influenced. No known exploitation so far — but if you build or install roles from third-party repos, patch first, ask questions later.

Worth a mention: the egress lockdown above is itself a meaningful security upgrade — attack surface is now the allow-list, not the internet.

The Fine Print

• Upgrade check: the default-deny egress applies when feature_isolate_namespace is true (the default) — if your artifact repo lives on a nonstandard port, your analysis pipeline will tell on itself immediately.
• Agentic preview: the agentic controller needs the Agent Sandbox CRD on-cluster; without it, the pre-flight simply skips the deployment.
• IdP prep: Keycloak is your responsibility now. Budget some migration time.

One Sentence

Konveyor v0.11.0 turns the migration toolkit into a platform — agentic-ready, network-hardened, and honest about who runs the keys.

Learn More

• Konveyor Official Website
• GitHub Repository
• Full Changelog for v0.11.0