Provenance-first: making AI-generated Kubernetes manifests verifiable and safe

AI can write a tidy Deployment or Service faster than manual YAML, but the convenience carries a familiar risk: who (or what) actually owned the final manifest, and can you trust it? Treating Kubernetes manifests as first-class artifacts — signed, attested, and policy-checked before they reach the API server — changes the conversation from “Did the YAML look okay?” to “Can the cluster prove the YAML came from a trusted pipeline?” This article describes a provenance-first pattern that fits AI-assisted manifest generation into secure GitOps flows using manifest signing and policy-as-code enforcement.

Why provenance matters with AI-generated manifests

• LLMs are great at scaffolding resources and handling tedium, but they’re also fallible about specifics that matter in production: wrong API versions, missing resource requests, unsafe RBAC, or insecure probes. Research has shown LLM-based tools can find and suggest remediations for misconfigurations, but they don’t guarantee correctness or intent. Treating their outputs as authoritative without extra checks is risky. (arxiv.org)

• The bigger risk in automated workflows isn’t just a bad YAML — it’s an untrusted or unexamined YAML becoming the single source that drives clusters at scale. Provenance — a cryptographic record of who/what produced an artifact and when — lets runtime enforcement distinguish “approved, auditable pipeline output” from ad-hoc edits or malicious changes.

The provenance-first pattern (high level) Think of a manifest as a released artifact, like a compiled binary. The pattern rewires the pipeline so manifests are generated, signed, stored, and verified before being applied. A typical flow looks like this:

• AI-assisted generation: an LLM (or a developer using an LLM helper) produces Kubernetes manifests from a repo, chart, or a short spec.
• Sign and attest: the generated YAML is signed (and optionally attested with build metadata) and pushed to an artifact store or Git record.
• Policy validation in CI/GitOps: a policy engine verifies signatures and checks guardrails before manifests are merged or synced.
• Admission-time enforcement: the cluster’s admission controller (policy engine) rejects any manifests that either fail signature verification or violate enforced policies.

Each stage provides a different guarantee: the signature proves origin and immutability; attestations add build-time metadata (SBOMs, scan results, CI run IDs); policy-as-code enforces organizational guardrails both before and at admission time.

Tools that make this pattern practical today

• Sigstore / Cosign and k8s-manifest-sigstore: Sigstore’s cosign and the k8s-manifest-sigstore plugin provide a straightforward way to sign Kubernetes YAML files (keyed or keyless) and produce signatures/attestations tied to identity and transparency logs. That makes the manifest an auditable artifact rather than a transient file. (pkg.go.dev)

• Kyverno (policy-as-code): Kyverno supports validating signed Kubernetes manifests (including Sigstore-signed manifests) and can be used as an admission controller to reject unsigned or tampered manifests, or to allow specific, well-understood exceptions on a per-field basis. That capability lets policy teams require cryptographic provenance for resources before they are created in-cluster. (kyverno.io)

• GitOps controllers (Argo CD / Flux): In a GitOps setup the signed manifest or a reference to it lives in Git/OCI; Argo CD or Flux can be combined with Kyverno to ensure that only compliant, signed manifests are synced. Modern GitOps practices and tooling increasingly treat signatures and attestations as part of the delivery contract. (cncf.io)

What a signed-manifest workflow looks like in practice Below is a conceptual sketch rather than a copy-paste checklist; it’s intended to show the shape of the integration.

• Generation: The LLM produces application manifests (Deployment, Service, etc.). The manifest is committed to an artifacts repo or packaged into an OCI blob.
• Signing: The artifact is signed with Cosign or the k8s-manifest-sigstore plugin, producing an attached signature and optional attestation that links back to CI and build metadata (who ran the generation, which job produced it, what scans ran).
• Verification in CI/Git: A policy check validates the signature and attestation and evaluates policy-as-code (pod security, image provenance, resource requests, RBAC constraints). If the signature or policy check fails, the artifact is flagged and not promoted.
• Admission enforcement: Kyverno enforces that only signed manifests (or manifests matching acceptable attestations) are allowed into the cluster. Kyverno’s validate policies can be written to check signature metadata or require specific attestations, effectively blocking unsigned or untethered AI-generated YAML at admission time. (kyverno.io)

A small, conceptual Kyverno policy fragment (illustrative) Note: the following is a conceptual excerpt that highlights intent (verify that manifest signatures exist and match a trusted key). Implementations vary and the Kyverno docs have concrete examples and fields for exact configuration.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-manifests
spec:
  validationFailureAction: Enforce
  rules:
  - name: verify-manifest-signature
    match:
      resources:
        kinds: ["Deployment", "Service"]
    validate:
      message: "Manifest must be signed and verified."
      pattern:
        metadata:
          annotations:
            cosign.sigstore.dev/signature: "?*"

The real Kyverno examples include options to verify the signature against a public key or keyless identity and to allow field-level exceptions; the project documentation and policy catalog are good reference points for exact syntax. (kyverno.io)

Why this combination helps with AI risks

• Non-repudiation: A signature ties the manifest back to the pipeline that generated it. If an AI assistant creates a spec, the signing step makes that creation traceable and auditable.
• Defense-in-depth: Policy checks before merge and at admission time catch both accidental LLM mistakes (missing probes, deprecated APIs) and deliberate tampering (someone editing YAML post-generation).
• Clear ownership model: The artifact + attestation pattern separates “authoring” from “approval.” Even if an LLM drafts the YAML, the artifact is only promoted when the pipeline signs and attests to scans and approvals.

Limitations and trade-offs

• Operational overhead: Signing, attestation, and admission verification add complexity to an already multi-stage pipeline. For organizations without mature CI/CD or GitOps practices, the overhead may be non-trivial.
• Key management and identity: Keyed signing requires secure key storage; keyless signing shifts trust to identity providers and transparency logs, which has its own threat model. Both approaches require policy teams to reason about trust anchors and revocation.
• Not a substitute for review: Signatures prove origin and immutability, but they don’t prove semantic correctness. Policies need to be written to capture the organization’s safety rules, and human review still has a role for novel or risky changes. Research shows LLMs can recommend fixes but cannot be relied upon as sole validators of complex configuration correctness. (arxiv.org)

How governance looks in everyday terms Imagine a band recording: the LLM writes sheet music, but the conductor (CI/GitOps) only allows the orchestra to play if the sheet has the composer’s stamp and a studio engineer’s checksheet. Kyverno is the venue’s security guard at the door checking the stamp and checksheet before entry. The result is that music generated quickly by tools still plays through the official, audited stage rather than from a mysterious bootleg.

Closing note (what the pattern offers) Treating generated manifests as signed artifacts with attestations, and enforcing those guarantees with a policy engine, closes a big gap between the speed of AI generation and the safety expectations of production systems. It doesn’t remove the need for careful policy design and human judgment, but it gives platform and security teams a practical lever to make AI-assisted manifest generation verifiable and auditable within existing GitOps practices. The documentation and tooling around manifest signing and policy enforcement — especially Kyverno’s manifest verification features and Sigstore tooling — make this pattern achievable with existing open-source components. (pkg.go.dev)

References

• GenKubeSec: LLM-based Kubernetes misconfiguration detection and remediation research. (arxiv.org)
• Kyverno docs: manifest validation and Sigstore integration (verify-signed manifests / validate rules). (kyverno.io)
• k8s-manifest-sigstore (kubectl plugin) and Sigstore/Cosign for signing manifests. (pkg.go.dev)
• GitOps + policy-as-code: Argo CD and Kyverno integration discussions and guides. (cncf.io)