Kubex Agentic AI Platform: Secure Context at the Edge

In Part 1: Agentic AI at Scale – Building the Kubex Agentic AI Platform of this series, we laid the foundation for scaling agentic AI across cloud infrastructure. We examined why traditional ops workflows get stuck in reactive loops of dashboard watching, why static context limits intelligence, and how the Kubex platform uses context engineering and a distributed nervous system to bridge the gap between telemetry and deterministic actions.

But as agents move from answering questions to investigating infrastructure optimization and preparing consolidation proposals, they hit a hard boundary: the enterprise network perimeter. When a customer’s Kubernetes environment is private, isolated, and protected by strict network controls, how can an AI agent reason accurately about what is actually happening inside it?

Our answer is CDI, the Cluster Data Interface: a read-only observation point that runs inside each cluster, connects outward to the Kubex platform, and operates strictly within the customer’s own Kubernetes RBAC. In this article, I explain why agents need live cluster context, how CDI delivers it without opening the cluster, and why observing a cluster is never the same as being authorized to change it.

Recommendations and proposals. Kubex produces two kinds of output. Deterministic recommendations, such as container request and limit rightsizing, come from Kubex analytics and are applied continuously by the Kubex Automation Engine within customer-defined policies. Built-in runtime checks cover autoscaler conflicts, ResourceQuota and LimitRange bounds, node headroom, pod readiness, and Pod Disruption Budgets, with automatic rollback if a change fails. In large enterprises that means hundreds of thousands of recommendations, far too many for anyone to review one by one, and none of it depends on AI agents or CDI. Proposals are different: AI agents generate them for broader, investigative changes that cut across workloads, such as node pool consolidation, packing strategy, or runtime configuration, where human judgment adds real value. This article is about proposals, and how CDI grounds them in live cluster context.

The Context Gap: Without Live Data, Agents Give Textbook Advice

To provide meaningful recommendations and diagnoses, an AI agent needs more than general Kubernetes knowledge or centralized metrics. It needs current, granular context from the live cluster to answer questions like:

• Which packing strategies are active across node pools (MostAllocated bin-packing versus LeastAllocated spread)? Which resource requests, limits, topology spread constraints, node affinities, taints, and tolerations govern where pods land?
• What consolidation thresholds, node drain behavior, and disruption budgets are configured (Karpenter consolidation policies and Pod Disruption Budgets)?
• Which autoscaling, rightsizing, and rollout controllers, such as KEDA, Karpenter, VPA, HPA, or Argo Rollouts, are actively managing workloads and node pools?
• Where does runtime state diverge from the desired configuration; rollouts, pending pods, or crash loops?

Without this context, an agent’s reasoning degrades into generic textbook advice that misses the local operational reality.

Yet customer clusters are isolated by design. They run behind firewalls, NAT gateways, and restricted VPCs. They are governed by strict compliance policies, vary in version and topology, and hold data far too sensitive to expose through broad integrations.

So this is not just a data-retrieval problem. It is a connectivity, security, trust, ownership, and operational-boundary problem all at once. The task is to give the agent the right context without weakening the security posture or control boundaries of the environment that produced it.

Just as important, what the agent can see must be bounded by the namespace policies, quota limits, and RBAC controls the customer already enforces, so the cluster decides what the agent can inspect, not the agent itself.

CDI: A Read-Only Observation Point Inside Every Cluster

To close the distance between the Kubex platform and the live cluster, we built CDI (Cluster Data Interface).

CDI runs directly inside the customer’s Kubernetes environment and acts as a dedicated observation point. It lets Kubex AI agents retrieve the operational context they need while preserving the customer’s existing network isolation and authorization boundaries.

CDI is intentionally cluster-local: each instance provides a controlled view into exactly one K8s environment. At platform scale, agents don’t manage every CDI instance as a separate integration. Instead, the CDI Federation MCP connects the agentic platform to the right CDI instance for each request, allowing Kubex to work across hundreds or thousands of clusters.

Federation will get its own article; for now, the key distinction is that CDI is the secure observation point inside one cluster, while federation makes those observation points usable at platform scale.

Here is how CDI fits alongside the other platform components across the lifecycle from observation to execution:

