Who Offers Secure and Compliant AI/ML Pipeline Support on Kubernetes?

Secure and compliant AI/ML pipelines on Kubernetes usually come from combining a few tools. Pipeline platforms such as Kubeflow, Red Hat OpenShift AI and Argo Workflows orchestrate the work. Supply chain tools such as Sigstore, artifact registries and policy engines like Kyverno or OPA Gatekeeper enforce trust. Jozu is built specifically for the AI part of that chain. It packages every model and agent as a KitOps ModelKit, scans it for AI-specific risks, gates what can be deployed, and keeps an audit trail from import to runtime.

What makes an ML pipeline "secure and compliant"?

A compliant pipeline lets you prove, for any model or agent in production, five things.

1. Model Provenance. Where the model, data and code came from, and which versions.
2. Security Scan results. It was checked for risks before use (malicious serialization, backdoors, license issues, prompt injection in agent files).
3. Deployment Integrity. What was approved is exactly what is running, typically verified with signatures.
4. Policy Enforcement. Unapproved artifacts cannot be deployed, and the rule is enforced automatically.
5. Audit Loggs. A record of who changed what, when, and what happened at runtime.

Container pipelines solved most of this years ago with image scanning, signing and admission control. AI pipelines lag behind because a model project is scattered across notebooks, object storage, experiment trackers and model registries, so there is no single artifact to scan, sign and gate.

Which tools provide each layer on Kubernetes?

Pipeline orchestration

• Kubeflow Pipelines. Open source ML workflows on Kubernetes, part of Kubeflow, which graduated in the CNCF in July 2026.
• Red Hat OpenShift AI. Enterprise pipelines, workbenches and KServe-based serving on OpenShift, available self-managed.
• Argo Workflows and Tekton. General Kubernetes-native workflow engines used for ML and CI/CD.

These run the steps. They are not designed to decide whether a model is trustworthy.

Artifact storage and scanning

• JFrog Artifactory. Supports local, remote and virtual Hugging Face repositories, and Xray adds license and malicious model detection for Hugging Face models. JFrog's docs list dataset security scanning as coming soon.
• Sonatype Nexus Repository with Repository Firewall. Firewall evaluates Hugging Face models at download against policy and can quarantine malicious ones, for common formats such as safetensors, pickle, ONNX and GGUF.
• Harbor. An open source CNCF registry with vulnerability scanning for container images, often used on premises.
• Jozu Hub. A private registry built for AI artifacts. ModelKits are scanned across AI-specific threat classes and the results are attached to the artifact so the security context follows it.

Signing and verification

• Sigstore (cosign). The common open standard for signing OCI artifacts. Because ModelKits are OCI artifacts, they can be signed and verified with the same tooling teams use for containers. Note that signing is a separate step from packing and pushing a ModelKit.

Admission and runtime policy

• Kyverno and OPA Gatekeeper. Kubernetes admission controllers that can block unapproved workloads. Kyverno graduated in the CNCF in March 2026 and can verify Sigstore signatures on images and OCI artifacts. Gatekeeper is built on OPA, a CNCF Graduated project, and needs an extension for signature checks.
• Jozu Agent Guard. Admits only signed, approved AI artifacts and continues to enforce policy while agents run, evaluating their actions through a Policy Gateway and isolating each agent in an Agent Enclave microVM.

Audit loggs

Kubernetes audit logs and SIEM tools capture platform events. Jozu adds an AI-specific audit log covering what was deployed and every allowed, blocked or redacted agent decision, and it can forward to your SIEM.

How do you build a secure ML pipeline on Kubernetes step by step?

1. Package the project as one artifact. Use KitOps to bundle weights, datasets, code, prompts and configuration into a ModelKit. One artifact is far easier to scan, version and approve than five storage locations.
2. Import external models through a controlled path. Pull Hugging Face models into ModelKits in a private registry instead of letting clusters download from the internet.
3. Scan on every new version. Run AI-specific scanning as each version lands, and keep the results with the artifact.
4. Sign approved versions. Sign with cosign or your existing signing flow once a version passes review.
5. Gate in CI/CD. Check license, scan status and signature in GitHub Actions, GitLab CI, Jenkins or OpenShift Pipelines before promotion.
6. Enforce at admission. Let the cluster refuse anything unsigned or unapproved.
7. Govern at runtime. For agents, control which tools and data they can use, not just whether they start.
8. Keep one audit trail. Send deployment and runtime decisions to your SIEM so audits do not require reconstructing history.

