Self-hosted Kubernetes AI needs packaging, policy and audit trails

At a glance

What this is: This is a guide to assembling a self-hosted Kubernetes AI stack from platform, packaging, supply-chain and runtime controls, with the core finding that governance fails at handoff boundaries, not inside any single tool.

Why it matters: IAM, NHI and AI governance teams should pay attention because the article frames AI agents as governed artefacts that need lifecycle control, policy enforcement and auditability, not just infrastructure access.

Context

Self-hosted AI on Kubernetes is usually a governance problem disguised as an infrastructure choice. The difficult part is not training or serving models, but keeping the same governed artefact intact as it moves between notebooks, pipelines, registries and runtime endpoints.

That problem becomes sharper when organisations scale AI agents across business workflows. Each handoff creates a chance for provenance loss, policy drift or uncontrolled tool use, which is why packaging and runtime governance have to be designed together rather than added later.

Key questions

Q: What breaks when AI model packaging is not the governed unit?

A: Teams lose the ability to prove which data, code, prompts and configuration actually produced the deployed model. That creates gaps in reproducibility, rollback and accountability, because each tool only knows part of the lifecycle. A governed package gives the organisation one artefact to approve, move, inspect and revoke.

Q: Why do runtime policy gateways still leave AI agents exposed?

A: Because they only see a slice of the agent’s behaviour. If an agent can perform local file actions, shell commands or stdio-based tool calls, network-only policy will miss part of the decision surface. Effective governance needs enforcement at the runtime boundary where the agent actually acts.

Q: How should teams govern AI supply chains for self-hosted deployments?

A: Use package identity, provenance and approval status as the control points for promotion. The goal is to make every model or agent artefact traceable from import to production, with scanning and attestation attached to the same object that is deployed. That reduces the chance of unreviewed content slipping into a live environment.

Q: What is the difference between platform control and runtime control for AI agents?

A: Platform control decides where the AI lifecycle runs and how infrastructure is operated. Runtime control decides what an agent may do after it starts, including which tools, data and destinations it can reach. Both are necessary, but they answer different governance questions and fail in different ways.

Technical breakdown

Why model handoffs lose provenance in Kubernetes AI stacks

Kubeflow, OpenShift AI, KServe, PyTorch and MLflow each handle a piece of the AI lifecycle, but none of them owns the full artifact boundary. Model weights may live in object storage, datasets in a lake, code in Git, and prompts or configuration elsewhere. That means the system can track experiments without guaranteeing that the deployed runtime matches the trained artefact. The governance gap appears when teams promote outputs by convention instead of by immutable identity. Once a model is split across tools, reproducibility and accountability become weak points rather than defaults. See the AI Governance Platform Buyer's Guide.

Practical implication: Treat the model package as the governed unit, not the individual files it contains.

How OCI packaging changes control over AI supply chains

A ModelKit-style package collapses the model, data, code, prompts and configuration into one versioned OCI artifact. That changes the control plane because the registry, digest and provenance record become the thing that moves through the pipeline, rather than a loose collection of outputs. This is the same reason software supply chain controls are effective: they make promotion a matter of verifying a known artefact instead of reconstructing trust from multiple systems. In this model, the boundary of control is the package digest, not the notebook, job or endpoint.

Practical implication: Use immutable digests and signed provenance to make promotion and rollback auditable.

What runtime policy means for AI agents on Kubernetes

Runtime governance matters because an AI agent can be approved as an artefact and still behave in ways the business did not intend once it is live. Policy gateways, enforcement layers and audit logs need to sit close enough to the agent to observe tool use, data access and destination controls in real time. That is especially important when agents interact with local files, shell commands or MCP servers, because those actions may never traverse a traditional network gateway. The identity question is no longer just who can log in, but what the agent is authorised to do after it is already running. See the Enterprise AI Copilot Security Guide.

Practical implication: Bind agent permissions to runtime policy, not just to deployment approval.

Threat narrative

Attacker objective: To place untrusted or over-permissioned AI artefacts into production and use them to reach data or actions that should have stayed blocked.

1. Entry begins when a model or agent artefact is imported from an external source and placed into the internal AI workflow without verified provenance.
2. Credential or artefact trust is then established through packaging and registry promotion, which can become the point where unscanned or unapproved content enters the pipeline.
3. Escalation occurs when the running agent can access tools, data or destinations beyond the intent of the original approval, especially outside network-only controls.
4. Impact is loss of governance over what the agent executed, what data it touched and whether the deployed runtime matched the reviewed artefact.

Breaches seen in the wild

• CrewAI Uncrew GitHub token exposure: A CrewAI provisioning error exposed an admin GitHub token for all its private repositories; Noma reported it and CrewAI fixed it in hours.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Artifact governance is now the primary control surface for self-hosted AI. In Kubernetes-based AI stacks, the real security unit is no longer the notebook, pipeline or endpoint on its own. It is the packaged artefact that survives movement across all three. That is why provenance, versioning and promotion controls matter more than any single platform choice. Practitioners should stop treating model files as build outputs and start treating them as governed identities in motion.

