Building a SOC2 Audit Trail for AI-Assisted Dev

The question auditors are starting to ask isn’t whether you scan your code. Most development teams at SOC2 stage have some scanning in place. The question is whether AI-generated code goes through the same gate.

SOC2 CC7.1 (System Monitoring) under the AICPA Trust Services Criteria requires continuous evidence that your system components are monitored for vulnerabilities. When Claude Code, Cursor, or GitHub Copilot writes a chunk of your codebase, the resulting code is a system component. The evidence requirement doesn’t distinguish by authorship. Your auditor might.

What SOC2 CC7 Requires (and What It Doesn’t Say About AI)

BrassCoders maps to CC7.1 directly: the ai_instructions.yaml file it writes on every scan is a timestamped, version-anchored record of what the scanner found in your code — tied to the git commit hash at scan time.

The AICPA publishes the Trust Services Criteria at aicpa-cima.com. CC7.1 asks for evidence of ongoing detection of vulnerabilities in system components. The criteria document was written before the current wave of AI coding assistants, so it doesn’t mention Claude Code or Copilot by name. What it says is: vulnerabilities in your system components need to be detected and monitored. Your AI assistant’s output is a system component the moment it lands in your repository.

The practical implication: if your CI gate runs BrassCoders only on commits from a specific team member, or only on manually authored PRs, you have a gap. The audit evidence shows scanning ran — but not that it ran on all code paths. That gap is what this post is about closing.

The earlier post on SOC2 artifact evidence at BrassCoders covers the mechanics of 90-day artifact retention, the contents of detailed_analysis.yaml, and how to link the artifact to a specific commit. Read that first if you’re setting up a BrassCoders-based audit program from scratch. This post picks up where that one stops: the AI-specific addition to your evidence package.

The Evidence Record BrassCoders Produces

BrassCoders writes .brass/ai_instructions.yaml on every scan — a YAML file structured for AI assistant consumption but equally readable as a compliance artifact.

The file records: the BrassCoders version, the git commit hash, per-scanner status (ran, skipped, or errored), and per-finding detail including scanner name, rule ID, severity, file path, and line number. Because it’s generated by the same scanner ruleset on every run, the output is reproducible. Run the same BrassCoders version against the same commit and you get the same findings. Auditors can verify this.

The version pin matters more than it seems. A finding present in build 103 that disappears in build 104 should correspond to a code change, not a change in which scanner version ran. BrassCoders’s --version output appears in the YAML header, so the evidence record includes which exact scanner configuration produced it. That’s a stronger claim than “we run scanning” — it’s “we ran this version of this scanner against this commit on this date.”

For teams using brasscoders --offline: the offline flag makes the OSS core send zero bytes off-machine during the scan. The .brass/ai_instructions.yaml file still writes locally with full fidelity — same findings, same scanner statuses, same commit hash anchor. The network behavior of the scan doesn’t alter the evidence record. Upload the artifact to your CI artifact store after the scan completes; that’s the only outbound transfer in the chain, and it’s under your control.

Wiring the Scan Into the CI Audit Trail

BrassCoders integrates with GitHub Actions via a documented workflow pattern that puts the scan before the merge gate, not after it.

The placement is the audit-critical detail. A scan that runs after a PR merges is a monitoring run. A scan that runs before the merge gate fires — and that gates merge on a clean result — is a change-control gate. CC7.1 wants ongoing monitoring; CC8.1 (change management, covered in the companion post) wants evidence that changes were tested before implementation. The same CI step satisfies both when it’s positioned correctly.

The full GitHub Actions integration is documented at /guides/add-brasscoders-to-github-actions/. The core pattern:

- name: Install BrassCoders
  run: pip install brasscoders

- name: Run BrassCoders scan
  run: brasscoders scan .

- name: Upload .brass/ artifacts
  uses: actions/upload-artifact@v4
  with:
    name: brasscoders-scan-${{ github.sha }}
    path: .brass/
    retention-days: 90

Naming the artifact with ${{ github.sha }} ties the artifact to the exact commit. Your auditor can pull any artifact from the build list, check the SHA in the artifact name, match it to the commit hash inside ai_instructions.yaml, and confirm they match. No additional scripting needed. The provenance is embedded in the artifact itself.

For teams whose AI assistant generates large PRs in a single push: BrassCoders doesn’t require you to tag or annotate which files were AI-authored. The scan runs against all changed files. The evidence record captures all findings regardless of how the code was written. That’s the point — the scan gate is uniform.

What the Auditor Sees

BrassCoders’s CI artifact chain addresses the three things a SOC2 auditor reviewing CC7.1 evidence typically wants: proof the scan ran, proof it ran on the relevant code, and proof the output was retained.

The GitHub Actions run log shows the scan step executed and when. The artifact — named with the commit SHA — shows it ran against that specific commit. The YAML content shows what was found. The 90-day retention window covers the standard Type II audit period.

The question they may ask next: does your gate apply to AI-authored PRs specifically, or could an AI-authored PR bypass the scan? The answer lives in your branch protection rules, not in BrassCoders. If branch protection requires the BrassCoders workflow to pass before a PR can merge — and that rule applies to all branches feeding into main — then no PR bypasses the gate, AI-authored or otherwise. That’s a GitHub or GitLab configuration question; BrassCoders doesn’t control branch protection. But the evidence it produces gives auditors something concrete to evaluate against that configuration.

One more thing auditors are starting to note: AI coding assistants can generate code faster than a human reviewer reads it. A PR that arrives with 800 lines of AI-generated Python and a two-sentence description is a review surface area problem. BrassCoders’s scan-before-merge gate is a partial answer — it catches pattern-based issues before the reviewer has to find them manually. The evidence record shows the catch happened before merge, not after the fact.

The AI-Specific Addition to Your Evidence Package

BrassCoders’s scan produces the same artifact whether the code came from a human or an AI assistant — and that uniformity is exactly the evidence an auditor needs when asking about AI-generated code review.

SOC2 programs built before AI coding assistants became mainstream typically document a human code review process: PR submitted, reviewer assigned, approval required. That process still applies. What’s new is the question of whether the AI-generated code that the human reviewer approved was also machine-scanned before that approval decision was made. The .brass/ai_instructions.yaml file in CI is the answer to that question.

The AI-specific addition to your evidence package is two things. First, confirm your CI gate fires on AI-generated PRs the same as human-authored ones — document this in your security controls narrative as “automated static analysis gates apply to all code merged to main, regardless of authorship.” Second, retain the BrassCoders artifacts for those PRs at the same 90-day standard as all other builds. The artifact name includes the commit SHA; your git history shows which commits originated from AI-assisted sessions if you maintain that attribution in commit messages.

Neither of these requires special BrassCoders configuration. The scanner doesn’t know or care who authored the code. That’s a feature, not a gap. AI-generated code runs through Bandit, Pylint, Pyre/Pysa, Semgrep, detect-secrets, and the six custom detectors — the same 12-scanner pass that runs on every commit. The evidence record reflects what was actually there, produced by a deterministic process that any auditor can verify by re-running the scan.

---

Install with pip install brasscoders and wire the scan into your merge gate today. The AI-specific evidence question gets a lot easier when the same artifact you’ve always been producing is also the one that answers it.

Full SOC2 artifact guide and retention setup →