Look for vendor-specific databases, custom scaling logic, separate upgrade procedures, and a console the platform team must learn from scratch. Those are signals that Kubernetes is only the landing zone, not the control plane foundation.
How to tell Kubernetes is only the landing zone
When an AI platform is genuinely built on Kubernetes, the orchestration layer should feel like the substrate, not the product. If the platform team still has to manage a separate data store, learn a second control experience, or follow upgrade steps that do not track cluster operations, the real control plane is probably elsewhere. That distinction matters because it determines where policy, lifecycle, and failure recovery actually live.
One practical clue is whether the control logic is expressed in Kubernetes-native objects or hidden behind vendor-owned state. If the important decisions are made in custom databases, side channels, or proprietary schedulers, Kubernetes is providing compute, not governing the system. In that case, the operational model is split: one team runs clusters, another runs the actual AI control surface.
Another clue is drift between day-two operations and cluster administration. If scaling, rollout, tenant isolation, or policy changes require vendor-specific workflows instead of the same operational patterns used for the rest of the platform, that is a sign the control plane is separate. A real Kubernetes foundation usually lets platform operators observe and manage the system through familiar cluster primitives, not a parallel admin model.
Where the separation shows up in upgrades, state, and operator workflow
Separate upgrade procedures are one of the clearest indicators. When Kubernetes versions can be changed without materially affecting the AI control plane, or the AI plane can be upgraded on its own cadence with its own compatibility matrix, the relationship is layered rather than unified. That is not inherently bad, but it means Kubernetes is acting as an execution environment, not the source of truth for control behavior.
State management is another tell. If the product keeps durable control state outside the cluster, such as in a vendor database or hosted service, then cluster loss, namespace changes, or redeployment may not fully reset the platform. A Kubernetes-native system usually keeps enough of its control intent close to the cluster to make recovery and portability understandable. A separate control plane often makes those promises depend on proprietary backing services.
The operator experience also reveals architecture. If the platform team must learn a console from scratch, with its own terminology, approval flow, and policy model, you are likely looking at a distinct product control plane that happens to deploy onto Kubernetes. That is often the right design for complex platforms, but it should be recognized as a separation of responsibility, not marketed as “just Kubernetes.”
The container- and cluster-security baseline still matters here, especially around image provenance, registry trust, and runtime exposure. NIST’s container security guidance is useful for understanding the boundary between the orchestrator and the application platform, and NIST SP 800-190 Container Security is the right reference point when you are validating what Kubernetes does, and does not, control. For teams studying how secrets and credentials leak through container ecosystems, Secrets in Docker Hub images (RWTH Aachen study) is a useful reminder that the orchestration layer does not automatically govern every sensitive asset around it.
Risk and Threat Considerations
A split control plane creates a false sense of uniform governance. Teams may assume Kubernetes policy, RBAC, or cluster upgrades fully cover the AI platform, when the actual control logic, persistence, and credentials sit in a separate service. That gap can leave recovery, change control, and access review weaker than operators expect, especially when the vendor plane owns the real decision-making path.
Failure mechanism: The cluster is treated as the governance boundary even though the meaningful state, authorization flow, or scaling logic lives in external vendor services or proprietary databases. That breaks operational visibility and can leave a hidden dependency that survives cluster changes.
Impact: A compromise, misconfiguration, or outage in the separate control plane can affect every workload managed through it, even if Kubernetes itself is healthy. It can also complicate incident response because the platform team may need two different administrative models to contain the problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Separate control planes change platform configuration and upgrade baselines. |
| AC-6 — Least Privilege | A distinct control plane usually adds a second privileged admin surface. | |
| AU-2 — Event Logging | A separate AI control plane needs its own audit trail beyond cluster logs. | |
| Recommendation — Baseline the Kubernetes and vendor-plane components separately and track drift across both. Restrict vendor-plane and cluster-admin access independently to the minimum needed. Log control-plane actions separately from Kubernetes events and retain them for review. | ||
| NIST CSF 2.0 | GV.SC-01 — Cybersecurity Supply Chain Risk Management Strategy | Vendor-owned control planes create dependency and trust-boundary risk. |
| Recommendation — Map vendor-managed control components and verify their operational dependencies and trust assumptions. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | A control plane layered over Kubernetes can hide insecure deployment and separation patterns. |
| Recommendation — Validate that the platform’s deployment and access model do not leave sensitive state outside intended controls. | ||
Practitioner Guidance
What to verify: Check whether policy enforcement, tenancy, secrets handling, and lifecycle operations are defined by Kubernetes objects or by vendor-side state. If a redeploy, namespace move, or cluster upgrade does not materially change the control experience, that is evidence of a separate plane.
Common mistake: Treating “runs on Kubernetes” as the same thing as “is governed by Kubernetes.” Platform teams should test operational ownership, not just deployment topology, because the hidden control plane is often where the real blast radius sits.
What good looks like: The team can explain exactly which functions Kubernetes owns, which functions the platform owns, and what happens to state, policy, and access if the cluster is rebuilt. If that answer is vague, the architecture is probably less integrated than it appears.
Practitioner takeaway: A genuine Kubernetes foundation is visible in control boundaries as much as in manifests. If the operator must learn a second console, follow separate upgrade logic, or trust external state for core behavior, Kubernetes is hosting the system, not governing it.
Related resources from NHI Mgmt Group
- How should teams decide whether an AI control plane needs to be Kubernetes-native?
- Why do organisations need a unified control plane for agentic AI instead of separate stacks for models, tools, and agents?
- How should security teams detect AI agent escapes in Kubernetes before they reach the host or control plane?
- What are the signs that Kubernetes remote code execution risk is being created by exposed control-plane components?