Does Runtime Topology Context Improve LLM-Generated Kubernetes Security Patches?
Kubernetes security patches improved sharply when the model received live service dependencies, showing that scanner findings alone omit context needed to avoid breaking workloads.
KuTIE combines Istio call edges, Trivy findings, and service-account bindings before asking an LLM to patch Kubernetes configurations. Evaluation covered **248 trials** on a 36-deployment cluster with 31 findings across seven dependency classes.
Feed remediation agents the runtime relationships their patches must preserve. For topology-dependent findings, correctness rose from **11.1% with scanner-only context** to **78.0% with topology context**.
KuTIE combines Istio call edges, Trivy findings, and service-account bindings before asking an LLM to patch Kubernetes configurations. Evaluation covered **248 trials** on a 36-deployment cluster with 31 findings across seven dependency classes. Feed remediation agents the runtime relationships their patches must preserve. For topology-dependent findings, correctness rose from **11.1% with scanner-only context** to **78.0% with topology context**. The topology-independent control showed **no improvement**, supporting a context-specific effect rather than generic prompt enrichment. The study used one purpose-built healthcare cluster, and one of seven dependency classes did not show the broader pattern.
KuTIE provides controlled evidence that context engineering should be dependency-aware, not merely additive: runtime topology sharply improved patches only when findings depended on that topology, while unrelated cases did not benefit. This strengthens the case for agents retrieving bounded, task-relevant relationships and for evaluating context effects per case, while limiting generalization to the tested cluster and dependency classes.