# Who Can Attest to an AI Model, and to What

> Six kinds of AI model attestation, from a supplier’s own AIBOM to an EU notified body: who issues each, and a table of what each proves and does not.

Source: https://playciso.com/blog/who-can-attest-ai-model · Published: 2026-10-29 · Publisher: PlayCISO (https://playciso.com)

---

Anyone can attest to an AI model. The question is who issued the statement, about which exact files or which organisation, and what it claims. A supplier can declare what is in a model, a publisher can sign its files, a build platform can attest how it was built, an accredited body can certify an AI management system, and under the EU AI Act a provider or a notified body confirms that a high-risk system conforms. None of them proves the model is safe. **Who this is for:** GRC and compliance leads deciding which evidence to produce or demand, CISOs deciding what to accept from an AI vendor, and AppSec engineers who will produce the technical attestations. ## Four words that get mixed up - Attestation. An authenticated statement about something. In software supply chains, an in-toto attestation is a statement with a subject (an artefact name and its digest) and a predicate (the claim, such as “built by this workflow”). Anyone can issue one, including the supplier. - Signature. Proves who issued some bytes and that they have not changed. It is how attestations are authenticated, and it can also be applied directly to model files. - Certification. A third-party assessment against a standard by a body that is itself accredited. ISO/IEC 42001 certification is the AI example. - Conformity assessment. In the EU AI Act, the legal procedure that shows a high-risk AI system meets the Act’s requirements. Sometimes the provider does it alone; sometimes a notified body must be involved. For any of them, ask three things: who issued it, about what exact subject, and what does it claim? ## Six kinds of attestation, side by side AttestationWho can issue itWhat it provesWhat it does not proveEvidence format Supplier declarationThe supplier, or anyone acting for itWhat the supplier says is in the model and how it may be used, and who to hold to thatThat any of it is true, or that the files you received match the descriptionModel card; CycloneDX ML-BOM or SPDX 3.0 AI profile; questionnaire answers Signed self-attestationThe supplier, with a named signatoryThat this party issued these statements and they have not changed sinceThat the statements are accurate. Signing proves origin, not truthCycloneDX `declarations` with `affirmation.signatories`, a JSF `signature` on the BOM, or a detached signature Model signatureThe model publisher, using Sigstore keyless signing (an OIDC identity) or its own key or certificateThat every file is byte-for-byte what that identity signed, with nothing added or missingHow the model was built, what it learned from, or whether it is safe. A stolen key or CI identity still produces a valid signatureOpenSSF Model Signing (OMS): a Sigstore bundle holding an in-toto statement with every file’s SHA-256 Build provenance (SLSA)The build platform: GitHub Actions, Google Cloud Build, GitLab, or the SLSA GitHub generatorWhich builder produced which digests, from which source and inputs. Build L2: tampering after the build is detectable. Build L3: the build itself is hardenedThat the inputs (base model, datasets) are trustworthy or licensed, or anything that ran outside the attested build, such as training on a separate GPU clusterin-toto statement with predicate `https://slsa.dev/provenance/v1`, usually in a Sigstore bundle Management-system certificationA certification body accredited for ISO/IEC 42001 by a national accreditation body such as ANAB or UKASThat the organisation runs an AI management system meeting ISO/IEC 42001 for a stated scope, audited and then surveilledAnything about a specific model’s accuracy, security or legalityCertificate with scope and accreditation mark; link it as CycloneDX `certification-report` EU AI Act conformity assessmentThe provider (internal control, Annex VI) or a notified body (Annex VII), as Article 43 decidesThat a high-risk AI system meets the Chapter III Section 2 requirements, under a quality management systemFitness for uses outside the intended purpose. A substantial modification needs a new assessmentEU declaration of conformity (Art. 47), CE marking (Art. 48), registration (Art. 49); with Annex VII, an EU technical documentation assessment certificate Independent test reports, red-team results and audits sit alongside these. They prove what was tested, by whom, on which version, and nothing else. Ask for the version tested and compare it with the AIBOM. ## Self-attestation: the supplier speaks A model card and an AIBOM are self-attestation. They are still worth having, because they put the supplier’s claims in writing: what the base model is, which data it learned from, what it is for. If a claim is wrong, you have a record of who made it. The [CycloneDX ML-BOM worked example](/blog/cyclonedx-ml-bom-example) walks through one for Northwind Health’s Triage Assistant; the complete files are in the Pro [AIBOM Template Library](/tools/aibom-template-library). CycloneDX has a structure for this. Since version 1.6, a BOM can carry `declarations`: `assessors`, `attestations`, `claims`, `evidence` and an `affirmation` with named `signatories`. Each assessor has a `thirdParty` flag; the schema says false “indicates a self assessor”. One file can therefore hold both the supplier’s own claims and a third party’s, and say which is which. Sign the BOM itself as well, or anyone who can edit it can make it match a swapped model. ## Signing services: who vouches for the identity With Sigstore keyless signing, the signer logs in with an OpenID Connect (OIDC) identity, such as an email account or a CI workload identity like a GitHub Actions workflow. Sigstore’s certificate authority, Fulcio, issues a short-lived certificate for that identity, and the signing event is recorded in Sigstore’s public transparency log, Rekor. Sigstore vouches that the identity signed. It does not vouch that the identity is trustworthy. The verifier must say which identity and which identity provider it expects; the `model_signing` CLI makes both mandatory. For models, the format is the **OpenSSF Model Signing (OMS)** specification, introduced by the OpenSSF AI/ML Working Group in June 2025. It defines a detached signature file, usually kept in the model folder, and is PKI-agnostic: bare keys, certificate chains or Sigstore keyless signing. The specification repository holds no tools; the reference implementation is the `model_signing` package in sigstore/model-transparency, version 1.1.1 on PyPI as of October 2026. In our test of 1.1.1, the signed statement lists every file in the model folder with its SHA-256, and verification fails on a changed, extra or missing file. The [signing worked example](/blog/sign-ai-model-provenance-attestation-example) shows the commands and the real failure messages. ## Build platforms: which ones emit SLSA provenance, at which level SLSA (Supply-chain Levels for Software Artifacts) defines build levels for the platform that produced an artefact. The current specification is v1.2. Build L1 means provenance exists; Build L2 means it is signed by a hosted build platform, so tampering after the build is detectable; Build L3 means the platform is hardened against tampering during the build. The provenance predicate type is `https://slsa.dev/provenance/v1`. BuilderWhat it emitsSLSA Build level it claimsLimits GitHub artifact attestations (`actions/attest@v4`; `attest-build-provenance` is now a wrapper on it)SLSA provenance v1 in an in-toto statement, signed with Sigstore, stored through the GitHub attestations APIBuild L2 on its own; Build L3 when the build runs in a reusable workflow that isolates it from the callerPublic repositories on all current plans. Private and internal repositories need GitHub Enterprise Cloud; not available on GitHub Enterprise Server. Private repositories use GitHub’s own Sigstore instance, which has no transparency log SLSA GitHub generator (`generator_generic_slsa3.yml`)SLSA provenance for any list of file hashes, generated in an isolated reusable workflowBuild L3 provenanceThe project says its workflows alone do not meet every Build L3 requirement: distributing and verifying the provenance is up to you Google Cloud BuildSLSA v1.0 provenance (and v0.1), predicate type https://slsa.dev/provenance/v1The docs say it “meets SLSA level 3 assurance”Only for artefacts stored in Artifact Registry: container images and Go, Java (Maven), Python and npm packages. A folder of model files has to be packaged as one of these. Set `requestedVerifyOption: VERIFIED` GitLabA provenance statement generated by GitLab Runner for build artefactsGitLab describes it as SLSA Level 2-compliant; a Level 3 option exists as an experimentThe Level 3 option is Ultimate tier, GitLab.com only and “not ready for production use”. Check how your statements are signed; GitLab points to a CI/CD component for that A build level describes the builder, not the model. If Northwind fine-tunes on a separate GPU cluster and only packages the weights in GitHub Actions, the provenance covers the packaging job. It shows which workflow published which digests, not how the weights were trained. To attest training, run it on an attested builder, or at least record its inputs (base model revision, dataset hashes) in the provenance and the AIBOM. The [identity, provenance and lineage guide](/blog/aibom-identity-provenance-lineage) covers those fields. ## Certification: ISO/IEC 42001, and who checks the certifier ISO/IEC 42001:2023 is the certifiable standard for an AI management system (AIMS). Three layers sit behind a certificate: - The certification body audits the organisation and issues the certificate for a stated scope. - A national accreditation body accredits the certification body against ISO/IEC 17021-1, the general standard for bodies that certify management systems. ISO/IEC 42006:2025, published in July 2025, adds the requirements specific to bodies that audit and certify AI management systems. ANAB in the United States runs an ISO/IEC 42001 accreditation programme. UKAS in the United Kingdom announced its first ISO/IEC 42001 accreditation, of BSI, after a pilot. - Mutual recognition. Accreditation bodies that sign the International Accreditation Forum (IAF) multilateral arrangement recognise each other’s accreditations. IAF CertSearch lets you check management-system certificates that participating certification bodies have uploaded. Certificates from unaccredited bodies exist and look much the same. Ask which accreditation body accredits the issuer for ISO/IEC 42001 specifically, read the scope (which products, sites and AI systems), and check the dates. Then remember what it covers: the organisation’s management system. It says nothing about any one model, and it is not EU AI Act conformity. ## The EU AI Act: who attests conformity, and what is in force Article 43 sets who carries out the conformity assessment for a high-risk AI system. The text below is as amended by the Digital Omnibus on AI. High-risk systemProcedureWho signs off Annex III point 1 (biometrics), harmonised standards or common specifications appliedProvider chooses: internal control (Annex VI) or Annex VIIThe provider, or a notified body of its choice Annex III point 1, standards absent, not applied or only partly appliedAnnex VIIA notified body. For systems put into service by law enforcement, immigration or asylum authorities or EU institutions, the market surveillance authority acts as the notified body Annex III points 2 to 8 (critical infrastructure, education, employment, essential services, law enforcement, migration, justice and democratic processes)Internal control (Annex VI)The provider alone. No notified body is involved AI in products under Annex I Section A (for example machinery or medical devices)The product’s own conformity procedure, which must also cover the AI Act requirementsThe notified body under that product law. Those bodies must apply for designation under the AI Act by 28 January 2028 **Internal control (Annex VI)** means the provider checks its own quality management system against Article 17, examines its technical documentation against the requirements, and checks that design, development and post-market monitoring match that documentation. **Annex VII** means a notified body assesses the quality management system and the technical documentation. It may be given full access to the training, validation and testing data sets and, only once other reasonable means are exhausted, to the training and trained models. If the system conforms, it issues an EU technical documentation assessment certificate. Either way, the provider then draws up the EU declaration of conformity (Article 47), affixes the CE marking (Article 48) and registers the system (Article 49). A substantial modification triggers a new assessment, except for changes the provider pre-determined in the technical documentation (Annex IV point 2(f)). What that documentation must hold is in the [Annex IV guide](/blog/eu-ai-act-annex-iv-technical-documentation-template). **What is in force on 29 October 2026:** - The rules on notifying authorities and notified bodies (Chapter III Section 4) have applied since 2 August 2025. - The high-risk obligations, and with them the need for a conformity assessment, apply from 2 December 2027 for Annex III systems and 2 August 2028 for AI in Annex I products. Both dates were set by the Digital Omnibus on AI. No high-risk AI system needs an AI Act conformity assessment yet. - Notified bodies. National notifying authorities designate them and they are listed in the Commission’s NANDO database. We could not query NANDO directly: its search needs JavaScript and an API key. The secondary trackers we found reported no notified body listed under Regulation (EU) 2024/1689 as of late October 2026. Treat that as unverified and check NANDO before you plan around one. - Harmonised standards. The law firm Orrick reports that the first harmonised standard under the Act, EN 18286:2026 on quality management systems, was published on 14 October 2026 through Implementing Decision (EU) 2026/2274, and that it covers Articles 11(1) and 17(1). We could not open the decision on EUR-Lex. In Orrick’s reading, a biometrics provider can choose self-assessment only when standards or common specifications cover all the essential requirements; otherwise a notified body is mandatory. - General-purpose AI models do not go through conformity assessment. Their providers have documentation duties under Article 53, which the GPAI Model Documentation Form guide covers. ## Northwind: which attestations fit the Triage Assistant Northwind Health ships Triage Assistant v2.3, a LoRA fine-tune of `mistralai/Mistral-7B-Instruct-v0.3` that drafts support replies for a human agent to approve. Here is what each kind of attestation looks like for it. AttestationNorthwind’s choiceIssued byLinked from the AIBOM as Model card and AIBOMYes: CycloneDX 1.7 and SPDX 3.0.1 filesNorthwind (self)Published with each release Signed AIBOMNot yet: the canonical files carry no BOM signatureNorthwind release keyA JSF signature on the BOM, or a detached signature next to it Model signatureYes: Sigstore keyless signing in CIThe release workflow’s GitHub Actions identity; the certificate comes from Sigstore`externalReferences` type `digital-signature` Build provenanceYes: GitHub artifact attestations, Build L2 (L3 if the job moves into a reusable workflow)GitHub Actions`externalReferences` type `attestation` ISO/IEC 42001None. Optional, and it would cover the organisation, not the modelAn accredited certification body`certification-report`, if obtained EU AI Act conformityNot required on Northwind’s own assessment: drafting support replies for a human agent is not an Annex III use. Emergency patient triage would be (Annex III point 5(d))Would be Northwind itself, by internal control, from 2 December 2027EU declaration of conformity _Fictional example. Northwind Health, Triage Assistant and its datasets, services, scores and URLs are invented for illustration; the base model and open-source libraries are real._ The pattern generalises: technical attestations (signature, provenance) are cheap and automatic in CI, so do them for every release. Organisational and legal ones (ISO/IEC 42001, EU conformity) depend on your market and the system’s use, so decide them once and record the decision. ## What to ask a supplier - Who signed the model files, with which identity and identity provider, and where is the signature bundle? - Which builder produced the provenance, at which SLSA Build level, and did the attested build include training or only packaging? - Is the AIBOM signed, and by whom? - For an ISO/IEC 42001 certificate: which certification body, accredited by whom, and what does the scope cover? - For a high-risk system placed on the EU market from December 2027: the EU declaration of conformity and, where Annex VII applies, the notified body’s certificate. The full list, by risk area, is in [the AIBOM questions to ask every AI vendor](/blog/aibom-questions-to-ask-ai-vendors). To see which framework clause each piece of evidence answers, read [the AIBOM as compliance evidence](/blog/aibom-compliance-evidence-eu-ai-act-iso-42001). Every guide and tool by role is on the [AIBOM Library hub](/aibom). ## Frequently asked questions ### Who can issue an attestation for an AI model? Anyone can make a statement about a model; what matters is who issued it and what it covers. The supplier can declare what is in the model (a model card or AIBOM). The publisher can sign the files. A build platform such as GitHub Actions or Google Cloud Build can attest how an artefact was built. An accredited certification body can certify the organisation’s AI management system to ISO/IEC 42001. Under the EU AI Act, the provider or, in some cases, a notified body confirms that a high-risk system conforms. ### What is the difference between an attestation and a certification? An attestation is an authenticated statement about something, made by whoever issues it, including the supplier itself. A certification is a third-party conformity assessment against a standard by a body that is itself accredited, such as an ISO/IEC 42001 certificate from a certification body accredited by ANAB or UKAS. Every certificate is an attestation; most attestations are not certifications. ### Does a signed model prove that the model is safe? No. A signature proves that the files are the ones a named identity signed and that nothing was added, removed or changed since. It says nothing about the training data, the evaluation results or the behaviour of the model. A signature from a stolen key or a compromised CI identity still verifies, which is why you also check the expected identity and the build provenance. ### Which SLSA level do GitHub artifact attestations provide? GitHub’s documentation says artifact attestations on their own provide SLSA v1.0 Build Level 2, and that running the build in a reusable workflow that isolates it from the calling workflow can meet Build Level 3. Attestations work in public repositories on all current plans; private and internal repositories need GitHub Enterprise Cloud. ### Can an AI model be certified to ISO/IEC 42001? Not a model as such. ISO/IEC 42001 certifies an organisation’s AI management system for a stated scope. The certificate tells you the organisation governs its AI systems in an audited way; it does not say that any one model is accurate, secure or lawful. Check which certification body issued it, which accreditation body accredits that body for ISO/IEC 42001, and what the scope covers. ### Do I need a notified body for the EU AI Act? Only in a few cases. High-risk systems in Annex III points 2 to 8 use internal control by the provider (Annex VI), with no notified body. Biometric systems in Annex III point 1 need a notified body (Annex VII) unless the provider applied harmonised standards or common specifications. AI in products under Annex I Section A follows the product’s own conformity procedure, with that sector’s notified body. The high-risk obligations apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I). ## Sources - in-toto Attestation Framework v1 (Statement, subject, predicate) - CycloneDX bom-1.7 JSON schema (declarations, externalReference types) - Sigstore documentation (Fulcio, Rekor, keyless signing) - OpenSSF: An Introduction to the OpenSSF Model Signing (OMS) Specification (25 June 2025) - ossf/model-signing-spec: the OpenSSF Model Signing (OMS) specification - sigstore/model-transparency: OpenSSF model signing (model_signing), README on main - model-signing on PyPI (1.1.1 released 10 October 2025) - SLSA v1.2: security levels (Build L0 to L3) - SLSA build provenance (predicateType https://slsa.dev/provenance/v1) - GitHub Docs: artifact attestations (Build L2, L3 with reusable workflows) - actions/attest-build-provenance README (plans and repositories) - slsa-framework/slsa-github-generator - Google Cloud Build: generate and validate build provenance - GitLab Docs: SLSA provenance - GitLab Docs: SLSA level 3 provenance attestations (experiment) - ISO: ISO/IEC 42006:2025, requirements for bodies certifying AI management systems - ANAB: ISO/IEC 42001 Artificial Intelligence Management Systems accreditation - UKAS: first accreditation for ISO/IEC 42001 certification - IAF CertSearch FAQ - AI Act Article 43: conformity assessment (AI Act Service Desk, as amended) - AI Act Annex III - AI Act Annex VI: internal control - AI Act Annex VII: QMS and technical documentation assessment - AI Act Article 113: entry into force and application - AI Act Service Desk: implementation timeline (reflects the Digital Omnibus on AI) - NANDO: notified bodies by legislation - Orrick: First harmonised technical standard published under the EU AI Act (October 2026) _Checked on 29 October 2026. PlayCISO is not affiliated with any standards body, accreditation body, vendor or project named here. This is general information, not legal advice._