Runtime controls must assume the agent is already trusted enough to run, but not trusted enough to act freely. A policy gateway that only checks network traffic cannot see local file operations, shell commands or stdio-based MCP interactions. That leaves a gap between deployment approval and actual behaviour. The governance model has to move from

AI supply chain governance and runtime governance are converging. The article makes clear that scanning artefacts before promotion and controlling actions after launch are not separate disciplines. They are two halves of the same assurance problem, because an approved model can still be dangerous if its runtime permissions are too broad. Practitioners should align supply chain review, artefact attestation and runtime policy as one control family.

Centralised audit trails are becoming the evidence layer for AI governance. A single record that spans import, approval, deployment and blocked actions gives security, compliance and AI teams something they can actually defend to auditors. That is materially different from dashboards or point-in-time screenshots. The practical implication is that the evidence model must be designed with the control plane, not bolted on after deployment.

Self-hosted AI platforms expose an identity problem hidden inside infrastructure design. Once agents can invoke tools, access data and make runtime decisions, they behave like governed non-human actors rather than passive workloads. That is where enterprise AI copilot security thinking becomes relevant: the question is not only where the model runs, but what it is authorised to do in production. Practitioners should extend identity governance to agent actions, not just to human access.

From our research library:

• Enterprise AI use rose from 55% of organisations in 2023 to 88% in 2025, according to McKinsey’s Global Surveys on the State of AI.
• Read next: Enterprise AI Copilot Security Guide

What this signals

AI governance will increasingly be judged by artefact traceability, not platform branding. As more organisations scale agents on Kubernetes, the decisive question will be whether the deployed object can be traced from import to runtime without gaps. That shifts programme design toward immutable packages, provenance and policy enforcement rather than one-off platform selections.

Agent identity is becoming a governance issue, not just an engineering detail. Once an agent can choose tools and act without direct human approval, access control has to be expressed as runtime authority over actions, data and destinations. That is where organisations will need to connect model governance with enterprise AI copilot security and broader identity controls.

Auditable AI operations will become a baseline expectation for regulated teams. If a board, regulator or customer asks what an agent was allowed to do, the answer has to come from a durable control trail, not a screenshot. The practical implication is to design evidence collection as part of the architecture, not as a reporting afterthought.

For practitioners

• Standardise the AI platform layer Choose one Kubernetes AI foundation for each environment, then keep serving, training and pipelines aligned to that operating model instead of mixing ad hoc deployment paths.
• Make the packaged artefact the approval unit Require every model, dataset, prompt and configuration bundle to move as one versioned object so approvals, rollback and provenance all refer to the same digest.
• Separate promotion from rebuilds Promote AI artefacts by digest from development to staging to production and prohibit repackaging steps that would break the evidence chain.
• Enforce runtime policy close to the agent Apply policy checks at the point where the agent can call tools or reach data, including local execution paths that bypass ordinary network inspection.
• Stream one audit trail into SOC workflows Send import, approval, deployment and blocked-action events into the SIEM so governance evidence is queryable alongside operational detections.

Key takeaways

• Kubernetes AI governance fails most often at the boundary between tools, not inside any single platform.
• Packaging models, prompts, code and configuration as one versioned artefact is what makes provenance usable.
• Runtime policy and audit trails are the controls that turn self-hosted AI from a deployment exercise into a governed system.

Related NHI Mgmt Group resources: AI Governance Platform Buyer's Guide · Open Source Security Guide · Enterprise AI Copilot Security Guide · AI Security Platform Buyer's Guide

Key terms

• ModelKit: A ModelKit is a packaged AI artefact that bundles a model with its data, code, prompts and configuration. The goal is to make one versioned object move through training, promotion and serving so governance can follow the same unit across tools and environments.
• Agent Guard: Agent Guard is a control layer for monitoring and constraining AI agent activity, especially tool calls and secret handling. It helps capture metadata, log inputs and arguments, and integrate with secret providers so credentials are not hard coded or broadly exposed. The security value comes from tighter operational visibility and safer secret delivery.
• AI Supply Chain Security: AI supply chain security is the practice of protecting the people, data, models, code, tools, and services used to build and run AI systems. It covers risks from training data, model artifacts, dependencies, prompts, connectors, and deployment pipelines, with controls for integrity, provenance, access, and change monitoring across the full lifecycle.
• Runtime Policies: Runtime policies are enforcement rules that control what a workload is allowed to do while it is running. They can be used to block dangerous actions, contain suspicious behavior, or automate response based on security requirements. In container environments, they turn detection into immediate control.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management for teams that need to connect identity control to modern platform risk. It gives practitioners a shared language for governing systems, services and AI agents across complex environments.