AI-Powered Repository Security Check with Antigravity Workflow

When teams want to "move fast and break things," security is often the first thing they forget. I've seen a lot over 15 years in the industry. My approach is simple: follow the Pareto Principle (80/20). You want 80% of the security results with just 20% of the work.

In the AI era, that 20% of work can look like a single command.

Here is how we built the Antigravity workflow that checks the whole repository for security issues in several minutes. It does not cost much and does not use up all the AI's context window.

Short video demo made on a real repository:

The Initial Stack

To get a clear picture of a repository's health, one tool is not enough. We use a combination of proven, open-source scanners for the beginning:

1. Gitleaks: To find secrets like API keys and tokens.
2. Semgrep: For SCA and SAST to find bad code patterns and supply chain issues.
3. Checkov: To check IaC security (Docker, Terraform, Kubernetes).
4. OSV-Scanner: For SCA scan.

Inspecting their results manually takes a lot of time. And if you just send all their raw output directly to an AI, it becomes very expensive and confusing.

Token Economy

For a security review, the AI doesn't need to see every test that passed. It doesn't need to see the full abstract syntax tree. It only needs to know what is broken, where it is, and why it matters.

We use jq to remove the extra noise. This minifying step is very important for Token Economy.

To increase the token savings the command (workflow) may be ran with the cheapest Gemini 3 Flash. It is more than enough to receive a high-quality base report. Then the report may be reviewed with more powered models like Gemini 3.1 Pro.

Example: Minifying Results

Instead of a huge JSON file per tool, we make it small and simple. For example, here are the exact commands we use to make the results smaller:

  1. `jq '[.[] | {rule: .RuleID, file: .File, line: .StartLine}]' gitleaks-raw.json > gitleaks-min.json`
  2. `jq '[.results[] | {rule: .check_id, file: .path, line: .start.line, severity: .extra.severity}]' semgrep-raw.json > semgrep-min.json`
  3. `jq 'if type=="array" then map(.results.failed_checks[]) else .results.failed_checks end | [.[]? | {rule: .check_id, file: .file_path, line: .file_line_range}]' checkov-raw.json > checkov-min.json`
  4. `jq '[.results[]?.packages[]?.vulnerabilities[]? | {rule: .id, file: .package.name, line: "N/A", severity: ((.database_specific.severity) // "N/A")}]' osv-raw.json > osv-min.json`

By making the data 90% smaller, the AI stays focused on real problems. This makes the check much cheaper.

% ls -lh .security-artifacts | awk '{print $5, $9}'

6.3K checkov-min.json
2.6M checkov-rev-004-security-20260401-201110.json
2.4K gitleaks-min.json
19K gitleaks-rev-004-security-20260401-161824.json
19K gitleaks-rev-004-security-20260401-201110.json
107B osv-min-rev-001-security-20260406-110805.json
11K osv-raw-rev-001-security-20260406-110805.json
4.3K semgrep-min.json
61K semgrep-rev-004-security-20260401-161824.json
38K semgrep-rev-004-security-20260401-201110.json

The "One Command" Workflow

We put all these steps into one Antigravity slash command: /review-security-repo.

When we run it, the agent does exactly this:

• Identifies the environment: Checks for tools like semgrep, gitleaks, checkov, osv-scanner and jq.
• Executes Raw Scans: Runs the scanners to get raw logs.
• Applies Minification: Uses jq to strip massive metadata.
• Synthesizes Findings: Only reads the small files (gitleaks-min.json, semgrep-min.json, checkov-min.json, osv-min.json).
• Performs Review: Checks high-risk files to find complex problems that static tools miss.
• Generates an Actionable Report: Uses a strict Markdown structure instead of a generic summary.

Report Structure Snippet

The workflow forces the AI to output exactly what we need, like this:

### [Severity] - [Vulnerability Name/Rule ID]
- **Tool Source:** [Semgrep / Gitleaks / Checkov / Manual Architectural Review]
- **Location:** `[File Name]:[Line Number]`
- **Business Impact:** [Why this matters]
- **Remediation:** 
  [Actionable, copy-paste code or config fix]

Why This Works

• Repeatability: Anyone on the team can check security without being an expert.
• Audit Trail: Every raw and minified report is moved to .security-artifacts/ so we can track the history.
• Reduced Hallucinations: Because we give AI only the exact scanner results and small code pieces, it gives real fixes without making things up.

Full Workflow Code

If you want to try this yourself, here is the complete code for the /review-security-repo workflow:

---
description: "Security review of the repo"
---

