Keeping Secrets Out of Your Antigravity Agent's Output: Layered Defenses for Logs, Diffs, and PR Bodies

Exit 2: Logs and Audit Trails, Redacted While Streaming

Even if you protect commits, an agent's execution log is a separate exit. I keep audit logs in R2 so I can reconstruct a background agent's decisions later, but ironically there was a dilemma: the more carefully I retained logs, the more carefully the keys were retained too.

What you need here is not to block the log, but a filter that masks only the keys while letting everything flow. Pipe stdout and stderr through it, and mask both known patterns and the live values of environment variables.

#!/usr/bin/env python3
# redact_stream.py — receive agent output line by line, mask keys, pass through
import os
import re
import sys
 
# Known key formats (prefix + body)
PATTERNS = [
    re.compile(r"AKIA[0-9A-Z]{16}"),
    re.compile(r"AIza[0-9A-Za-z_-]{35}"),
    re.compile(r"gh[pousr]_[0-9A-Za-z]{36}"),
    re.compile(r"sk_live_[0-9A-Za-z]{24,}"),
]
 
# Mask the literal values of environment variables (most reliable)
SECRET_ENV_KEYS = ("FIREBASE_SERVER_KEY", "ADMOB_API_SECRET", "STRIPE_SECRET_KEY")
SECRET_VALUES = [v for k in SECRET_ENV_KEYS if (v := os.environ.get(k)) and len(v) >= 8]
 
def redact(line: str) -> str:
    for value in SECRET_VALUES:
        line = line.replace(value, "«REDACTED:env»")
    for pat in PATTERNS:
        line = pat.sub("«REDACTED:pattern»", line)
    return line
 
for raw in sys.stdin:
    sys.stdout.write(redact(raw))
    sys.stdout.flush()

The point is to make this two-tiered. Pattern matching alone misses keys in an in-house format, or keys that happen not to match the expected length. So I give top priority to replacing "the literal value stored in the environment variable." This rarely misses and reliably redacts regardless of format. When launching the agent, wiring it up as agent run ... 2>&1 | python3 redact_stream.py | tee -a audit.log protects both the screen and the audit log at once.

One thing to watch: forgetting flush() delays the log and breaks real-time monitoring. When you're watching a long-running agent from another terminal and the output arrives dozens of lines late, you notice a runaway too late. I had one close call with exactly this, so I always flush line by line.

Exit 3: PR Bodies and Chat Responses, with a Final Gate in CI

This is the exit where my opening incident happened. Even if you protect diffs and logs, when an agent copies a key into the body text "for explanation," that body passes neither the diff check nor the log filter. PR bodies and comments are often generated outside Git's management.

Put a final gate on the CI side here. With GitHub Actions, inspect both the body and the diff when a PR is opened or updated, and block the merge on detection.

name: secret-guard
on:
  pull_request:
    types: [opened, edited, synchronize]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Inspect code diff
        uses: gitleaks/gitleaks-action@v2
        env:
          GITLEAKS_CONFIG: .gitleaks.toml
      - name: Inspect PR body
        env:
          BODY: ${{ github.event.pull_request.body }}
        run: |
          printf '%s' "$BODY" > pr_body.txt
          if grep -Eq 'AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35}|gh[pousr]_[0-9A-Za-z]{36}|sk_live_[0-9A-Za-z]{24,}' pr_body.txt; then
            echo "::error::PR body contains a key-like string"
            exit 1
          fi

The advantage of making CI the final gate is that even if something slips past the local hook (including the unexpected case of an agent committing with --no-verify), it always stops here. I have the local hook and CI share a single pattern-definition file, treating .gitleaks.toml as the single source of truth so I don't have to maintain two copies.

Reducing False Positives: The Balance of Allowlist and Entropy

Right after introducing layered defense, my repositories were flooded with false positives. In the first week, of 53 alerts across all six apps, zero were real leaks; every one was a false positive. Breaking it down, AdMob app IDs, dummy test keys, long base64 icon data, and commit hashes were all getting flagged as "high-entropy strings."

In terms of false-positive rate, about 12% of all detections were initially "things a human reviewed and judged fine," and my work stalled at every step. Here is how I brought it down:

1. Declare safe-to-publish values in the allowlist. AdMob app IDs and test keys go into the [allowlist] section of .gitleaks.toml as regular expressions.
2. Exclude by file. Files that are structurally bound to be high-entropy, like base64 icons or snapshot JSON, are excluded by path.
3. Don't raise the entropy threshold too far. Lowering sensitivity misses real keys, so I permit individually via the allowlist rather than via the threshold.

After running this loop, the false-positive rate fell to 0.4% in about two weeks. What mattered even more than the numbers was the habit of leaving a comment explaining why each allowlist entry was added. If the reason a value was permitted doesn't reach my future self (or the agent), the allowlist swells unchecked and the defense becomes hollow. I always attach a line like # AdMob app id is public, safe to commit to each allowlist entry.

When a Leak Does Happen: Recovery Is the Real Work

No matter how many layers you stack, leaks never reach zero. If anything, "we detected it" almost always means "it was already written." More than improving detection accuracy, I believe the real work is how fast you can neutralize a leak after it happens.

The procedure I've committed to is fixing the priority order.

1. First, rotate the key. Invalidating the leaked key and issuing a new value is the top priority. Before deleting the commit, make the key itself unusable.
2. Next, check the blast radius. Enumerate what services the key had permission for, and check for signs of misuse (anomalous activity in the AdMob or Stripe dashboards).
3. Last, scrub the history. Removing it from history with git filter-repo and the like comes at this stage. Treat any key already pushed to a remote as "already public," and don't let scrubbing stand in for neutralization.

Get the order wrong and try to "delete the history first," and the key keeps getting used in the meantime. Even when delegating auto-remediation to an agent, this priority order is the part I feel a human should keep their hands on.

How to Combine the Three Layers (Notes From Operating It)

The three layers differ in where they stop and how fast. pre-commit is fastest and doesn't hurt the developer experience, but it can be bypassed with --no-verify. The log filter redacts without stopping the flow, but can't prevent the commit itself. CI is reliable, but stops at the PR stage, so the rework is somewhat larger.

My conclusion was to put all three layers in thinly. Lean on any single one, and the moment something gets past it you're defenseless. What matters is that the three layers share the same pattern definitions (.gitleaks.toml) and the same environment-variable list, so maintenance cost doesn't grow. As someone running several Dolice Labs sites and six apps solo, I prioritize "defenses that don't collapse even when thin" over "thick defenses." The more I delegate work to agents, the more what a human should hold onto becomes not the individual checks, but the design of the layers themselves.

I hope this helps as a first step for anyone else running multiple projects alongside agents.