AIUC-1 grades the platform. Something still has to read the output.
AIUC-1 is becoming the SOC 2 for AI agents. One of its mandatory coding-agent requirements, A008, asks for scanning logic applied to generated files and block or flag logic on any secrets it finds. That is a scan of the output an agent ships.
GRC platforms automate the evidence and the policy that get you to the certificate. Seatbelt runs the scan and hands you the report.
The code an agent ships is where the risk lands.
A008 names post-generation scanning of output files for common credential patterns as a safeguard, and its evidence spec asks you to show the scanning logic and the block or flag behavior. Those are properties of the code, provable only by reading it.
- ~40%
- of GitHub Copilot's contributions were vulnerable across the security-relevant scenarios of the first systematic assessment of AI-generated code.Pearce et al., IEEE S&P 2022
- ~20%
- of packages an AI recommends do not exist, a ready-made supply-chain target.USENIX Security, 576k samples
- A008.2
- asks for “scanning logic applied to generated files” and “block/flag logic preventing persistence of outputs containing detected secrets.” That is a scanner, written into the evidence spec.AIUC-1 A008, released 2026-07-15
The output-scanning layer, next to your compliance program.
Seatbelt reads an AI-generated application across seven surfaces and returns a Ship Read: what is exposed, what is unguarded, what is safe. It is not a replacement for your GRC platform or your auditor. It is the piece that reads the generated code, and the report attaches as evidence for the output controls.
Seven surfaces, mapped honestly to the requirements about the code.
One surface is a strong fit for a requirement. Several are partial. One maps to nothing, and the row says so rather than reaching for an ID.
| Surface | What Seatbelt reads | AIUC-1 requirement |
|---|---|---|
| Code execution | Request text reaching a shell command; attacker-controlled bytes handed to a deserializer; eval and new Function in app code; user input in a server-side template | C006Prevent output vulnerabilities (partial) |
| Secrets | Hardcoded API keys, tokens, and credentials in generated code | A008Prevent leakage of credentials and secrets (strong fit) |
| Customer data | Endpoints returning data not scoped to the requester; PII in responses and logs | A006Prevent PII leakage (partial) |
| Databases | Query construction open to injection; unsafe ORM use | C006Prevent output vulnerabilities (partial) |
| Login | Authorization on the page but not the action behind it; weak session and cookie defaults | No requirement claimed. The standard covers auth defaults at generation time, not at read time. We read this surface because it is a ship killer, not because a control names it. |
| Payments | Money paths and data handling that skip validation | A006Prevent PII leakage (partial) |
| Risky shortcuts | Admin routes on guessable paths; actions that skip authorization; import strings missing from the nearest package.json manifest | C006Prevent output vulnerabilities (partial)D001Prevent hallucinated outputs (phantom-dependency facet, partial) |
Requirement IDs are read from the live AIUC-1 standard, released July 15, 2026 and refreshed quarterly (next October 15). That update named coding agents as a focus area. We do not quote a requirement count on this page: published counts disagree, and the July release changed eight more.
One requirement we fit strongly. Three partial. One we do not claim.
A008 is the fit. Its evidence spec asks for scanning logic applied to generated files and block or flag logic on detected secrets, which is what a Ship Read is. C006, A006, and the phantom-dependency facet of D001 are partial, and we say partial because they are. It is not your whole AIUC-1 program. We name the requirements we address, not a percentage of the standard.
- It does not draft policy, run your governance workflow, or issue the certificate.
- It does not cover accountability, red-team testing, runtime tool gating, or refusal controls. Those are not scanner-shaped and stay with your auditor, your GRC platform, and your own controls.
- B010 (not claimed): its six named safeguards are all generation-time defaults, from parameterized queries to pinned dependencies to cookie flags, delivered through system prompts, scaffolding, and configuration. Static analysis is not among them. We read the code after it is written, so this is the agent's requirement, not ours. Earlier versions of this page named it as an evidence source. That was wrong, and we removed it.
- Coverage within C006 and D001 is still deepening. Where a check is not live yet, the gap runs in our test lane so the catch rate is measured the day the detector lands, not asserted before it.
- D001 (partial): orphan imports when an import or require names a package absent from the nearest
package.json(static manifest read, no network). Opt-inverify_depsadds bounded npm and PyPI registry checks for declared names. Honest limits: phantom names already listed in the manifest still pass static read; registry verify is opt-in and the report stamps whether it ran. This is the phantom-dependency / manifest-drift facet of D001, not full hallucinated-output coverage.
Every requirement carries a frequency. A safeguard is not a thing you install once.
This is the part of the standard that is easy to miss, because it is a field on the requirement page rather than a headline. Alongside Mandatory or Optional, each requirement carries a Frequency and a type. The requirement we fit strongest is due again every twelve months. The one next to it is due every three.
| Requirement | Application | Frequency | Type |
|---|---|---|---|
| A008 Prevent leakage of credentials and secrets | Mandatory | Every 12 months | Preventative |
| C006 Prevent output vulnerabilities | Mandatory | Every 3 months | Preventative |
| C008 Monitor AI risk categories | Optional | Every 12 months | Detective |
The certificate works the same way: valid for one year, with agents submitted for third-party red-teaming each quarter inside it, and a full re-audit to renew. A read that happened once, months ago, is not evidence that a safeguard is operating. That is the standard's position, not ours.
C008 is Optional, and we say so. It is the requirement a continuous read maps to: continuous reading on a set cadence, with the history to show it ran. We are not going to print Mandatory next to a requirement the standard marks Optional in order to make a product look necessary. The reason to run a check on a cadence is that code changes, not that a control table says to.
Everything above, cited.
See where the seven surfaces line up with your control set.
Run a Ship Read on a generated app and see the output evidence it produces. A008 comes due every twelve months and C006 every three, so the read has to happen again, and a single report is evidence of one moment rather than of an ongoing control. Repeating it on a cadence is your process to own; C008, the requirement that would cover it, is Optional in the standard.
Seatbelt is independent and is not affiliated with, endorsed by, or certified by AIUC or the AIUC-1 standard. Requirement names and IDs are referenced for interoperability and cited to the live standard. Product and company names are the property of their respective owners.