Jozu Hub Overview

Jozu Hub is the management plane for AI supply chain security and governance. It provides a private registry for storing, versioning, and distributing AI artifacts as ModelKits. A ModelKit is an open packaging format from the CNCF that is based on OCI Artifacts, designed for agents, models, MCP servers, datasets, prompts, skills, configurations, and policies. Jozu Hub scans the artifacts in ModelKits for security threats before they reach production, and manages the policies that govern how they run.

Jozu Hub can enforce policies when pulling ModelKits (for example to prevent distributing unsigned or vulnerable ModelKits), but it doesn't enforce policy at runtime. That is the role of Jozu Agent Guard, the secure runtime for AI agents, MCP servers, and models. Jozu Hub administers and distributes policies while Agent Guard enforces them. The two products are designed to work together, but Hub is useful independently as a governed artifact registry even in environments not yet running Agent Guard.

Jozu Hub is available as a SaaS instance hosted by Jozu, or as a self-hosted deployment on your own Kubernetes cluster (ideal for sovereign control). Some capabilities, including pull policy administration, scheduled and customizable security scans, and full organization management, are available only in self-hosted deployments. This guide covers both, and notes where behavior differs.

You can learn the basics of Jozu Hub through our SaaS quick start tutorial, or contact [email protected] for a private proof-of-value trial of the full self-hosted platform. The rest of this page covers the foundational concepts behind Jozu Hub:

• How artifacts are stored and governed
• How security scanning works
• What attestations are and why they matter
• How policies control artifact movement
• How Hub connects to Jozu Agent Guard at runtime

Private registry

Jozu Hub is typically self-hosted and used on-premises or in a virtual private cloud. It is a private OCI registry and security platform for AI artifacts. Unlike public model repositories, the Jozu Hub system and every repository and artifact it contains, is under your private organization's control: your authentication, your RBAC, your network, your audit trail.

On self-hosted deployments, Hub runs entirely inside your own Kubernetes cluster. No artifact data leaves your environment. This matters in regulated industries where model weights, training data, or fine-tuning configurations contain sensitive information that cannot be transmitted to third-party infrastructure.

On the SaaS version hosted by Jozu, repositories are scoped to your account or organization on jozu.ml.

Repositories can be set to public or private visibility. Organizations themselves are always public (their existence is visible), but the repositories inside them can be private so contents are invisible to users outside the organization. User accounts can have both public and private repositories. Creating organizations, and the more granular user management controls that come with them, is available in self-hosted deployments only.

The private registry stores every artifact type involved in an AI deployment:

• Model weights (any model type from LLMs to vision to predictive, and others)
• Training datasets and fine-tuning data
• Code and configurations
• Skills and prompts
• MCP server packages
• Security policies (ArtifactPolicy, ToolPolicy, GuardrailPolicy)

All artifacts are stored as KitOps ModelKits with SHA-256 content digests protecting every layer.

Learn to use the Private Registry

ModelKits and OCI

Jozu uses KitOps ModelKits as the artifact format for AI projects. ModelKits are OCI Artifacts that bundle everything needed to reproduce and deploy an AI project as a single versioned unit: model weights, training datasets, code, configurations, prompts, guardrail configs, MCP server specifications, and policies.

OCI was chosen because it is already the standard that container images, Helm charts, WASM modules, and other artifacts use. It has broad tooling support, well-understood security properties, and works with every major container registry. Using OCI for AI artifacts means:

• No new security workflows. Your security processes and tools already handle OCI content.
• No new distribution tooling. You can pull a ModelKit the same way you pull a container image.
• Self-verifying artifacts. Every component in a ModelKit is protected by a SHA-256 content digest. The digest verifies the artifact in any environment, including air-gapped ones, without calling back to Jozu Hub.

ModelKits also use content addressable storage, so the same blob in different ModelKits is stored once, the same way container image layers work.

Jozu is the commercial platform built on top of KitOps. KitOps is an open source CNCF Sandbox project with more than 250,000 downloads. The ModelPack specification, written by Jozu CTO Gorkem Ercan and accepted into CNCF Sandbox in May 2025, is the vendor-neutral standard that KitOps implements. Contributions come from Red Hat, Docker, PayPal, and others.

Using OCI and CNCF-governed open standards means your AI artifacts are not locked to Jozu. They can be stored in, pulled from, and verified against any OCI-compliant registry.

KitOps ModelKits plus the Jozu Hub OCI registry gives organizations the same controls, security, and usability for their AI projects that git repositories do for their code.

Scan before sharing

Jozu Hub scans AI artifacts for security threats before they are distributed to downstream environments.

Hub runs five integrated scanners that collectively address more than 10 vulnerability types that are invisible to standard container scanners.

On the SaaS version of Hub, scanning runs automatically whenever an artifact is pushed. On self-hosted deployments, scanning can additionally run on a configurable schedule, and the scanner configuration is customizable to match organizational risk tolerances and compliance requirements.

