In Kubescape 4.0, the focus shifts from reactive security to proactive security. The main changes include runtime detection, a redesign of the agent model, and the extraction of security data from etcd.
The problem manifests at scale. As the cluster grows, security begins to compete for resources with the control plane itself. Storing security metadata in etcd increases the load. Ephemeral DaemonSets with elevated privileges complicate auditing. Runtime detection either generates noise or fails to keep up with the load. Additionally, a new layer is introduced—AI agents, which gain access to the infrastructure and expand the attack surface.
In Kubescape 4.0, several related changes have been made. Runtime Threat Detection has reached GA and has transitioned to CEL (Common Expression Language). This provides more predictable performance and direct access to Application Profiles as baselines. Simultaneously, the host-sensor and host-agent have been removed. Instead, the node-agent has been strengthened, and direct API interaction with core services has been introduced. This is a compromise: less flexibility at the host level, but greater manageability and transparency.
The implementation relies on Kubernetes-native approaches. Rules and bindings are formatted as CRDs, simplifying the operational model. Alerts can be sent to existing pipelines: AlertManager, SIEM, Syslog, webhooks. For data storage, Kubescape Storage based on Aggregated API has been introduced. This extracts Application Profiles, SBOM, and vulnerability manifests from etcd into a separate layer. Thus, the pressure on the main datastore is reduced, and behavior in high-density clusters is improved. The transition to a single node-agent eliminates the need for ephemeral pods with elevated privileges, simplifying auditing.
A separate vector is AI. Kubescape adds integration with KAgent: AI agents can read the security posture of the cluster. At the same time, the system checks the KAgent itself. 42 critical configuration points have been defined, and 15 Rego controls have been added. This is an attempt to close the bidirectional risk: the agent as an analysis tool and the agent as a potential point of compromise.
The results claim stability of runtime detection at scale, but specific metrics are not provided. Architecturally, the changes appear to be evolutionary: fewer components with elevated privileges, clear separation of storage, and a more predictable rule model. The cost is the dependency on Kubernetes API extensions and the need to manage an additional storage layer.