Leaked Google keys hit Gemini & TerminalPhone Tor walkie-talkie chat - Hacker News (Feb 26, 2026)

First up, the security story that has the most “wait, what?” energy: Truffle Security is calling out how Google’s long-standing guidance about `AIza…` API keys has effectively changed in the Gemini era. Historically, Google told developers these keys aren’t really secrets. They’re often embedded in client-side apps for things like Maps or Firebase, and the expectation was: restrict them if you can, but don’t treat them like a password. Truffle’s argument is that once a Google Cloud project enables the Gemini—or Generative Language—API, old keys in that same project can silently become valid for Gemini endpoints. No extra confirmation. No banner saying “hey, that public key on your marketing site can now authenticate to AI features.” And because new keys have often defaulted to “Unrestricted,” one key can suddenly span more services than the team intended. The practical risk isn’t just cost—though cost is real, because attackers can run up usage and burn quotas. The scarier angle is access scope: the post claims attackers can take a scraped key and query endpoints like `/v1beta/files` or `/cachedContents`, potentially exposing uploaded documents or cached context depending on how the project is set up. They tried to measure how widespread this could be by scanning Common Crawl from November 2025. Their reported number: 2,863 live, publicly exposed keys that worked for Gemini access. And yes, they say even Google had at least one publicly deployed key that responded successfully to a Gemini models call. On the response side, Truffle says they disclosed in late November 2025, initially got “intended behavior,” then Google reclassified it as a bug in early December, asked for the key list, and started restricting exposed keys from Gemini while working on deeper fixes. As of February 2026, it’s still in remediation. If you’re a GCP user, the immediate checklist is pretty concrete: find which projects have the Generative Language API enabled; audit key restrictions; rotate anything that’s been public; and—if you need help hunting—use scanners like TruffleHog to identify and even verify leaked keys. In other words: treat “not a secret” keys as secret-ish the moment they can authenticate to AI services.

Staying in privacy and security, there’s a very different kind of project making the rounds: TerminalPhone. This is an open-source tool on GitLab that aims to give you anonymous, end-to-end encrypted push-to-talk voice and text—over Tor hidden services. The standout detail is the implementation choice: it’s a single, self-contained Bash script. No separate server components, no accounts, no phone numbers. Your identity is basically your `.onion` address, and the call is simply one Tor hidden service connecting to another. Functionally, it behaves like a walkie-talkie rather than a live phone call. You record a complete voice message, it compresses the audio with Opus, encrypts it—by default using AES-256-CBC—and then sends it as one payload. That “record-then-send” model is intentional: the README frames it as a way to reduce traffic fingerprinting compared to continuous streaming, because you’re not producing a constant real-time pattern. It also supports in-call encrypted text chat, caller ID by exchanging onion addresses, automatic hangup detection, and even message size statistics so you can see what your audio is costing in bytes. There’s an optional QR code display too, which is a nice usability touch for sharing an onion address face-to-face. Security-wise, it goes further than many hobby projects: it offers a curated set of cipher choices—21 options—does live cipher negotiation, and even allows switching ciphers mid-call. There’s optional HMAC-SHA256 signing of protocol messages, though with a compatibility caveat: that’s not compatible with versions prior to 1.1.3. The author also tries to avoid common operational leaks, like passing secrets to OpenSSL via file descriptors so they don’t show up in process listings. The trade-offs are clearly spelled out too. You have to exchange a shared secret out-of-band. There’s no forward secrecy, so if that shared secret is compromised later, older traffic could be at risk. And, like any endpoint-secure system, if the endpoints are compromised, plaintext can leak. As for running it: it’s Linux-friendly and can work on Android via Termux, but Android needs the separate Termux:API app plus the `termux-api` package to access microphone and media functions. Dependencies are pretty standard—tor, opus-tools, sox, socat, openssl—and optionally ffmpeg. If you like tools that feel like they came from a time when “just ship a script” was the norm, this one is a fascinating read, and a reminder that anonymity plus voice is still surprisingly hard to do cleanly without relying on big platforms.

