Secure AI Code

Baz uses cyber-capable models, such as Mythos Preview, to review code changes with repository context, ticket intent, organization-specific security instructions, and fix guidance.

What Baz sends to the model

For every review, Baz builds structured context in and around the diff. This can include the changed files, changed hunks, repository metadata, module metadata, language, dependencies, pull request title, source and target commits, prior reviewer discussions, and linked ticket context.

Ticket context can include the ticket title, description, issue type, comments, parent description, knowledge-base links, issue key, and source link. This allows Baz to compare the code against the intent of the change.

Basic Security agent

The Basic Security agent reviews a change for common security risks across application code, infrastructure, and automation workflows.

It is designed to catch issues such as missing authentication checks, missing authorization checks, unsafe secret handling, sensitive data exposure, path traversal, shell injection, insecure CI/CD behavior, and common infrastructure misconfigurations.

The agent reviews the code change together with the surrounding context Baz provides. For example, when a ticket says that only workspace admins should be able to invite users, the agent can check whether the implementation actually verifies the caller’s role before performing the action.

The result is a security finding tied to a specific file and line range, with a description, confidence score, severity, and suggested remediation.

Advanced Security agent

The Advanced Security agent uses cyber-capable models for deeper security reasoning.

This agent is designed for issues that are difficult to catch with simple rules or pattern matching. It evaluates whether the code preserves the intended security property across the surrounding codebase.

For example, if a ticket says that users can rotate API keys for their own workspace, the Advanced Security agent can reason about whether the API key belongs to the caller’s workspace, whether the old key is invalidated, whether audit events are emitted, and whether downstream workflows preserve the same authorization boundary.

This is where cyber-capable models are most useful. They can reason across implementation details, ticket intent, repository structure, dependencies, and existing security patterns.

Baz also supports enriched security findings. A finding can include severity, confidence, OWASP mappings, cross-repository references, external evidence, and a fixing prompt.

Fixer agent

The Fixer agent turns security findings into code changes.

When a security agent finds an issue, the finding can include a fixing prompt. That prompt gives Fixer the remediation objective, the affected file and line range, and the security invariant that needs to be preserved.

For example, a finding may say that a route is authenticated but does not verify resource ownership. Fixer can use the surrounding codebase context to add the smallest safe authorization check, following the existing patterns in the repository.

Fixer is most useful when the finding is precise. Baz structures findings with file path, line range, description, confidence, severity, and optional remediation guidance so that fixes can be generated and reviewed in context.

cyber.md

cyber.md is a recommended security instruction file for teams that want Baz to enforce their security rules during review.

Use cyber.md to document security expectations that are specific to your organization, product, architecture, and compliance needs.

Good candidates for cyber.md include authorization rules, tenant isolation requirements, secret handling rules, logging restrictions, PII policies, audit event requirements, cloud security guardrails, CI/CD trust rules, approved cryptography patterns, and product-specific threat model assumptions.

Baz’s instruction model is designed to load organization and repository-specific review guidance and apply it during review. This allows cyber-capable models to review code against your rules, not only generic security best practices.

Further reading: Introduction to cyber.md.

Full codebase scan (Beta)

Baz uses codebase context so security agents can inspect more than the changed lines. The review can include changed hunks, full-file hunk diffs for deeper exploration, module metadata, language, dependency information, repository identity, pull request identity, and deeper file context.

This allows Baz to answer questions such as whether a changed endpoint bypasses an existing authorization wrapper, whether a helper is used by both admin and non-admin paths, whether a new dependency changes a trust boundary, or whether the implementation matches the linked ticket.

Scanning a full repository

Advanced Security is not limited to the lines touched in a pull request. Teams with access to Advanced Security can trigger a scan of an entire repository, so latent risk that was never part of a recent change still gets reviewed.

Who can trigger a scan

Full repository scans are available to teams on the Advanced Security tier. Triggering a scan is a workspace-level action, so it is scoped to the repositories the team already has access to in Baz, the same access model used for pull request review.

Repository selection and scope

A full scan targets a single repository at a time. Instead of a diff, the Advanced Security agent walks the codebase itself, using the same repository context, module metadata, dependency information, and organization-specific instructions from cyber.md that it uses during pull request review. Baz prevents duplicate active scans on the same repository, so starting a new scan while one is already running on that repository is blocked rather than queued as a second parallel run.

Tracking progress with Sessions

A full repository scan is tracked as a Session, the same execution record Baz uses for reviewer runs, fixer runs, and scheduled scans. The Sessions page shows the scan's status, trigger source, and environment, and the session detail page breaks the run into stages such as setup, scanning, and findings, so teams can tell whether a scan is still in progress, completed, or failed, without waiting on a final report.

Finding severity levels

Each finding produced by a full repository scan carries a severity level, so teams can triage repository-wide results the same way they triage pull request findings. Findings are tied to a specific file and line range, with a description, confidence score, severity, and suggested remediation, and can include OWASP mappings and cross-repository references when relevant.

From findings to fixer PRs

Findings from a full repository scan can be handed to the Fixer agent the same way pull request findings are. Each finding carries a fixing prompt with the remediation objective, the affected file and line range, and the security invariant that needs to be preserved, so Fixer can open a pull request that addresses the issue using the surrounding codebase context and existing patterns in the repository.