False Positive — Prohibited Use Policy (Cybersecurity / Code Injection Classifier)

Google Antigravity
1

Bug Report: Safety Filter False Positive on Defensive Software Testing / Mutation Audit

**Issue Type:** False Positive — Prohibited Use Policy (Cybersecurity / Code Injection Classifier)
**Environment:** Google Antigravity / Gemini API (gemini-3.8-flash)
**Timestamp:** 2026-09-14T20:21:21Z
**Error Message:**
> "The prompt could not be submitted. The prompt contains sensitive words that violate Google's Generative AI Prohibited Use policy."

#### 1. What Happened
A local automated coding agent was executing unit and mutation tests for a web application. Upon turn completion, the summary event payload included the ticket title and acceptance criteria for Ticket 06 ("06 — Adversarial Mutation Audit
& Edge Hardening").

The classifier flagged the response due to standard software testing terms:
- "Adversarial mutation testing"
- "Injection testing on RenterProfileModal"
- Mention of input sanitization test cases: `<script>` injection tags and boundary values
- "Mutant killers" (standard academic/industry mutation testing terminology)

#### 2. Why This is a False Positive
This is a strictly benign, defensive software engineering workflow:
- The task was verifying that our React/FastAPI application properly sanitizes user input and rejects malformed payloads.- No exploits, payload delivery systems, or unauthorized access tools were generated or requested.- Standard defensive test verification (e.g., verifying pytest kills injected mutants) should not be conflated withmalicious code generation.

#### 3. Expected Behavior
Automated software development workflows that test input sanitization or discuss mutation analysis should be recognized as defensive software engineering and allowed through the safety filter.
2

Unfortunately, this happens. You can try one of the following:

  1. (Recommended) Disable safety settings. If there’s a native way to do it, do so, otherwise read up on patching the binary.
  2. Using stand-in terms: highly annoying, but you can add a hook to PreToolInvocation where you invoke a pre-process filter that swaps out words for placeholders that don’t cause issues. You can then post-process them at any point. It’s annoying, but if you want, write a small binary that opens the last response (via checking transcript) with post-processing enabled.

Technique 1 has been proven, but you need to clean-room reverse engineer yourself.
Technique 2 also works, but it just has a lot of friction.

Best of luck.