Now to developer tooling—specifically, the “let’s run multiple AI coders at once” category. Desplega.ai has open-sourced Agent Swarm under an MIT license. The architecture is a lead-and-worker setup. A lead agent receives tasks from various sources—Slack, GitHub, email, an API, or a user prompt—then breaks work into subtasks and hands them off to worker agents. Those workers run in isolated Docker containers, which is important because it keeps tool installation, repo state, and potential prompt accidents compartmentalized. There’s an MCP API server in the middle, backed by a SQLite database, to handle task distribution, coordination, and persistence. And there’s a dashboard UI that lets you watch what’s happening: agent status, task queues, and inter-agent chat. Feature-wise, it’s aiming for the stuff teams quickly need in the real world: priority queues, task dependencies, pause and resume across deployments, and scheduled work via cron or intervals so you can automate recurring maintenance. The differentiator they emphasize is “compounding memory.” The system produces searchable memories from session summaries, outcomes—including failures—and file-based notes. It uses embeddings—specifically OpenAI’s `text-embedding-3-small` in the default description—to retrieve learnings and inject them into future work. You also get “persistent identity” per agent through files like `SOUL.md`, `IDENTITY.md`, `TOOLS.md`, and `CLAUDE.md`, which sync to the database and evolve. Integrations are practical: Slack with Socket Mode and scoped permissions; a GitHub App that can react to mentions, assignments, review requests, and CI failures; and an email workflow via AgentMail with Svix-signed webhooks. There’s even Sentry support, so a worker can run an “investigate-sentry-issue” command when it’s configured. This fits into a broader trend: teams are moving from “one chat window” to “systems of agents” with state, memory, and workflow hooks. The hard part, as always, is reliability—getting predictable outcomes, not just flashy demos. But the repo seems designed to make those operational details visible rather than hand-wavy.

Let’s zoom out to AI governance and strategy, because two widely discussed items are basically about “how AI companies behave under pressure.” On the governance side: Anthropic published Responsible Scaling Policy v3, and the big change is philosophical. Their earlier policy included a clear self-imposed commitment: if capabilities outpaced their ability to keep models safe, they would pause training. That’s now removed. Anthropic’s stated reasoning is pragmatic: if careful actors pause while less careful ones keep going, the world might end up less safe. So they’re separating internal safety planning from broader industry recommendations, and reframing the policy as flexible and nonbinding—something that “can and will change.” They’re still promising public accountability: regular reports on mitigations, threat models, and capabilities, plus a “Frontier Safety Roadmap” they’ll grade themselves against. But it’s a shift from hard guardrails to a more adaptive posture. This comes amid a very real external pressure cooker: a reported clash with the Pentagon, where Anthropic is said to face an ultimatum tied to a $200 million contract—roll back certain safeguards or risk losing the deal and being effectively blacklisted. A spokesperson says the policy update isn’t related, but the timing makes the broader context hard to ignore. Anthropic also reportedly has two “red lines,” including AI-controlled weapons and mass domestic surveillance. Then there’s the strategy critique aimed at OpenAI, from Benedict Evans. His thesis: OpenAI has a scale advantage, not a durable moat. Benchmarks suggest multiple organizations can ship frontier-ish models that leapfrog each other, so unique tech advantage is fleeting. Meanwhile, usage is massive—he cites roughly 800 to 900 million users—but shallow. Only about 5% pay, and many aren’t daily users. Evans points to OpenAI’s own “wrapped” style data: a large chunk of users sent fewer than 1,000 messages in 2025. He interprets OpenAI’s interest in ads as a way to subsidize that broad, non-paying base and maybe fund pricier models to increase engagement. But he questions whether better models solve the “blank screen” problem—because chat UIs are inherently hard to differentiate, like web browsers: input box, output box. He’s also skeptical of OpenAI’s platform aspirations—identity, standards, agent ecosystems—because APIs break in real workflows, partners don’t want to become dumb pipes, and standards often don’t create lock-in when developers can multi-home. Put together, these two stories show the same underlying tension from different angles: when the market is moving fast, safety frameworks and product strategy both get stress-tested. And what looked like a principled long-term plan can morph into something more elastic once competition and contracts are on the line.

Switching gears to developer culture: one essay making the rounds argues that “being technically right” often doesn’t win inside organizations. The author’s point is not that teams are irrational, but that many companies optimize for comfort and short-term ease. Fixing things is visibly disruptive—people have to change habits, accept new constraints, and potentially look bad in front of peers. Not fixing things is invisible until it turns into an outage, a customer-facing incident, or an escalating maintenance tax. They give a telling example: a lightweight code-quality tracker that simply made warning counts visible. It was removed before a trial because visibility would reveal that warnings weren’t being reviewed. So the underlying problem continued to grow, but without the discomfort of acknowledging it. The post also criticizes “consensus” processes that turn into de facto veto power for anyone whose workflow might need to change. In theory it’s fairness; in practice it reliably blocks improvement. Another dynamic is selective enforcement: some changes must go through heavyweight approval, while other risky changes slip through because they’re familiar. And the most painful pattern they describe is “responsibility without authority.” The person with technical insight is expected to fix incidents, carry the pager, and own outcomes—yet their proposals are treated as optional suggestions. That mismatch leads to burnout, because you can see the crash coming but you can’t turn the wheel. The conclusion is blunt: you can’t communication-hack your way out of structural incentives. The reliable fix is aligning authority with responsibility—or finding an organization that already treats technical judgment as leverage rather than friction.

