AI security tools read your code. Something still has to record your build.

Your team is probably adding AI to security already

Most engineering teams now have at least one AI tool in the security loop. A model reviews pull requests. Another suggests fixes for static analysis alerts. A third sorts scanner findings into "look at this" and "probably noise." These tools save real time, and nothing on this page argues against them.

The useful question is which jobs they should own and which jobs need a record that comes out the same every time. The companion question is what your AI tools are reading when they make a call about your dependencies.

What AI security tools do well

• AI code review. GitHub Copilot code review leaves natural language comments and code suggestions on pull requests, and it can follow repository specific instructions. It is good at the reading work a busy reviewer skips.
• AI fixes. GitHub Copilot Autofix "automatically generates code change suggestions for CodeQL alerts found on pull requests and on the default branch." A developer gets a proposed patch next to the alert instead of a link to a CWE page.
• AI triage. Semgrep's AI features autotriage findings from Semgrep Code and suggest fixes. Semgrep documents its noise filtering as "over 95% accurate in categorizing Semgrep Code findings as false positives."

Notice the pattern in the last two. Copilot Autofix works on CodeQL alerts. Semgrep's triage works on findings from Semgrep's rule based engine. The AI adds judgment on top of deterministic output. It does not produce the underlying findings itself.

What the vendors say about the limits

The clearest statements of where AI tools stop come from the vendors themselves, which is to their credit.

• On code review, GitHub writes that "Copilot may not identify all of the problems that are present in code" and that it "has a risk of hallucination," highlighting problems that do not exist.
• On Autofix, GitHub writes that it "uses a generative model that is non-deterministic. Even with the same alert and code, it might fail to produce a viable suggestion, or the suggestion might vary across attempts."
• Also on Autofix: "The system does not know which dependency versions are supported or secure, and may suggest fabricated dependencies published under statistically probable names."

None of this makes the tools less useful. It defines their job: they produce suggestions for a person to check. That is a different job from producing the record the person checks against.

Two layers, two jobs

CRACI sits in the record layer. It replaces the GitHub Actions runner (you change runs-on to craci), and a package-aware proxy observes the build's traffic to package sources while the job runs. The output is an SBOM of what the job actually pulled, a completeness state for each job and cache, a network trace, and signed provenance linking the artifact to the build.

Where deterministic visibility is needed

"Are we affected?"

When a new advisory lands, the first question is whether any of your builds included the affected version. CISA's 2026 SBOM minimum elements put the requirement plainly: the recipient of an SBOM "should be able to conclude that a newly reported vulnerability does not affect them if the SBOM does not list the component." That conclusion only holds if the list is complete. A model can help you read the answer. It should not be the thing that decides what was in the build.

CRACI aggregates vulnerabilities across builds and repositories and re-evaluates monitored SBOMs as new vulnerabilities are published, so the question is answered from what was recorded.

Dependencies that an AI added

AI coding assistants add dependencies, and research shows they sometimes name packages that do not exist. A study presented at USENIX Security 2025 generated 576,000 code samples with 16 models and found that the average share of hallucinated packages was at least 5.2% for commercial models and 21.7% for open source models. A name that does not exist today can be registered tomorrow. Whoever or whatever added a dependency, CRACI records the package the build actually downloaded, and network egress policies can limit a job to the package sources you approve.

Audits and customer questions

An auditor or a customer's security team will ask how you know what shipped. "The model said so" is a weak answer. "Here is the SBOM recorded during the release build, its completeness state, and a signature linking it to the artifact" is a strong one. Reports export as PDF, HTML, CSV, Excel and JSON.

Repeatable answers

Some questions need the same answer no matter who asks or when. Which packages did last Tuesday's release pull? Was the image we shipped built from that commit? A generative model can phrase those answers well, but by its vendors' own account it may phrase them differently each time. A recorded build gives one answer, and CRACI's provenance signatures (Ed25519 over SHA-512) let anyone check that the artifact and the record belong together.

How the two fit together

The pattern that works is the one Copilot Autofix and Semgrep already use: deterministic data underneath, AI judgment on top.

1. Let AI code review and AI fixes work on pull requests, with a human approving every change.
2. Let CRACI record what each build pulled in and state whether that record is complete.
3. When you want AI help with dependency risk, give the model the recorded SBOM. CRACI's public REST API returns the SBOM as CycloneDX, the job's network trace and the artifact's provenance.
4. Keep the recorded SBOM, not the model's summary of it, as the evidence.

If your team writes much of its code with AI assistants, our page on AI development security covers that situation, and build-time SBOM generation explains how the record is made.