The usual argument for AI governance tooling is that a regulator is about to require it. In 2026 that argument stopped being true. Three things happened in the first seven months of the year and all three cut the same way: the United States rescinded the memoranda that created its secure software attestation regime, the European Union pushed its AI Act high-risk obligations back by 16 to 24 months, and the one NIST document positioned to create an AI-authorship obligation considered the question and declined it. This page sets out all three with the primary text quoted rather than summarised.
Every quotation below was taken from the primary document — the OMB memorandum PDF, the Official Journal text of the amending regulation, and the NIST publication PDF — and each is attributed to the document it came from. Where something was counted rather than read, the page says it was counted. Where something was not found, that means it was looked for and not found, which is not the same as proving it does not exist.
The conclusion is stated up front so nothing here reads as a build-up to a sales pitch: no regulator is forcing anyone to record which parts of a codebase an AI wrote, or which human agreed the behaviour it implements. If a compliance deadline is the only reason you were considering governance tooling, the honest advice is to wait. The rest of the page is about what follows from that.
On 23 January 2026 the Office of Management and Budget issued Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security. It rescinds the two memoranda that created and extended the federal secure software development attestation regime.
“OMB Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices (M-22-18), imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments. This policy diverted agencies from developing tailored assurance requirements for software and neglected to account for threats posed by insecure hardware. Accordingly, OMB Memoranda M-22-18 and M-23-16, a companion policy, are hereby rescinded.”
— OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security, 23 January 2026. Read it and check the wording.
That reasoning is an argument against a whole category of tooling, including this one, and hiding it would make the rest of the page worthless. OMB did not say the attestation was pointless paperwork attached to a good idea. It said the regime was “unproven and burdensome”, that it “prioritized compliance over genuine security investments”, and that it “diverted agencies from developing tailored assurance requirements”. Anyone selling a governance artifact has to answer that charge on the merits, because a policy office that ran the experiment for three years concluded the artifact was displacing the work rather than evidencing it.
The form itself survives, and the precise wording matters. The same memorandum keeps the inventory duty and leaves the attestation form available:
“Agencies shall continue to maintain a complete inventory of software and hardware and develop software and hardware assurance policies and processes that match their risk determinations and mission needs. Agencies may choose to use the government-wide secure software development resources developed under M-22-18, such as the Secure Software Development Attestation Form.”
— OMB Memorandum M-26-05, same document.
“May choose” is the load-bearing phrase. The correct description is that the mandate was rescinded and the form survives as optional — not that the attestation was abolished, and not that it was withdrawn. A vendor telling you the federal attestation still requires anything of you in 2026 has not read M-26-05.
Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 — the Digital Omnibus on AI — amends Regulation (EU) 2024/1689, the AI Act, together with Regulations (EU) 2018/1139 and (EU) 2023/1230. Its Recital 40 records the position it is changing:
“Article 113 of Regulation (EU) 2024/1689 establishes the dates of entry into force and application of that Regulation, in particular that the general date of application is 2 August 2026.”
— Regulation (EU) 2026/1744 of 8 July 2026, Recital 40.
Article 113, third paragraph, point (c) is replaced by:
“(c) Chapter III, Sections 1, 2, and 3, with the exception of Article 6(5), shall apply from: (i) 2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III; and (ii) 2 August 2028 as regards AI systems classified as high-risk pursuant to Article 6(1)”
— Regulation (EU) 2026/1744 of 8 July 2026, amending Article 113 of Regulation (EU) 2024/1689.
So the general date of application for those obligations moved from 2 August 2026 to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and to 2 August 2028 for those classified under Article 6(1). That is 16 months and 24 months respectively. The right word is slipped, not cancelled: the obligations are still coming, and Chapter III is still Chapter III when it arrives.
Said plainly: anyone who bought AI governance tooling to meet an August 2026 deadline bought it 16 months early. That is a real cost borne by real buyers, and it is the second thing in six months to move the deadline for this category further away rather than closer.
NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, is the one federal document positioned to say that AI-generated source code must be identified as such. It considered the question and said the opposite, in its Scope:
“Practices and tasks in this Profile do not distinguish between human-written and AI-generated source code, because it is assumed that all source code should be evaluated for vulnerabilities and other issues before use.”
— NIST SP 800-218A, Scope.
That is a considered position, not an oversight, and it is a defensible one. If every line is reviewed and tested regardless of who or what produced it, then knowing the author adds nothing to the security case. Read narrowly — as a question about vulnerabilities in code — NIST is right.
Measured rather than assumed: the exact phrase “coding assistant” appears zero times in the document. That was counted in the extracted text of the publication, not inferred from a summary of it.
The title carries the second half of the point. The Profile is about securely building generative AI models — it is a community profile of the Secure Software Development Framework for people training and shipping foundation models. It is not about building ordinary software with those models. The document most often cited as covering AI-assisted development is scoped to a different problem.
No regulator is forcing this. The US mandate is rescinded and its successor makes the attestation form optional. The EU obligations that would have applied from August 2026 now apply from December 2027 and August 2028. The NIST profile that could have required AI-generated code to be identified states that it does not distinguish it. Three documents, three directions of travel, one conclusion.
And the corollary is the part that actually matters: no regulator is going to hand this category a mandate either. Waiting for one is waiting for something that has moved further away twice in seven months. Which means the reason to govern AI-written code has to be an engineering reason — something that pays for itself in review time, incident response and onboarding — or it is not a reason at all. A governance practice justified only by a coming rule is a practice that gets cut the moment the rule slips, and the rule just slipped.
If you did want to record that a tool wrote a change and a named human agreed it, there is currently nowhere standard to put that record. The five places it would most plausibly live were checked directly against their own specifications and documentation on 2 September 2026 — each of the five below was read at source rather than inferred from a summary:
bom-refs, and a mapping from requirement to claims to evidence with signatures. But its evidence carries author and reviewer as human names, with no way to record that a tool performed the work.What that adds up to is a gap, stated as a gap. Five specifications, none of which has a place to say “an agent wrote this, and this person agreed the behaviour on this date”. This is the limit of what was checked on those five sources on 2 September 2026 — it is not a claim that no such format exists anywhere, and any of them may have added a field since.
The obligation is not coming from a regulator. The question still arrives: which human agreed this behaviour, and when? Auditors ask it, incident reviews ask it, and every new joiner asks a version of it in their first week. It is asked whether or not a statute requires an answer, and the answer is expensive to reconstruct after the fact from chat logs and pull request titles.
Productizer’s position is narrow: that record should fall out of the lifecycle rather than be assembled for an audit. A permanent requirement id, the text that was agreed, the superseded text kept verbatim, and the human ruling recorded when a new request contradicted an old one — produced as a by-product of doing the work, because a record produced only when someone asks for it is a record nobody trusts. That is an engineering argument, and after M-26-05 it is the only kind available. Whether it is worth your time is a judgement about your own codebase, not about a deadline.
What Productizer is → · How the spec maps onto compliance frameworks →
Every quotation on this page links to the primary document it came from — the memorandum, the Official Journal, the NIST publication, the specification. Follow the link and check the wording rather than taking this page’s word for it. Independent analysis. This page is not affiliated with, endorsed by, or partnered with the Office of Management and Budget, the European Commission, the European Parliament, the Council of the European Union, NIST, the in-toto or SLSA projects, OASIS or CoSAI, the OWASP CycloneDX project, or GitHub. Quotations are verbatim from the named documents and are attributed to them; everything else is our reading of them and is not legal advice. Where the page says something was not found, that is the limit of what was checked, not a proof of absence. Regulations, standards and specifications change — verify every date and quotation against the current text before relying on it. Sources read on 2 September 2026: OMB Memorandum M-26-05 (23 January 2026), Regulation (EU) 2026/1744 of 8 July 2026, NIST SP 800-218A, the in-toto attestation predicate specification, the GitHub Artifact Attestations documentation, the SLSA v1.0 provenance specification, the CoSAI workstream 1 repository, and the CycloneDX Attestations documentation.