- Get the current branch name and current timestamp (format: YYYYMMDD-HHMMSS). Define output file as `security-review-[branch-name]-[timestamp].md`.
- Check for a `venv` (or `.venv`) directory in the repository root. If found, use its binaries.
- Verify if `semgrep`, `gitleaks`, `checkov`, and `jq` are installed. If missing, prompt for installation and pause until confirmed.
- Execute local security scanners to capture raw audit trails:
  1. `gitleaks detect --source . -v --report-format json --report-path gitleaks-raw.json`
  2. `semgrep scan --config auto --json --output semgrep-raw.json`
  3. `checkov -d . --quiet --skip-path venv -o json > checkov-raw.json`
  4. `osv-scanner -r . --format json > osv-raw.json || true`
- Execute `jq` to strip massive metadata, passed checks, and AST dumps, keeping only critical fields to save context tokens:
  1. `jq '[.[] | {rule: .RuleID, file: .File, line: .StartLine}]' gitleaks-raw.json > gitleaks-min.json`
  2. `jq '[.results[] | {rule: .check_id, file: .path, line: .start.line, severity: .extra.severity}]' semgrep-raw.json > semgrep-min.json`
  3. `jq 'if type=="array" then map(.results.failed_checks[]) else .results.failed_checks end | [.[]? | {rule: .check_id, file: .file_path, line: .file_line_range}]' checkov-raw.json > checkov-min.json`
  4. `jq '[.results[]?.packages[]?.vulnerabilities[]? | {rule: .id, file: .package.name, line: "N/A", severity: ((.database_specific.severity) // "N/A")}]' osv-raw.json > osv-min.json`
- Read ONLY `gitleaks-min.json`, `semgrep-min.json`, `checkov-min.json`, `osv-min.json`. Filter out false positives based on repository context.
- Analyze high-risk architectural files strictly for logical flaws and cross-service least-privilege violations that static tools cannot understand.
- Generate the report in `security-review-[branch-name]-[timestamp].md`. DO NOT output generic summary tables. You MUST output an exhaustive, itemized list.
- Use the following strict Markdown structure for the report:
  ## Executive Summary
  [Brief overview of the branch's security posture]
  ## Detailed Findings
  [Iterate through EVERY validated finding. For each finding, output:]
  ### [Severity] - [Vulnerability Name/Rule ID]
  - **Tool Source:** [Semgrep / Gitleaks / Checkov / Manual Architectural Review]
  - **Location:** `[File Name]:[Line Number]`
  - **Business Impact:** [Why this matters]
  - **Remediation:** 
    ```


    [Actionable, copy-paste code or config fix]


    ```
- Create a `.security-artifacts/` directory if it does not exist. Ensure `.security-artifacts/` is appended to `.gitignore`.
- Move and rename both raw and minified reports to `.security-artifacts/` to preserve the complete historical audit trail:
  - `gitleaks-raw.json` -> `.security-artifacts/gitleaks-raw-[branch-name]-[timestamp].json`
  - `semgrep-raw.json` -> `.security-artifacts/semgrep-raw-[branch-name]-[timestamp].json`
  - `checkov-raw.json` -> `.security-artifacts/checkov-raw-[branch-name]-[timestamp].json`
  - `osv-raw.json` -> `.security-artifacts/osv-raw-[branch-name]-[timestamp].json`
  - `gitleaks-min.json` -> `.security-artifacts/gitleaks-min-[branch-name]-[timestamp].json`
  - `semgrep-min.json` -> `.security-artifacts/semgrep-min-[branch-name]-[timestamp].json`
  - `checkov-min.json` -> `.security-artifacts/checkov-min-[branch-name]-[timestamp].json`
  - `osv-min.json` -> `.security-artifacts/osv-min-[branch-name]-[timestamp].json`
- Exit execution.

What’s Next?

What tools are missing from your perfect "One Command" security check? Will be happy to receive opinions on how to further optimize the token economy while expanding the security coverage.

Comments

[ASKAR AITUOV]

Great article Alexandr!

[Alexander Tyutin Google Developer Group]

Thanks @askar_ai ! 🔥 Happy to see you here and receive such a feedback from you! ❤️‍🔥

[Agent Work]

That antigravity workflow sounds cool, but I'd still want a human in the loop. AI can flag stuff, but real security is about context. I've seen too many false positives and missed threats from automated systems.

[Agent Work]

Antigravity workflow sounds cool, but I’ve had trouble getting any AI tool to really understand the context of my repo. They catch obvious stuff, but deeper security issues still slip through. Maybe it’s just the data training?