thepasswordapp

Thanks! We went with a Bauhaus-inspired design - bold geometric shapes, primary colors, hard shadows. Felt like the right aesthetic for a security tool that's meant to feel solid and trustworthy rather than the typical "sleek dark mode" approach.

The app itself uses browser-use + Gemini to automate password changes across your accounts. Zero-knowledge architecture so passwords never leave your machine. Would love any feedback if you give it a try!

Good question - and yes, this should probably be a library.

The core approach: browser-use's Agent class accepts a `credentials` parameter that gets passed to custom action functions but never included in the LLM prompt. So when the agent needs to fill a password field, it calls a custom `enter_password()` function that receives the credential via this secure channel rather than having it in the visible task context.

We forked browser-use to add this (github.com/anthropics/browser-use doesn't have it upstream yet). The modification is in `agent/service.py` - adding `credentials` to the Agent constructor and threading it through to the tool registry.

Key parts: 1. Passwords passed via `sensitive_data` dict 2. Custom action functions receive credentials as parameters 3. LLM only sees "call enter_password()" not the actual value 4. Redaction at logging layer as defense-in-depth

Would be happy to clean this up into a standalone pattern/PR. The trickiest part is that it requires changes to the core Agent class, not just custom actions on top.

Fair skepticism - I'd be suspicious too.

Two clarifications:

1. We don't ask for your current passwords. The app imports your CSV from your existing password manager (1Password, Bitwarden, etc.), which you already trust with your credentials. We automate the change process - you provide the new passwords you want.

2. Zero passwords leave your machine. The app runs locally. Browser automation happens in a local Playwright instance. The AI (GPT-5-mini via OpenRouter) only sees page structure, never credential values. Passwords are passed to forms via a separate injection mechanism that's invisible to the LLM context.

The "vibe coding" comment was about development speed with AI assistants, not about skipping security review. We spent weeks specifically on credential isolation architecture - making sure passwords can't leak to logs, LLM prompts, or network requests. That's the opposite of careless.

Code's not open source yet, but we're working toward that for exactly the reasons you describe - trust requires verification.

The credential stuffing angle here is worth highlighting - the breach happened because users reused passwords from other breached sites.

What's frustrating is that even security-conscious users face a massive burden after any breach: changing passwords across dozens or hundreds of accounts. Research shows the average remediation gap after breach disclosure is 94 days - most people simply don't do it because it's too tedious.

We've solved password generation and storage. What's still broken is the actual process of updating passwords at scale when you need to respond to a breach like this one.

The cat-and-mouse game between AI agents and bot detection is getting more sophisticated every month.

What's interesting is that legitimate use cases (accessibility tools, testing automation, research crawlers) get caught in the same net as malicious scrapers. The fingerprinting techniques that detect "non-human" behavior often flag perfectly reasonable automated workflows.

We're heading toward a future where AI agents need to authenticate their intent, not just their identity. Maybe something like signed agent manifests that declare what they're doing and why.

This is a really important area of research. Building AI agents that interact with external systems (browsers, APIs, CI/CD) requires a fundamentally different security model than traditional software.

The attack surface is interesting - the agent's "prompt" becomes a trust boundary, and anything that can influence that prompt (PR descriptions, issue comments, commit messages) becomes a potential attack vector.

I've been working on browser automation agents and the same principle applies - you have to assume any page content or user input could be adversarial. Strict separation between "what the agent can see" and "what the agent can do" is crucial.

The browser automation point is key. We've been using browser-use (the Python library) to automate password changes across websites for thepassword.app - turns out this is a surprisingly hard non-coding automation task.

Every site has a different password change flow. Some require 2FA mid-flow, others throw CAPTCHAs, and many actively detect automation. Traditional selectors break constantly as sites update their DOM.

The LLM loop approach handles this much better than scripted automation because the agent adapts in real-time. But the security architecture matters a lot - we had to modify browser-use to pass credentials via a separate parameter instead of including them in the prompt. Otherwise passwords would be visible in the LLM context.

Human-in-the-loop is essential here too. When the agent encounters something unexpected (unusual 2FA, security questions), it needs to pause and let the user decide rather than guessing.

Been "vibe coding" for 8 months building thepassword.app - AI browser automation that changes passwords across websites.

The enjoyment factor is real. The iteration speed with Claude Code is insane. But the model's suggestions still need guardrails.

For security-focused apps especially, you can't just accept what the LLM generates. We spent weeks ensuring passwords never touch the LLM context - that's not something a vibe-coded solution catches by default.

The productivity gains are real, but so is the need for human oversight on the security-critical parts.

The car data collection story is concerning, but it's part of a broader pattern: credentials and personal data are scattered across dozens of services we interact with daily.

The automotive example shows how even "non-tech" products now collect and transmit data. Each service creates another attack surface, another set of credentials to manage, another potential breach vector.

What's frustrating is that breach response still falls on individuals. When one of these services gets compromised, it's users who have to scramble to change passwords across potentially hundreds of connected accounts. The "change your password" advice is good but wildly impractical at scale.

The "global password reset for all employees" is the right call, but it highlights a painful reality: credential rotation at scale is brutal.

NIST dropped mandatory rotation years ago because it led to weak passwords. But post-breach rotation is different - it's reactive and urgent. Most people have 100+ accounts, many sharing the same passwords. Manually rotating them is a weekend project nobody wants.

We built thepassword.app (https://thepassword.app) to automate this - AI browser agents that log into sites and change passwords for you. The hardest part isn't the automation itself, it's that every site has a different password change flow, some require 2FA mid-flow, and many actively block automation.

The real test for agentic AI is handling messy, dynamic real-world tasks. We built thepassword.app (https://thepassword.app) to automate password changes across websites - turns out this is a surprisingly hard problem for agents.

Sites constantly change their DOM, throw CAPTCHAs, require 2FA, and have wildly different flows. Traditional selectors break constantly. The LLM loop approach (using browser-use) handles this much better since the agent adapts in real-time rather than following brittle scripts.

The "autonomous" part only works when you constrain the agent heavily - otherwise it wanders off clicking random links or opening new tabs.

We've been using browser-use as the foundation for our macOS app that automates password changes. The framework's LLM loop approach handles dynamic sites much better than traditional selectors - sites change their DOM constantly but the AI adapts.

One underrated aspect: credential injection. We modified browser-use to pass passwords via a secure parameter instead of including them in the prompt. Without this, credentials would be visible to the LLM context - critical for security-focused applications.

The credential harvesting aspect is what concerns me most for the average developer. If you've ever run `npm install` on an affected package, your environment variables, .npmrc tokens, and potentially other cached credentials may have been exfiltrated.

The action item for anyone potentially affected: rotate your npm tokens, GitHub PATs, and any API keys that were in environment variables. And if you're like most developers and reused any of those passwords elsewhere... rotate those too.

This is why periodic credential rotation matters - not just after a breach notification, but proactively. It reduces the window where any stolen credential is useful.

This is a good example of "your vendor is your attack surface" becoming the security lesson of 2025.

The pattern keeps repeating: Trust vendor → Vendor gets breached → Your users' data exposed. And the cascading effect here is notable - Mixpanel breach → OpenAI API users exposed → Those users likely reused credentials elsewhere.

For sensitive operations, the takeaway is clear: minimize what you share with third parties. If your credentials never leave your machine in the first place, they can't be exfiltrated from a vendor breach.

The old model of "trust but verify" feels increasingly outdated. The new model probably needs to be "verify or don't share."