How Rig Works

Setup: prepare checks for your project

Prepare once. Check changes in seconds.

A default security rule pack provides a starting point, but can miss patterns specific to your project.

Rig spends time during setup tailoring security checks to your project. During everyday coding, it reuses those saved rules to check changes, give your agent actionable feedback, and verify repairs.

Setup is run once for a project. Your agent uses Rig’s setup skill and Rig tools to prepare the scanner for your codebase.

The setup skill runs the agent through a simple flow:

1. 1Understand the projectIdentify the languages, frameworks, and code patterns the checks need to understand.→
2. 2Assess coverageMeasure which files are covered and which vulnerability types are tested for.→
3. 3Close the gapsAdd or refine project-specific rules, then test coverage again until the coverage goal is achieved.

1. Understanding the Project

The agent gathers project-specific details such as languages, frameworks, database types, and packages for database access and authentication.

2. Assess Coverage

Rig starts with a default rule pack designed to cover most security types for most projects. But default rules can miss vulnerabilities in your specific stack.

Rig includes a coverage tool that your agent will use to assess how well the default rule pack covers your app.

For example, your application might wrap database access in its own helper. Tailoring gives checks a way to recognize that project-specific pattern.

Coverage considers two things: files covered and vulnerability types tested for. This helps direct the setup work toward areas that need more attention.

3. Close the Gaps

Rig guides the agent through a loop designed to close the gaps identified in step 2.

Rig includes a skill and specialized instructions on how to create rules that capture vulnerability types.

1. 1MeasureIdentify files and vulnerability types that need more attention.→
2. 2Refine rulesAdd checks for the relevant project patterns.→
3. 3Test againReassess coverage with the updated rules.

↶ Coverage gaps remain? Refine the rules and test again.

The agent continues this loop until the coverage goal of >80% is reached. This is Rig’s setup coverage measure across files and vulnerability types—not a claim that it detects 80% of all possible vulnerabilities.

Example Rule

A rule can look for values inserted directly into the query text, like in this example with a database helper called database.raw.

database.raw(`SELECT * FROM users WHERE name = '${name}'`);

database.raw('SELECT * FROM users WHERE name = $1', [name]);

rules:
  - id: interpolated-raw-query
    languages: [javascript, typescript]
    severity: ERROR
    message: Pass input as a separate query parameter.
    pattern: database.raw(`...${$VALUE}...`)

–

Output: saved project rules

The resulting rules are the connection between setup and everyday scanning: the scanner reuses them instead of asking the agent to rediscover the project on every check.

Setup loop → saved project rules → fast scan loop

Scans: check changes as your agent codes

Once setup is complete, work with your agent as usual. Rig connects to the coding workflow through MCP tools—tools the agent calls to talk to Rig—and hooks, which run at events such as code changes and the end of a turn.

1. 1Code changesRig tracks the changes made during the task.→
2. 2Check the diffThe scanner applies the saved rules and compares against the starting code.→
3. 3Fix or explainThe agent repairs a finding or records why it is skipping it.→
4. 4Recheck and reportRig checks repairs and supplies the result for the turn summary.

↶ Code changed during repair? Recheck with the saved project rules.

How checking the diff works

Rig retains the task’s starting code and compares it with the current changes. Checks cover the accumulated changes in the task, including later edits made to repair a finding.

The scanner reads the changed files with their surrounding code, not just isolated added lines. Rig uses a baseline comparison to identify findings associated with the changes, while retaining the current-file results to verify whether a reported issue is actually gone.

This keeps feedback focused on the work in progress. A whole-project scan is a separate operation.

How findings become fixes

Rig gives the agent structured findings with a file location, rule, severity, and explanation. The agent uses that information to edit the code, then calls Rig to check again using the configured rules.

Location: `src/users.ts`, line 18  
Rule: `interpolated-raw-query`  
Problem: a value is inserted into a raw database query.  
Repair guidance: pass input as a separate query parameter.

The agent has the choice to handle each finding:

The agent does not simply declare an issue fixed. Rig derives that status from the scan evidence, including whether the recheck covered the affected file and still matches the current code.

What if the agent forgets to call Rig?

Rig falls back to using turn hooks. The end-of-turn hook checks for missing or outdated scan evidence. For configured scans, it runs the needed check before deciding whether more agent work is required.

1. 1Check the evidenceDoes the current code have a current scan result?→
2. 2Fill the gapRun configured checks when evidence is missing or outdated.→
3. 3Return the outcomeRequest work on unaddressed findings, or report the current result.

If findings are still unaddressed, Rig can ask the agent to repair them or record reasons. This automatic loop is bounded to three repair rounds, and stops earlier on no progress, cancellation, or a scanner failure. Hook behavior depends on the host integration being enabled and trusted.

What you see at the end

Rig supplies a summary for the agent’s turn response, with the findings and verification state kept together.

---
Rig Findings
1 fixed · 1 skipped · 0 unaddressed

- Fixed: query input is now passed separately; recheck confirms resolution.
- 👀 Skipped: the training fixture remains intentionally unsafe; the reason is recorded.

The skipped issue remains unresolved even though no findings are left without a response.
---

The MCP Interface

A task identifier connects these calls to the same starting code, changes, findings, and evidence. Rig retains the scan results so the summary is based on recorded checks.