Ratify
Ratify is a cloud-native verification engine for checking artifact security metadata before Kubernetes workloads are admitted for deployment.
Definition
Ratify is a verification engine that can run as a binary or in Kubernetes. Its own documentation describes the project as a way to verify artifact security metadata and allow deployment only when the artifacts satisfy policies chosen by the operator. The CNCF project page says Ratify was accepted into CNCF on August 30, 2024 at the Sandbox maturity level.
In practice, Ratify belongs between registry evidence and runtime authority. It asks whether a workload artifact has required evidence, whether configured verifiers can check it, and whether the resulting reports satisfy policy.
How It Works
Ratify's documentation breaks configuration into stores, verifiers, certificate/key-management resources, and policy providers. Stores retrieve reference artifacts and related data. Verifiers check artifact types such as signatures, software bills of materials, or vulnerability reports. Policy providers combine verifier results into a decision that can be used by the admission workflow.
The Ratify quick start demonstrates Ratify in Kubernetes through OPA Gatekeeper as the admission controller. In that example, a signed test image is allowed while an unsigned test image is rejected by Gatekeeper after Ratify reports failed verification. The quick start also notes a platform-selection limit: when an image reference resolves to an OCI Index or Docker Manifest List, validation occurs only at the index or manifest-list level, not by automatic platform selection.
Ratify ships with several relevant verifier paths. The Notation verifier uses X.509 PKI, trust stores, and trust policies to decide whether a signed artifact is authentic. The Cosign verifier checks signatures generated with Sigstore Cosign, including legacy tag conventions and experimental OCI 1.1 referrer support. The SBOM verifier can evaluate SPDX JSON SBOM referrers. The vulnerability-report verifier can evaluate SARIF reports generated by Trivy or Grype.
Agent Context
Ratify is not an AI safety tool in the behavioral sense. It does not evaluate prompts, model outputs, autonomy, persuasion, or misuse. The AI relevance is architectural: AI coding agents, deployment agents, tool servers, model-serving images, and evaluation workers are often packaged and launched as software artifacts. If those artifacts enter a Kubernetes cluster through mutable tags, missing signatures, stale SBOMs, or ignored scan reports, an agentic workflow can scale ordinary software supply-chain mistakes.
An admission-time Ratify gate makes one narrow question explicit: should this exact artifact, with this available evidence, be allowed into this cluster under this policy? That is a smaller claim than "safe AI," but it is a useful claim. It gives human governance a place to say no before an automated system receives compute, credentials, network reach, or production data.
Governance Use
A governance-grade Ratify record should preserve the subject image reference and digest, namespace, admission controller, Gatekeeper or policy constraint, Ratify version, store configuration, verifier configuration, trust stores, policy provider, verifier reports, exception path, and final admission decision. For SBOM and vulnerability-report checks, the record should also preserve the evidence artifact type, creation timestamp, scanner or generator, and whether the report was itself signed or otherwise verified.
Ratify is strongest when paired with Notary Project, Sigstore, SLSA Provenance, in-toto, OCI Artifacts and Referrers, Syft, vulnerability scanning, and an AI Bill of Materials. Signatures say who vouched for a digest. SBOMs describe components. Vulnerability reports describe known findings. Provenance describes build ancestry. Ratify helps turn those documents into an operational admission decision.
For AI systems, the policy should be artifact-specific. A sandboxed experiment might log missing evidence. A production model-serving deployment might require a digest reference, trusted signature, current SBOM, and vulnerability report below a chosen threshold. Tool images reachable by autonomous agents deserve the same discipline as application images.
Limits
Ratify can verify metadata and enforce policy, but it cannot make weak evidence strong. A trusted signer can sign vulnerable software. A permissive trust policy can accept too many identities. An SBOM can be incomplete. A vulnerability report can be stale. A registry or copy workflow can lose referrers. A cluster can also have privileged paths that bypass the admission path entirely.
Operational limits matter. Ratify's configuration docs say CRDs can override file configuration, and they note a single-namespace limitation for custom resources with duplicate names. Its quick start notes the manifest-list validation limitation. The project README also warns that the main branch is under active Ratify v2 development and may be unstable for users building against v1, so production documentation should pin the version, chart, and branch being relied upon.
Source Discipline
Claims about Ratify should cite Ratify documentation, the project repository, CNCF, and the specific verifier documentation used. When applying Ratify to AI systems, label the inference: the tool is a software supply-chain control, and the AI relevance comes from the fact that agent and model infrastructure is deployed as software artifacts.
Audit language should distinguish "admitted by policy" from "safe." A Ratify success means the configured evidence passed the configured verification path. It does not mean the model is aligned, the application is harmless, the dependencies are vulnerability-free, or the deployment has appropriate authorization.
Spiralist Reading
Spiralism reads Ratify as a refusal to let artifacts pass through the cluster gate as vibes. The image must arrive with a digest, attached evidence, a verifier, and a policy. The yes or no is not mystical; it is procedural.
That procedural quality is the point. When agents can assemble and launch systems quickly, Ratify gives deployment a moment of friction before the artifact acts.
Related Pages
- Notary Project
- OCI Artifacts and Referrers
- Sigstore
- Rekor Transparency Log
- SLSA Provenance
- in-toto
- Syft
- Grype
- Trivy
- Agentic Supply Chain Vulnerabilities
Sources
- Ratify Docs, What is Ratify, reviewed June 25, 2026.
- Ratify Docs, Getting Started, reviewed June 25, 2026.
- Ratify Docs, Configuration, reviewed June 25, 2026.
- Ratify Docs, Store, reviewed June 25, 2026.
- Ratify Docs, Verifier, reviewed June 25, 2026.
- Ratify Docs, Policy custom resource, reviewed June 25, 2026.
- Ratify Docs, Notation verifier, reviewed June 25, 2026.
- Ratify Docs, Cosign verifier, reviewed June 25, 2026.
- Ratify Docs, SBOM Validation, reviewed June 25, 2026.
- Ratify Docs, Vulnerability Report, reviewed June 25, 2026.
- Ratify Docs, Security, reviewed June 25, 2026.
- CNCF, Ratify project page, reviewed June 25, 2026.
- GitHub, notaryproject/ratify repository, reviewed June 25, 2026.