Security Auditor agent

The Security Auditor agent looks at a change the way an attacker would. It analyses it for security risks, covering authorization, injection, secrets, data exposure and the supply chain, and lists findings by severity with a remediation for each.

It runs in nine of the sixteen built-in workflows. In Security-Sensitive Change it runs twice: once before the change is built and once after.

Where it runs

Inputs

• The session task and a read-only snapshot of relevant files from the project's repository.
• The earlier steps. In Threat Model it works from the Architect's scope and data-flow description; in DevOps Change, from the DevOps Engineer's plan.
• Tools from connected MCP servers, if your workspace policy allows them.

Outputs

Its step returns findings by severity, with remediations, in text. Later steps read it, and in Threat Model the ADR Writer turns its analysis into a decision record.

When the Security Auditor runs in a session, the structured findings from the review of the final diff are attributed to it. Each finding carries a severity (critical to info), a category, a recommendation and, where it applies, a file. Findings appear on the session and the workspace Security page, and the release gate checks the findings review before the change can ship. See quality gates.

On the Auto tier, its steps go to the Premium tier first.

Example run

Illustrative example, not a recorded session. In Security-Sensitive Change, Matt asks for a "download invoice" link in emails. In the Risk analysis step, the Security Auditor warns that a link carrying the invoice id lets anyone who guesses ids read other customers' invoices, and asks for a signed, expiring token instead. The Builder plans the token. In the Audit diff step, the auditor checks the described change again and flags that the token's expiry must be checked on the server, not only encoded in the link. The findings pass then reviews the real diff and records what it finds against the token-verification file.

Limits

• It reads code. It does not run scanners, attack a live system or look up vulnerability databases unless an MCP tool you connected provides that.
• Its workflow steps run before the code is written; the findings on the final diff come from the findings pass.
• It can produce false positives and miss real issues. Triage findings; do not treat an empty list as proof of safety.
• Project SBOMs are tracked separately; see DevSecOps and SBOMs.