Hacker Newsnew | past | comments | ask | show | jobs | submit | password-app's commentslogin

Browser automation finally works reliably enough for most tasks. Vision models have gotten good enough that AI agents can navigate dynamic websites without breaking on every UI change.

I've been using this for automated password rotation after breach notifications. The agent handles navigation while credentials are injected locally—LLM sees the page but never actual password values. When 2FA is required, OTP extraction happens via local regex, not AI.

~89% success rate on standard sites. Turns 6+ hours of tedious credential rotation into 40 minutes of supervision.

The gap between Google's research and "AI that saves me time today" is closing fast.

https://thepassword.app (Mac app I built for this)


Forgive me for not understanding, but assuming you use unique passwords on every account/website, and get a breach notification, wouldn't that breach password only be on that one website/account and would thus take nowhere near 6 hours?

What am I missing?


That GP's comment is an advertisement for a subscription based closed source application that gets access to your credentials.


Congrats on shipping v1. The "sense-think-act" architecture is exactly what's needed for agentic workflows.

Re: the login handling discussion upthread—I've been using browser-use for automated password rotation (breach response use case). Two patterns that might be relevant to Vibium's roadmap:

Credential injection: Instead of putting passwords in the prompt, pass them via a sensitive_data parameter. The agent calls enter_password() without the value ever appearing in LLM context. Solves the "blast radius" concern several people raised.

Deterministic 2FA handling: When email verification is required, open Gmail in a new tab, but extract OTPs with local regex—not AI. The LLM orchestrates navigation; code extraction stays local. Handles ~90% of email 2FA automatically.

These patterns should work with any browser automation framework. Built a Mac app around this: https://thepassword.app

Would love to see Vibium add first-class support for credential injection in the API—it's the missing piece for any security-sensitive automation.


This is exactly the right approach for sensitive data + LLMs. We use a similar pattern for password automation:

- Credentials never flow through LLM context - Agent triggers actions via callbacks - Passwords injected at the last mile, invisible to the model

The key insight: you can get all the benefits of AI agents without exposing sensitive data to the model. Client-side execution + careful context isolation makes this possible.

For anyone building AI agents that handle PII/credentials, this WASM approach is worth studying.


Thanks! The last mile injection idea is exactly how I think about it too.

I realized that for 90% of 'summarize this' or 'debug this' tasks the LLM doesn't really need any specific PII or sensitive information, it just needs to know that an entity exists there to understand the structure.

That's why I focused on the reversible mapping, so that we can re-inject the real data locally after the LLM does the heavy lifting. Cool to hear you're using a similar pattern for credentials.


Formal verification for AI is fascinating, but the real challenge is runtime verification of AI agents.

Example: AI browser agents can be exploited via prompt injection (even Google's new "User Alignment Critic" only catches 90% of attacks).

For password management, we solved this with zero-knowledge architecture - the AI navigates websites but never sees credentials. Credentials stay in local Keychain, AI just clicks buttons.

Formal verification would be amazing for proving these isolation guarantees. Has anyone worked on verifying AI agent sandboxes?


Impressive image quality improvements. Meanwhile, AI agents just crossed a milestone: Simular's Agent S hit 72.6% on OSWorld (human-level is 72.36%).

We're seeing AI get better at both creative tasks (images) and operational tasks (clicking through websites).

For anyone building AI agents: the security model is still the hard part. Prompt injection remains unsolved even with dedicated security LLMs.


This is why I'm skeptical of any app claiming "super secure" without open-source verification.

The real lesson: assume every service will eventually leak something. Use unique passwords everywhere, enable 2FA, and rotate credentials after breaches.

The tedious part is the rotation. I've seen people skip it because manually changing 50+ passwords is brutal. Automation helps but needs to be done securely (local-only, zero-knowledge).


The word "super" is enough to make my red flags fly. As a millennial the word super is something that I remember only being used around the house, or between young friends. Fast forward to the last few years and the casual use of the word super, along with uptalk, is being used what seems like every other sentence in the professional setting. It's strange to me and immediately makes me think of the person using it as childish or otherwise not know what they are talking about. I'm not surprised about the "Super secure" app not being secure.


Google discontinuing this is unfortunate timing given the recent breach surge (700Credit, SoundCloud, LinkedIn leak).

Alternatives: haveibeenpwned.com (free), 1Password Watchtower, Bitwarden breach reports.

The harder part isn't knowing about breaches—it's actually rotating passwords afterward. Most people know they should but don't because it's tedious.

Automated rotation tools are emerging but need careful security architecture (local-only, zero-knowledge) to avoid creating new attack vectors.


This is a great example of why AI automation needs careful oversight. When AI gets things wrong in high-visibility contexts like this, it erodes trust.

The same principle applies to password management - automating password changes across dozens of sites is powerful, but you need transparency and control over what the AI is doing. Users should be able to monitor the automation in real-time and intervene if needed.

Building trust in AI-powered tools requires showing your work, not just delivering results.


The concurrency aspect is interesting - we're building password automation and one of the pain points is that most sites have rate limiting / bot detection that gets triggered if you try to parallelize password changes too aggressively.

Sequential execution with realistic timing delays is actually necessary for our use case. But I can see how other agent applications would benefit from true concurrency.

Are you handling session isolation between concurrent agents? That seems like it would be critical for avoiding state pollution.


Yes. Browser4 supports concurrent multi-agent execution. At the moment, we support the following scenarios:

A single agent operating on multiple pages (tabs) within the same browser context

Multiple agents operating in parallel across multiple browser contexts, where each context has an isolated profile

Are you specifically looking for multiple agents concurrently operating on the same browser context? If so, could you describe the concrete use case?


Nice work on the human-in-the-loop approach. We're using a similar pattern for password automation - the AI handles the tedious clicking through password change flows, but the user explicitly selects which accounts to update.

The challenge we've found is balancing automation with user control. Too much automation and users get nervous (especially with credentials), too little and you're just a fancy macro. The "approve then execute" pattern seems to hit the sweet spot.

Curious how you're handling error recovery when the agent gets stuck?


Interesting challenge you have there and error recovery for agents is indeed a hard challenge. For this linear based workflow, it is relatively easy to give feedback to the agents when the tasks were done to the spec you are expecting and the cost is low enough you can just toss out the work being done so far and restart completely


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: