A plain-English overview of what two EU regulations mean for teams shipping AI-assisted code to enterprise clients — and why proving your code was checked is becoming part of the deal.
This is a general overview, not legal advice — consult qualified counsel for your specific CRA/NIS2 obligations.
Coding agents now generate a meaningful share of the code shipped by software agencies. Research comparing AI-assisted and human-written code has found AI-generated code is roughly 1.9–2.7× more likely to contain vulnerabilities. Part of that risk is structural: AI models sometimes invent plausible-looking package names that don't exist — and attackers have started registering those exact names, a supply-chain attack known as slopsquatting. At the same time, two EU regulations are arriving that put supply-chain security obligations directly into commercial contracts.
The EU Cyber Resilience Act phases in vulnerability-reporting obligations from 11 September 2026, with full application from 11 December 2027.
Software built exclusively for one specific customer is generally not considered “placed on the market” — so it falls outside the CRA's direct manufacturer obligations (CE marking, etc.) for the agency that built it. But once that code is integrated into the client's product, the client remains responsible for every integrated component and has to consolidate supplier SBOMs and technical documentation. In practice, the obligation reaches an agency contractually, through its client's compliance program — not as the agency's own CE-marking duty.
NIS2 Article 21 requires organizations in scope of the directive to manage cybersecurity risk in their supply chain — and to apply that requirement to their direct suppliers through contractual flow-down clauses. For a software agency, that means clients who are themselves in scope of NIS2 (as they transpose it into national law) start asking for contract clauses covering security measures, incident reporting, and audit rights. This reaches suppliers now, ahead of the CRA's own deadlines.
Today, a supplier typically proves security one of two ways. Organizational certifications — ISO 27001, SOC 2 — attest that the company has a process; they don't say anything about whether this specific delivery was checked. Self-produced artifacts — a SonarQube or Snyk PDF export, a pentest report — are point-in-time and editable after the fact by the party being asked to prove something. Build-provenance tooling (SLSA, in-toto, Sigstore) solves the cryptographic-tamper-evidence problem, but it's free, developer-facing tooling, self-signed by the build system — not packaged as evidence a non-technical client stakeholder can open and trust.
The gap those three approaches leave is a per-delivery, tamper-evident, independently verifiable receipt tied to the specific moment a piece of (often AI-written) code was checked — something a client can open without an account, verify without taking the supplier's word for it, and file alongside the SBOM their own compliance program already asks for.
Graneth's free, account-less MCP tool (pre_flight_check) checks AI-generated code for hallucinated/slopsquatted packages and hardcoded secrets at the moment your agent writes it. Every completed scan can produce a signed, public scan receipt — a link a client can open to see that a specific delivery was checked, without taking your word for it.
Important: a scan receipt proves the code was checked — it does not prove the code is safe, and it is not a CRA or NIS2 compliance certification. Compliance is a legal determination for you and your counsel; Graneth produces one piece of technical evidence you can bring to that conversation.
This is a general overview, not legal advice — consult qualified counsel for your specific CRA/NIS2 obligations.