• Analytics Engine MCP Server provides deterministic optimization insights and time series performance intelligence
• CDI (Cluster Data Interface) provides current context, configuration, and operational state from a single Kubernetes cluster
• CDI Federation MCP federates access to CDI instances across many clusters.
• AI Agents + AI Execution Platform combine analytics, live cluster context, and operational constraints to investigate, reason, and build actionable proposals
• Human-in-the-loop governance is the approval bridge where platform operators review, validate, and authorize AI-generated proposals.
• Automation Engine executes approved proposals and policy-driven deterministic recommendations safely across target environments, with built-in runtime safety checks.

Outbound-Only Connectivity: Reaching the Cluster Without Opening It

A fundamental rule of enterprise networking is that a platform must not demand inbound access to customer networks. Kubex doesn’t require it. Customers are never asked to expose their K8s API publicly, open inbound firewall ports, or relax network policies just so an AI agent can inspect workloads.

Instead, a connector running alongside CDI inside the customer’s environment initiates an outbound-only connection to the Kubex platform, so no public inbound endpoint or inbound firewall rule is needed. When an agent needs context, the CDI Federation MCP routes the request over this encrypted tunnel to the CDI instance for the correct customer and cluster. CDI validates the request, queries the local cluster within its assigned Kubernetes RBAC permissions, and returns the live context that grounds the agent’s proposal in reality.

This secure encrypted tunnel is not a general-purpose network bridge and gives no access to the wider corporate network. It carries requests only to the services the connector registers, which by default is CDI’s read-only interface. It offers no shell, no port forwarding, and no direct path to the Kubernetes API or anything else on the network. The connector itself needs no Kubernetes permissions at all.

Two Boundaries Keep the Customer in Control

Connecting Kubex platform to a cluster is only half the challenge. The other half is doing it without changing the customer’s security posture. The encrypted tunnel + CDI system addresses this with two complementary boundaries.

The network boundary. Communication is established outward from inside the customer environment, so Kubex can reach CDI without an inbound connection into the customer network or public exposure of the K8s API. The secure tunnel carries targeted requests only to the CDI instance associated with the correct customer and cluster.

The authorization boundary. A request that reaches CDI can only read what CDI is permitted to read. CDI operates with strict permissions assigned to it inside the customer’s Kubernetes environment. Kubernetes RBAC remains the authority over which resources and namespaces it can read. CDI’s role is read-only: it can get and list the resources it needs, such as workloads, nodes, events, autoscalers, and disruption budgets, and nothing more. It has no access to Kubernetes Secrets, and customers can narrow its view further to specific namespaces.

Together, these boundaries form a layered, controlled path to cluster context:

• The connector establishes communication from inside the customer environment
• The CDI Federation MCP routes each request to the intended customer cluster
• Authentication verifies that the request is permitted to reach CDI for the given customer/cluster combination
• Kubernetes RBAC determines what CDI can see / read
• CDI is read-only: it has no permission to change workloads
• Approval and automation remain separate from observation

Access to a CDI instance provides read-only visibility, never control, and federation does not widen that access. The Federation MCP selects the appropriate CDI instance, while each instance remains governed by its own cluster-local permissions and RBAC boundaries. Each connector authenticates with its own tenant and cluster identity, so the Federation MCP can only route a request to the cluster it belongs to, and whatever it reaches is still read-only and limited by that cluster’s RBAC. Customers stay in control: removing the connector closes the path immediately.

From Insight to Grounded Proposal

CDI’s value is not that an agent can retrieve more Kubernetes data. It’s that the agent can use live cluster context to turn a general insight into a specific, timely, and responsible proposal.

The process starts with the Analytics Engine MCP Server, which exposes Kubex’s deterministic analytics to the agent. Analytics might surface an opportunity: a workload that appears over-provisioned, a cluster with stranded capacity, a node pool approaching a constraint, or a scaling policy that doesn’t match observed demand.

But an insight is not an instruction to act. To validate it against live infrastructure, the agent sends a request through the CDI Federation MCP to the appropriate CDI instance, which returns the cluster’s current configuration, runtime state, events, and relevant custom-resource context.

That validation step matters because proposals reach beyond any single workload. Container-level changes are already protected by the Automation Engine’s runtime safety checks. Proposals change things those checks were never designed to judge, so the agent needs the wider picture:

• A node pool may appear underutilized, yet a LeastAllocated spread strategy, a conservative Karpenter consolidation policy, or scheduling taints may explain why its spare capacity can’t simply be consolidated.
• A cluster may show stranded capacity, yet topology spread constraints or node affinities may pin workloads to specific zones or node types.
• A workload may look like a candidate for a different node pool or instance type, yet node affinities, taints, or GPU requirements may constrain where it can run.

With both sources in hand, the agent can connect three things:

• The opportunity: what the analytics and historical data suggest.
• The reality: what the live cluster configuration and runtime state show.
• The proposal: what should happen next, why it should happen, and under which constraints.

Because background agents generate these proposals on a schedule, rather than only when someone asks in the Kubex AI Agent chat, the investigation itself becomes proactive. Instead of waiting for an operator to manually inspect dashboards, configuration files, events, and container runtimes, the agent assembles the evidence, identifies a potential improvement, and presents a proposal grounded in the actual environment. A proactive proposal might include:

• The affected workload or infrastructure component
• Its current configuration and observed behavior
• The opportunity identified by the Analytics Engine MCP Server
• The supporting evidence retrieved from the cluster by CDI
• The proposed change and its expected performance, capacity, or cost impact
• The risks and operational constraints
• The conditions under which the proposal should, or should not, be applied

Cluster context retrieved through CDI is used by the agent for reasoning; it is not added to Kubex’s data model. What persists is the output, an answer in chat or a proposal for review. Customer data is never used to train models; Kubex runs its models on Amazon Bedrock, where training on customer data is not permitted.

Our background agents and the automated proposal-generation process will be covered in a dedicated future article.

Observation Is Not Authorization

Each step in this flow has a distinct owner. CDI provides the live context. The AI agent interprets that context and formulates the proposal. A human operator reviews and approves it. The Automation Engine executes the approved change. This separation lets the platform become increasingly proactive without confusing observation or reasoning with authorization to alter live infrastructure.

It also keeps AI-generated proposals deliberately conservative: agents observe before they propose, evaluate surrounding context before drawing conclusions, and separate verified facts from assumptions. Federation improves reach and scale, but it does not remove cluster-level boundaries: each CDI instance remains responsible for enforcing the permissions and scope of its own k8s environment.

To keep those boundaries clear, it’s worth stating plainly what CDI does not do:

• CDI does not replace Kubernetes or existing management tools
• CDI does not replace Kubex analytics or centralized historical performance engines
• CDI does not change workloads; its role grants read access only
• CDI does not execute actions; AI-generated proposals require human approval and are carried out by the Automation Engine
• CDI does not bypass K8s RBAC or network controls
• CDI does not require exposing the Kubernetes API publicly
• CDI does not provide any access to the wi.der customer network
• CDI does not automatically turn raw cluster observations into guaranteed proposals

Every AI-generated proposal requires explicit human approval before the Automation Engine acts on it. Deterministic recommendations follow their own path: applied within customer-defined policy and protected by the Automation Engine’s runtime safety checks.

Looking Ahead

Part-1: Agentic AI at Scale – Building the Kubex Agentic AI Platform  established that reliable agentic infrastructure automation requires more than a language model. It requires a distributed platform that combines deterministic analytics, operational context, controlled communication, and human oversight. In Part-2 we saw how we added a critical piece of the platform: secure, live context from inside private clusters.

The Analytics Engine MCP Server identifies where an opportunity may exist. CDI reveals how the workload is actually configured, what is happening now, and which constraints must be respected, all over an outbound-only encrypted tunnel that never requires customers to expose their Kubernetes APIs or weaken their network boundaries. The CDI Federation MCP extends that reach across hundreds and thousands of clusters while preserving the boundaries of each one. Together, they let the agent explain not only what could change, but why the change is appropriate in that specific environment.

That is the path an AI-generated proposal takes from generic advice to grounded action: identify an opportunity, locate the right cluster context, inspect the live configuration, understand the surrounding conditions, propose a change, pass through human approval, and let the Automation Engine execute it with the same safety controls that already govern Kubex’s policy-driven automation.

In a future article, we’ll explore the detailed architecture of the CDI Federation MCP and how it operates at large scale.