dhayabaran

The core technical problem: Google subsidizes Antigravity tokens via aggressive prompt caching optimized for their own clients. Third-party tools break those cache hit rates, potentially increasing serving costs 5-10x per request.

That's a legitimate economic concern. But the enforcement is indefensible — zero-tolerance instant bans on paying subscribers with no warning, no graduated response, and near-zero support.

Anthropic had the same problem with Claude Code third-party tools. They communicated first, flagged it, gave people time to adjust. That's how you enforce policy without torching customer trust.

If the penalty for a gray-area OAuth usage is an instant ban with no appeal, the platform isn't buildable.

The interesting part is focusing on defenders specifically rather than making this a general purpose vuln scanner. Static analysis catches known patterns but the real gap has always been business logic flaws and broken access control, which is exactly what keeps showing up in breach after breach. The question is whether limiting this to Enterprise and Team customers is enough of a gate. If the model can find novel zero-days, the same reasoning capability in the base model can theoretically be prompted toward the same task by anyone with API access.

The "our systems were not breached" framing is doing a lot of heavy lifting here. A code change exposed SSNs for six months and they're calling it "not a breach" because nobody broke in. The data was just sitting there. That's the same pattern showing up everywhere right now. Firebase rules set to public, Supabase with no RLS, a loan app with a code error that exposes PII for half a year. The distinction between "we were hacked" and "we left the door open" doesn't really matter to the 100 people whose SSNs were out there since July.

The oauth2-proxy suggestion above is probably the easiest path for this. The main thing to watch out with nginx-level oauth is token expiry. If you set short-lived tokens (which you should), you need the proxy layer to handle refresh silently or your friends will keep getting kicked back to the login screen mid-session. If you just need Google or GitHub login for a few people, oauth2-proxy with an email allowlist is way less overhead than running a full identity provider.

The false positive problem gets worse over time too. Domains get sold, sites pivot, old content gets removed. A blocklist with no removal process and a "cry about it" attitude in the FAQ is basically a one-way reputational blackhole. At minimum it needs an expiry or re-review mechanism. Even browser safe browsing lists re-check URLs periodically.

Exactly. The fact that we've all internalized "store" as the default distribution model is itself a win for the platform gatekeepers. On desktop, nobody calls a .deb repo or a download link a "store" — it's just software distribution. Android sideloading should be the same: download an APK, verify the signature, install. The entire debate around "alternative stores" already concedes that distribution requires someone's permission.

Apollo is one of many. The broader pattern is the same across the industry — companies collect data with one set of promises and then the data ends up accessible through channels users never consented to.

I've been documenting this pattern in AI apps specifically. The number of companies shipping to production with Firebase rules set to "allow read: if true" or Supabase databases with no Row Level Security is staggering. The identity data people hand over during verification often ends up in databases with zero access controls.

LinkedIn at least has a security team. Most AI startups shipping verification flows don't.