Secure AI Code

The Baz security agents: Basic Security Patterns, Advanced Security with SAST-inside, and Fixer.

Baz reviews code changes for security issues with cyber-capable models, using repository context, ticket intent, organization-specific security instructions, and fix guidance. Three agents do that work: Basic Security Patterns for common risks, Advanced Security for reasoning that depends on how the system actually behaves, and Fixer for turning a finding into a code change.

What the agents get

For every review, Baz builds structured context in and around the diff: the changed files and hunks, repository and module metadata, language, dependencies, the pull request title, source and target commits, and prior reviewer discussions. Where a ticket is linked, the context also carries its title, description, issue type, comments, parent description, knowledge-base links, issue key, and source link, so an agent can compare the code against the intent of the change.

Beyond the changed lines, Baz supplies full-file hunk diffs and deeper file context, which is what lets an agent answer 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 moves a trust boundary, or whether the implementation matches the linked ticket.

Basic Security Patterns

Basic Security Patterns reviews a change for common security risks across application code, infrastructure, and automation workflows. It is aimed at issues such as missing authentication or authorization checks, unsafe secret handling, sensitive data exposure, path traversal, shell injection, insecure CI/CD behavior, and common infrastructure misconfigurations.

The agent reads the change together with the surrounding context Baz provides. When a ticket says only workspace admins may invite users, for example, the agent can check whether the implementation verifies the caller’s role before performing the action. The result is a finding tied to a file and line range, with a description, confidence score, severity, and suggested remediation.

Advanced Security

Advanced Security uses cyber-capable models for deeper security reasoning, and is meant for issues that rules or pattern matching do not catch. It evaluates whether the code preserves the intended security property across the surrounding codebase.

If a ticket says users can rotate API keys for their own workspace, Advanced Security can reason about whether the 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. Its findings can carry severity, confidence, OWASP mappings, cross-repository references, external evidence, and a fixing prompt.

Advanced Security is configured from its agent drawer, under Baz → Agents → Baz Agents → Advanced Security. The Code reviews tab there holds branch patterns the agent should skip, so it does not run on branches where a deep security pass adds nothing.

SAST-inside

SAST-inside broadens the set of hypotheses Advanced Security investigates. It runs specialized static checks on the changed code and hands their output to the agent as candidate signals: untrusted input reaching a sensitive operation, use of an unsafe API, or a language-specific security pattern.

A signal is not a finding. The agent evaluates each one against the repository, inspecting the affected function, retrieving wrappers and helpers, searching for callers, following data transformations, identifying validation and sanitization, and deciding whether the path is reachable at all. Signals with sufficient evidence become Advanced Security findings and keep their SAST source attribution. Signals that are unreachable, adequately mitigated, unsupported, or irrelevant to the change are suppressed.

Consider a request parameter passed to process execution:

String command = request.getParameter("command");
Runtime.getRuntime().exec(command);

A static check identifies the parameter as a source and process execution as a sink. Advanced Security then investigates the path: whether the value is constrained to a fixed set, whether a wrapper escapes shell metacharacters, whether the call executes through a shell, and whether the route is reachable by an untrusted user. The static signal says where to look, and the agent decides whether the implementation creates command injection.

The same division of labor handles sanitization that lives outside the changed function:

def download(name):
    return send_file(os.path.join(ROOT, name))

Local analysis reports path traversal here, but the real answer depends on how name is produced. If every caller replaces it with a generated opaque identifier, the signal is rejected. If a caller passes a decoded request parameter, the finding is retained.

SAST-inside is one input, not the scope of the review. Defects with no recognizable source, sink, or unsafe API, such as a resource loaded by identifier and modified without verifying the requesting tenant, a write that checks role membership but not ownership, or a new branch that bypasses an existing invariant, are still found through repository-level reasoning.

SAST-inside is enabled at the organization level during controlled rollout and needs no separate reviewer configuration. Advanced Security must be enabled for the change, and usage is accounted for as part of Advanced Security. Further reading: SAST-inside: expanding the hypothesis space of agentic security review.

Full repository scan

Advanced Security is not limited to the lines touched in a pull request. Teams on the Advanced Security tier can scan whole repositories, so latent risk that was never part of a recent change still gets reviewed.

Scans start from the Full repository scan tab of the Advanced Security drawer: select the repositories to include, or all of them, then confirm. Scanning is a workspace-level action, scoped to the repositories the team already has access to in Baz, the same access model used for pull request review. The action requires the agent to be enabled and remaining security scan budget, and Baz skips a repository that already has an active scan rather than running a second one in parallel.

Instead of a diff, the agent walks the codebase itself, using the same repository context, module metadata, dependency information, and organization-specific security instructions it uses during pull request review. Each scan is tracked as a session, with its status, trigger source, and environment, and a detail page that breaks the run into stages such as setup, scanning, and findings. Findings carry the same shape as pull request findings, tied to a file and line range with a description, confidence score, severity, and suggested remediation, so repository-wide results can be triaged the same way.

Fixer

Fixer turns security findings into code changes. When a security agent produces a finding, that finding can include a fixing prompt carrying the remediation objective, the affected file and line range, and the security invariant that must be preserved.

If a finding says 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 patterns already in the repository. Findings from a full repository scan hand off to Fixer the same way pull request findings do, and Fixer opens a pull request with the change. Fixer works best when the finding is precise, which is why Baz structures every finding with file path, line range, description, confidence, severity, and optional remediation guidance.

Organization security rules

cyber.md is a convention Baz proposes for documenting the security expectations specific to your organization, product, architecture, and compliance needs, in a form both agents and reviewers can consume. Good candidates are 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.

cyber.md describes the content, not a filename Baz looks for. Discovery matches an explicit list of paths, and cyber.md is not on it. To have Baz enforce these rules during review, put the content in a file that is discovered: a security section in your AGENTS.md or CLAUDE.md, a rule under .cursor/rules/, or a Skill. Referencing cyber.md from a discovered file is not enough, since only the discovered file’s own content becomes a guideline. See Skills & Instructions for the supported paths and how rules are applied.

Further reading: Introduction to cyber.md.

FAQ