Seriesaibom-library

Who Can Attest to an AI Model, and to What

aibom attestation model-signing slsa iso-42001 eu-ai-act ai-governance

October 29, 2026 · PlayCISO

TL;DR

Anyone can attest to an AI model, but each attestation proves something narrow. The supplier declares what is in the model (model card, AIBOM) and can sign that declaration. The publisher signs the model files, for example with OpenSSF Model Signing and Sigstore, which proves the files are unchanged since a named identity signed them. A build platform attests how an artefact was built (SLSA provenance: GitHub artifact attestations reach Build L2, or L3 with an isolating reusable workflow; Google Cloud Build claims level 3 for artefacts in Artifact Registry). An accredited certification body certifies an organisation’s AI management system to ISO/IEC 42001, not a model. Under the EU AI Act, most high-risk systems are self-assessed by the provider (Annex VI); notified bodies (Annex VII) are needed mainly for biometrics without harmonised standards, and the high-risk rules apply from 2 December 2027 and 2 August 2028. None of these proves a model is safe.

Put it into practice

Plan the attestations for your model

The AI Model Attestation Planner (Pro) asks how your model is built, shipped and used, then lists the attestations you need, who can issue each one, and the evidence to keep.

Open the Attestation Planner

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

Attestation	Who can issue it	What it proves	What it does not prove	Evidence format
Supplier declaration	The supplier, or anyone acting for it	What the supplier says is in the model and how it may be used, and who to hold to that	That any of it is true, or that the files you received match the description	Model card; CycloneDX ML-BOM or SPDX 3.0 AI profile; questionnaire answers
Signed self-attestation	The supplier, with a named signatory	That this party issued these statements and they have not changed since	That the statements are accurate. Signing proves origin, not truth	CycloneDX `declarations` with `affirmation.signatories`, a JSF `signature` on the BOM, or a detached signature
Model signature	The model publisher, using Sigstore keyless signing (an OIDC identity) or its own key or certificate	That every file is byte-for-byte what that identity signed, with nothing added or missing	How the model was built, what it learned from, or whether it is safe. A stolen key or CI identity still produces a valid signature	OpenSSF 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 generator	Which builder produced which digests, from which source and inputs. Build L2: tampering after the build is detectable. Build L3: the build itself is hardened	That the inputs (base model, datasets) are trustworthy or licensed, or anything that ran outside the attested build, such as training on a separate GPU cluster	in-toto statement with predicate `https://slsa.dev/provenance/v1`, usually in a Sigstore bundle
Management-system certification	A certification body accredited for ISO/IEC 42001 by a national accreditation body such as ANAB or UKAS	That the organisation runs an AI management system meeting ISO/IEC 42001 for a stated scope, audited and then surveilled	Anything about a specific model’s accuracy, security or legality	Certificate with scope and accreditation mark; link it as CycloneDX `certification-report`
EU AI Act conformity assessment	The provider (internal control, Annex VI) or a notified body (Annex VII), as Article 43 decides	That a high-risk AI system meets the Chapter III Section 2 requirements, under a quality management system	Fitness for uses outside the intended purpose. A substantial modification needs a new assessment	EU 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 walks through one for Northwind Health’s Triage Assistant; the complete files are in the Pro 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 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.

Builder	What it emits	SLSA Build level it claims	Limits
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 API	Build L2 on its own; Build L3 when the build runs in a reusable workflow that isolates it from the caller	Public 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 workflow	Build L3 provenance	The project says its workflows alone do not meet every Build L3 requirement: distributing and verifying the provenance is up to you
Google Cloud Build	SLSA v1.0 provenance (and v0.1), predicate type https://slsa.dev/provenance/v1	The 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`
GitLab	A provenance statement generated by GitLab Runner for build artefacts	GitLab describes it as SLSA Level 2-compliant; a Level 3 option exists as an experiment	The 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 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 system	Procedure	Who signs off
Annex III point 1 (biometrics), harmonised standards or common specifications applied	Provider chooses: internal control (Annex VI) or Annex VII	The provider, or a notified body of its choice
Annex III point 1, standards absent, not applied or only partly applied	Annex VII	A 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 requirements	The 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.

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.

Attestation	Northwind’s choice	Issued by	Linked from the AIBOM as
Model card and AIBOM	Yes: CycloneDX 1.7 and SPDX 3.0.1 files	Northwind (self)	Published with each release
Signed AIBOM	Not yet: the canonical files carry no BOM signature	Northwind release key	A JSF signature on the BOM, or a detached signature next to it
Model signature	Yes: Sigstore keyless signing in CI	The release workflow’s GitHub Actions identity; the certificate comes from Sigstore	`externalReferences` type `digital-signature`
Build provenance	Yes: GitHub artifact attestations, Build L2 (L3 if the job moves into a reusable workflow)	GitHub Actions	`externalReferences` type `attestation`
ISO/IEC 42001	None. Optional, and it would cover the organisation, not the model	An accredited certification body	`certification-report`, if obtained
EU AI Act conformity	Not 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 2027	EU 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. To see which framework clause each piece of evidence answers, read the AIBOM as compliance evidence. Every guide and tool by role is on the AIBOM Library hub.

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

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.

Plan the attestations for your model

The AI Model Attestation Planner (Pro) asks how your model is built, shipped and used, then lists the attestations you need, who can issue each one, and the evidence to keep.

Open the Attestation Planner