Security review and SBOM tracking for AI-written code

In AI CodeOps, the secure stage puts each AI change through a security review of its actual diff, records the risks as findings that can block the change, and keeps a per-project record of the SBOMs you produce. Around that, workspace policies limit what the AI may touch, secrets are stored encrypted, and the AI's code only ever runs in an isolated sandbox.

Security work on AI-written code comes down to three questions. Did this change introduce a risk? What went into the software? Where do the credentials live? This page covers what AI CodeOps does for each, and is plain about what it does not do.

Which agents run

• Security Auditor: authorisation, injection, secrets, data exposure and supply-chain risk, listed by severity with fixes. It runs in nine of the sixteen built-in workflows.
• Dependency Auditor: dependency, license and maintenance risk, with upgrade paths. It runs in Dependency Refresh and Release Readiness.
• Architect and ADR Writer: scope, data flow and the record of the agreed mitigations in Threat Model.

The workflows built for security work:

The Security Auditor also has a step in Parallel Review, Swarm Inspection, Feature SDLC, Data Migration and Release Readiness. Threat Model records its result as a proposed ADR for a person to accept.

These agents are language models reading code and plans. They do not query a vulnerability database, and they only run when a session runs. Treat them as an extra reviewer next to the scanners you already use.

Security findings that block

Whatever the workflow, every session that changes code ends with a findings review of the real diff. Security is one of its categories, next to quality, dependency, compliance and others. Each finding has a severity from info to critical and a recommendation.

The Security page (under Secure) lists open security findings by severity and gives the workspace a simple score. Each finding has a Fix with AI button that starts a run aimed at it. Open findings of high or critical severity block the change at the gate until they are fixed or triaged. See AI code review.

SBOM records per project

A software bill of materials (SBOM) lists the components and licenses inside a build. AI CodeOps keeps a history of the SBOMs you produce for each project. A record holds:

• the format, CycloneDX or SPDX, and its version;
• the component count and the vulnerable component count you report;
• a license summary: how many components use each license;
• a SHA-256 hash and a link to the SBOM file, so anyone can match the record to the file;
• the commit it describes and where it came from, such as CI or a manual upload.

The newest record is the project's current SBOM. The project page shows recent ones, and the Security page rolls the license summaries of every project's current SBOM into one view.

AI CodeOps does not generate SBOMs, and it does not store or parse the SBOM file itself. Generate it with the tool you already use, then record it. In the open beta that is a request to /api/sbom from a signed-in session; there is no upload form and no API-key route for it yet. The body is:

{
  "projectID": "checkout",
  "commitSHA": "4f2a9c1e7b3d",
  "format": "cyclonedx",
  "formatVersion": "1.5",
  "downloadURL": "https://artifacts.example.com/checkout/4f2a9c1e7b3d/bom.json",
  "sha256": "9d1c5e0b7a2f4c6e8d0b1a3c5e7f9a2b4d6c8e0f1a3b5c7d9e2f4a6b8c0d1e3f",
  "componentCount": 412,
  "vulnerableCount": 3,
  "licenseSummary": { "MIT": 301, "Apache-2.0": 74, "ISC": 29, "BSD-3-Clause": 8 },
  "generationSource": "ci"
}

To look inside a CycloneDX file without signing in, use the free SBOM viewer. It reads the file in your browser and never uploads it.

Quality gates involved

• Findings gate. Open high or critical findings, security ones included, block the pull request and a merge from the console. A security review that did not complete holds the change too.
• Path and action policies. Rules can ask for approval on or deny changes to sensitive paths (diff.apply), MCP tool calls (mcp.invoke), the test commands (shell.command), pull requests to a repository (github.push) and automatic deploys (release.deploy). A none trust setting makes sessions read-only unless a rule allows more. See approvals and policies.
• Human approval. The person who started a session cannot cast the approving vote while another approver exists in the workspace.
• License policy from CI. When your pipeline calls the release check with a list of banned licenses (disallowedLicenses=GPL-3.0,AGPL-3.0), the check fails if the project's latest recorded SBOM contains one of them. A project with no SBOM to check fails it too: no evidence is not a pass. It looks at the project's current dependencies, not each commit. See the API reference.

Secrets and sandboxing

Workspace secrets are for build jobs that need credentials. They are encrypted at rest with AES-256-GCM, and saving fails rather than storing plain text if the platform's encryption key is missing. After saving, the console only shows a mask. A secret can be limited to specific workflows, given an expiry date, disabled, or rotated in place, with the rotation time and version recorded. Secrets reach build jobs as environment variables, and their values are removed from the build log. AI agents never receive them.

Code from an AI change never runs on the console's servers. Tests run in an isolated sandbox that is cut off from the network after dependencies are installed, and terminal sessions run in sandboxed pods. See the security overview for how the platform itself is protected.

What is not included

AI CodeOps has no SBOM generator, no CVE scanner and no secrets scanner for your repositories. Use your existing tools for those, record the results here, and let the review, policies and approvals cover the AI's changes.