Scan results are stored as attestations to the artifact itself (see Attestations below), so every downstream system can verify what was scanned and what the results were by verifying the attestation.

Learn to use the security scanning

Attestations

An attestation is a signed, verifiable record tied to a specific artifact's SHA-256 digest. Attestations are stored in the same registry as the ModelKit they describe. They can be queried by consumers manually, automated as part of CI/CD pipelines, or used as inputs to policy decisions. Verification works in any environment with access to the registry and the signing public key, including air-gapped deployments.

Hub automatically generates attestations for two events: security scan results, and Hugging Face imports. You can attach your own attestations using Cosign for build provenance, evaluation results, human-in-the-loop approvals, license claims, or any custom signed statement about an artifact.

Attestations in Jozu Hub serve three functions:

• Supply chain evidence - proof that a specific artifact was the subject of a specific event (scan, build, approval) at a specific time
• Policy evaluation inputs - ArtifactPolicy, ToolPolicy, and GuardrailPolicy can require specific attestations as a precondition
• Compliance documentation - cryptographic proof of scans, approvals, and decisions for audit purposes

See the Attestations guide for how to attach custom attestations, capture build provenance for fine-tuned models, and verify attestations outside Hub.

Jozu policies

Registry policies

Pull policies govern artifact egress from the Jozu Hub. They can require that artifacts meet conditions at the time they are pulled or deployed.

All Jozu policies use CEL (Common Expression Language) for conditions, giving fine-grained control over evaluation logic. Policies are authored in YAML and distributed as signed OCI artifacts, so the policies themselves are subject to the same integrity verification as the artifacts they govern.

Policies are versioned in Hub alongside the artifacts they govern. Rolling back to a previous policy version is the same operation as rolling back any other OCI artifact.

Runtime policies

In addition to policies that run on Jozu Hub, Jozu also provides policies executed during runtime with Jozu Agent Guard:

ArtifactPolicy evaluates at admission time, when an artifact is about to be loaded into the runtime. It checks signature requirements, scan result thresholds, license compliance, and provenance requirements. An artifact that fails ArtifactPolicy does not execute.

ToolPolicy evaluates at runtime, at every MCP tool invocation. It controls which agents can call which tools, validates tool arguments, enforces rate limits, and triggers human-in-the-loop confirmation for high-risk operations. ToolPolicy re-evaluates at every invocation, not just at session start, which limits inherited privilege abuse across delegation chains.

GuardrailPolicy evaluates at runtime, on every inference request and response. It enforces content safety thresholds, PII detection, prompt injection defense, and toxicity filtering. Thresholds are policy-driven, not hardcoded, so they can be tuned to organizational requirements.

All three policy kinds use the same YAML-plus-CEL authoring format, are versioned and signed as OCI artifacts in Hub, and are distributed to Agent Guard instances through standard OCI pull.

Integration with Agent Guard

Jozu Hub and Jozu Agent Guard have distinct roles but work together.

Hub is the management plane. It stores artifacts, runs security scans, manages policies, and maintains the audit repository. It can enforce policies at pull time, but does not enforce policies at runtime.

Agent Guard is the enforcement runtime. It runs agents, models, and MCP servers inside an isolated execution environment and enforces policies on every artifact load, tool invocation, and prompt or response. It does not store artifacts or manage policies. It receives them from Hub.

The two systems work together:

1. Policies are authored in Hub and distributed as signed OCI artifacts.
2. Agent Guard pulls the policy artifacts from Hub and verifies the policy artifact's cryptographic signature before loading it.
3. When an agent or model is pulled into the Agent Guard runtime, Jozu's ArtifactPolicy is evaluated against the artifact's attestations and digest. An artifact that fails policy conditions does not load.
4. At every MCP tool invocation, Jozu's ToolPolicy is evaluated. Policies can log or block a tool invocation, or request the user's decision.
5. At every inference request and response, Jozu's GuardrailPolicy is evaluated. Guardrails also control what types of data can be sent to, or received back from, the model or agent.
6. Every policy decision is logged locally in Agent Guard's tamper-evident audit log.
7. When Agent Guard is connected to Hub, audit log entries sync to Hub's central audit repository.

A key property of this architecture is that Agent Guard does not require connectivity to Hub to enforce policy. Once the policy artifacts are loaded, they enforce locally with no runtime dependency on Hub availability. This is not a degraded or fail-open mode: Agent Guard enforces the full policy set whether it is connected or disconnected. This makes Jozu suitable for air-gapped environments, DDIL (Denied, Disrupted, Intermittent, Limited) networks, and offline edge deployments where a cloud control plane cannot be assumed.

Agent Guard fails closed by design. If a policy artifact is missing, if an attestation cannot be verified, or if an evaluation error occurs, the default behavior is denial, not permission.