TL;DR: I had explicitly configured the agent as a security guardrail, yet it silently generated a frontend-exposed Gemini API key (Vite define) with no warning. The key was scraped and abused → ~USD 6,700 in unauthorized charges. Posting as a post-mortem + preventive suggestions.
The setup
While building CortexScope (a medical app), I explicitly configured Antigravity as my technical translator and security guardrail — I’m a physician and product manager, not a professional developer. The agent confirmed in writing that it had assimilated directives to:
Flag unsafe practices- Propose safer alternatives
- Avoid “blind obedience”
- Never close a task without real QA
What happened
Despite those directives, the workflow produced a config that exposed a Gemini API key in the frontend, baking it into the public Vite bundle — with no warning about the security or billing risk:
// vite.config.ts — representative of the exposed pattern
define: {
'process.env.GEMINI_API_KEY': JSON.stringify(process.env.GEMINI_API_KEY)
}
The key shipped in publicly readable client code, was later exploited, and generated ~USD 6,700 in unauthorized charges. 
Why I’m posting this — not assigning blame
I executed and deployed the system, and I own that part. I’m sharing it as a post-mortem + preventive-improvement suggestion, especially for non-technical users who rely on the agent as a guardrail.
Suggestions
Client-side secret detection — auto-scan for credentials embedded in the bundle (keys via define, client-unsafe vars, secrets in config), with a hard stop when the agent operates under a stated security directive.
Risk-proportional warnings whenever deployment configs that can expose credentials are generated.
“Blast-radius” mitigation for beginners — proactively suggest moving the key to a backend/proxy, restricting the API key, and setting billing caps + alerts, so a leak can’t bankrupt someone.
Documentation
Happy to share the incident docs (including the governance-prompt logs where the agent assimilates the security directive) if useful — compromised key already revoked, no patient data included. 