Skip to main content

Steer the audit

Provide additional instructions when you start an audit to guide the agents toward what matters most to you, for example "focus on high-severity vulnerabilities that map to a CVE" or "prioritize logic bugs over input validation in this mature library." Steering cannot override scope or safety rules.

Steering is optional. If you leave it blank, the agents apply their default coverage across all vulnerability categories. Use it when you have a specific concern, a compliance requirement, or context about your application that the agents would not infer from the code alone.

It is most effective when it provides context the agents cannot infer: business rules, compliance requirements, or a known threat model. For example, if a particular module handles payment processing, you can steer the agents to spend extra effort there; if you are auditing a library, you can steer them to focus on the public API surface.

Decisions you have already documented​

You do not have to repeat in steering what your repository already says. When your code ships a security policy, a scope or out-of-scope table, a stated non-goal, or a comment explaining why a control is deliberately off, the agents read it and treat the behaviour it covers as intended. They do not spend analysis budget questioning it again, and they drop a finding that falls entirely inside it instead of reporting it.

Two limits apply, and they determine what AISafe still reports:

  • A documented decision covers only what it states. It does not cover the whole category. "Administrators are fully trusted" settles a path that an administrator takes. It does not settle a path that lets an ordinary user reach the same place. That path is the bug, and AISafe still reports it.
  • Accepting a mechanism does not accept its consequences. "The team token is shared by design" settles the fact that the token is shared. It says nothing about the token never expiring, being replayable, or being written somewhere readable, so AISafe still reports those issues.

If a decision is real but nowhere in the repository, put it in steering. The agents never treat behaviour on its own, such as an unguarded route, a permissive default or a usage example, as a decision to accept that behaviour.