Next, a practical privacy problem for developers: GitHub scraping and unsolicited email. A Tell HN post alleges that some companies are scraping GitHub users’ activity—or just the raw Git data inside repositories—and emailing people marketing messages based on what they commit to or even what they star. One company named is a Y Combinator-backed startup, Run Anywhere, and the thread also mentions a wave of similar outreach from Voice.AI. The key detail here is that Git makes this easy. Commit metadata typically contains an author name and an email address. And you don’t need GitHub’s API to get it—you can often just clone a repository and parse the history. That means even if GitHub tightened API access, the underlying data structure still leaks emails unless users take steps. A GitHub employee responded that this behavior violates GitHub’s terms of service, and that GitHub can and does take action, including bans—though enforcement becomes “whack-a-mole.” Mitigations are pretty straightforward but not widely practiced: configure Git commits to use GitHub’s “no-reply” email address so contributions still link to your account without exposing a personal address. And more broadly, use aliases, GitHub-specific addresses, or a personal domain with catch-all routing so scraped addresses are easy to filter and attribute. It’s also a reputational warning for startups: developer marketing that feels like surveillance tends to backfire. Even if it “works” in the short term, it poisons trust in the ecosystem.

Now for a science item with major public health implications: Scripps Research reports a redesigned fentanyl analog that aims to keep strong pain relief while reducing the respiratory depression that makes fentanyl so lethal in overdose. The researchers used a medicinal-chemistry approach called bioisosteric replacement. Instead of doing small tweaks, they replaced fentanyl’s central ring with a very different spirocyclic structure—2-azaspiro[3.3]heptane, essentially two four-member rings joined at a single point. What’s surprising is that the analog still produced effective analgesia. The authors argue that, despite big structural changes, they preserved a key electrostatic “anchor” interaction that lets the compound activate the μ-opioid receptor. The safety-relevant claim is about signaling pathways: the compound showed no detectable recruitment of the beta-arrestin pathway, which is often linked to respiratory depression and other adverse effects. In their testing, slowed breathing appeared only at very high doses and was temporary, with respiration normalizing within roughly 25 to 30 minutes. The compound also had a short half-life—about 27 minutes. This was published January 22, 2026 in ACS Medicinal Chemistry Letters and highlighted as an Editor’s Choice. It’s early-stage work, and it doesn’t erase the realities of opioid risk—especially around dependence and misuse—but it’s a strong example of redesign rather than incremental tinkering. And the team connects it to a broader effort: creating patent-free vaccines that could help the immune system neutralize fentanyl before it reaches the brain.

Finally, two lighter—but still very technical—items. First, IEEE Spectrum makes the case that Jimi Hendrix’s sound wasn’t mystical luck. It was, effectively, systems engineering with an analog signal chain. The article focuses on the February 3rd, 1967 recording of “Purple Haze,” where Hendrix used an Octavia pedal built for him by engineer Roger Mayer. The signal path is treated like a reproducible system: a Fuzz Face into the Octavia into a wah-wah, feeding a Marshall 100-watt stack. Then the room and the guitar complete an acoustic feedback loop. The author goes deep: schematics converted to SPICE netlists, pickup models with real inductance and resistance values, simulations in ngspice, and audio sample generation via Python. A few key engineering insights are pulled out. The Fuzz Face’s low input impedance makes the guitar’s volume knob a primary control, explaining Hendrix’s “cleanup effect” when rolling volume back. The Octavia’s rectifier behavior inverts parts of the waveform, boosting second-harmonic content that listeners perceive as an octave-up bloom. The wah is analyzed as a sweeping band-pass filter, and the Uni-Vibe—often added later—is broken down as a multi-stage phase-shift network modulated by a low-frequency oscillator. The punchline is that Hendrix controlled a gain-driven feedback system by physically positioning himself relative to a loud, near-saturated amp in a reflective room—and iterating quickly with engineers. It’s a great reminder that “tone” is often a closed-loop control problem. And last, a quick business note that still matters to a lot of listeners: Hightouch’s careers page hit the front page, essentially as a snapshot of a Series C startup trying to hire across the board. They emphasize a small, high-output team, list customers like Spotify and Grammarly, describe themselves as hub-and-remote friendly, and outline benefits like equity, parental leave, health coverage, and global remote roles. It’s not a product deep-dive, but it’s a useful signal of where certain parts of the data and AI tooling market think they are: growth mode, hiring broadly, and competing hard on culture and compensation.