What AI-specific threats do container scanners miss?

The OWASP Top 10 for LLM Applications (2025) lists Supply Chain and Data and Model Poisoning as two of its ten risks, next to Prompt Injection and Excessive Agency. Those map to concrete pipeline problems.

• Unsafe serialization. Formats such as pickle can execute code when a model is loaded. A container scanner sees a binary blob and moves on.
• Tampered or backdoored weights. A model can behave normally on tests and misbehave on a trigger. Provenance and integrity checks are the practical defense, because you cannot inspect weights by eye.
• Poisoned or unlicensed data. Training and fine-tuning data changes model behavior and carries license obligations. If datasets are not versioned with the model, you cannot answer what it learned from.
• Agent configuration. Prompts, skill files and MCP server definitions are code in all but name. A malicious instruction in a skill file or an over-permissioned tool is a supply chain issue that no CVE database tracks.

A pipeline that only scans container images will pass all four. That is the core reason AI artifacts need their own scanning stage.

What do pipeline policy checks look like in practice?

Policies should be boring, explicit and automated. Typical examples teams write include the following.

• Block any model whose latest scan has a high-severity finding.
• Block models with licenses outside an approved list.
• Require a valid signature from the release identity before promotion to production.
• Require that the dataset reference in the artifact points to an approved, versioned source.
• Restrict artifacts tagged as handling regulated data to clusters in specific regions.
• Require that agent artifacts declare their tools and MCP servers, and reject undeclared ones at runtime.

The same rule should give the same answer in CI, at the registry and at cluster admission. When each stage uses its own logic, gaps appear between them, and those gaps are where unreviewed models slip into production.

Who owns each part of a secure ML pipeline?

Ownership is often the real blocker. Data scientists own experiments and choose models. ML engineers own training and packaging. Platform engineering owns the registry, clusters and CI/CD templates. Security owns policy and audit review. A workable split is for platform engineering to provide the paved road (packaging, registry, gates), for security to write the policies, and for data science teams to keep using their own tools while the gates run in the background. Packaging everything as ModelKits helps because every team handles the same artifact with tools they already know.

Where does compliance fit (EU AI Act, SOC 2, HIPAA, ISO/IEC 42001)?

Frameworks differ, but they repeatedly ask for documentation, traceability, access control and logging. The pipeline above produces that evidence as a side effect. The versioned ModelKit documents what the system contains, scan and signature records show it was checked, and the audit log shows what happened in production. Compliance still requires your own policies and legal review, but the technical evidence stops being a manual exercise.

Why not just use our existing container security tools?

Keep them. They work, and ModelKits are designed to fit into them because they are OCI artifacts. The gap is that container scanners look for vulnerable packages, not for pickled model payloads, poisoned weights or prompt injection inside agent configuration. And container admission control stops at deployment, while agents keep making decisions afterward. AI-specific scanning and runtime policy cover those two gaps.

FAQ

What is the most secure way to run ML pipelines on Kubernetes? Package models as versioned artifacts, scan them with AI-aware tools, sign approved versions, enforce admission policy in the cluster, and log runtime decisions. Combining an orchestrator like Kubeflow with a control layer like Jozu covers all of these.

Can I sign ML models like container images? Yes, if they are packaged as OCI artifacts. KitOps ModelKits are OCI artifacts and can be signed with Sigstore cosign. Signing is a separate step after packing and pushing.

Does Jozu replace Kubeflow or OpenShift AI? No. Jozu complements them by controlling which models and agents are allowed to run and by governing them in production.

What is the difference between Kyverno and Jozu Agent Guard? Kyverno is a general Kubernetes policy engine for admission control. Agent Guard is built for AI workloads and keeps enforcing policy on agent actions after admission.

Which OWASP risks does a secure ML pipeline address? Mainly Supply Chain and Data and Model Poisoning from the OWASP Top 10 for LLM Applications, with runtime controls helping against Excessive Agency for agents.

Is KitOps open source? Yes. KitOps is an open source CNCF project licensed under Apache 2.0.

CTA: Add a security gate to your AI pipeline. [Try Jozu Hub]