DEV Community: Sourabh Katti

How I Built an AI Password Automation Tool with browser-use

Sourabh Katti — Sat, 27 Dec 2025 02:48:53 +0000

# How I Built an AI Password Automation Tool with browser-use

## The Problem

Breach notifications require changing 50+ passwords
Manual process takes 4-8 hours
Most people just... don't do it

## The Solution: AI Browser Automation

browser-use library (89.1% WebVoyager benchmark)
Vision + action: AI sees screen, clicks buttons, types text
Works on sites it's never seen before

## Architecture
[Code snippets showing browser-use integration]

Electron frontend
Python backend
Local execution for security

## Challenges Solved

Anti-bot detection → Chrome profile integration
2FA handling → Pause for human, resume
Password security → Zero-knowledge, memory-only

## Results

89% automated success rate
30 minutes vs 6 hours
Zero passwords transmitted to cloud

## Try It
Built this into The Password App for macOS.
Free tier: 5 passwords/month
https://thepassword.app

Building AI browser agents that actually work: lessons from automating password changes

Sourabh Katti — Tue, 02 Dec 2025 17:22:01 +0000

Everyone talks about AI agents coding, writing, and chatting. But what about agents that actually do things in the real world - like navigating websites, clicking buttons, and filling forms?

I spent the last few months building an AI agent that automates password changes across websites. Here's what I learned about making browser automation agents that actually work in production.

The problem with traditional browser automation

Selenium and Playwright are great for predictable workflows. But real websites are messy:

Login flows change without warning
CAPTCHAs appear randomly
Elements have dynamic IDs
Modals pop up unexpectedly
Sites detect and block automation

Traditional scripted automation breaks constantly. You end up playing whack-a-mole with selectors.

Enter AI browser agents

The idea is simple: instead of scripting every click, let an LLM observe the page and decide what to do next. Tools like browser-use make this surprisingly accessible.

Here's the basic architecture:

from browser_use import Agent, Browser
from langchain_openai import ChatOpenAI

# Initialize browser and LLM
browser = Browser()
llm = ChatOpenAI(model="gpt-4o-mini")

# Create agent with a task
agent = Agent(
    task="Navigate to example.com and click the login button",
    llm=llm,
    browser=browser
)

# Run it
await agent.run()

The agent takes screenshots, converts them to an accessibility tree, and asks the LLM: "Given this page state and your goal, what should you do next?"

Five hard lessons from production

1. Constrain the agent ruthlessly

My first agents were too open-ended. I'd say "change the password on this site" and watch in horror as the agent:

Opened new tabs to search for help articles
Clicked "Forgot Password" links
Navigated to completely unrelated pages

Fix: Add strict rules to your prompts:

task = """
Change the password on example.com.

STRICT RULES:
- DO NOT open new tabs
- DO NOT use search engines
- DO NOT click "Forgot Password"
- If stuck after 5 actions, STOP and report failure
"""

2. Never expose sensitive data to the LLM

This was my biggest security mistake. Early versions included passwords in the task prompt:

# DON'T DO THIS
task = f"Log in with password: {actual_password}"

That password now lives in your LLM provider's logs forever.

Fix: Use custom actions that inject credentials without exposing them to the model:

@browser.action("Enter password in focused field")
def enter_password(credentials: dict):
    # Password passed through secure channel
    # LLM only sees action name, never the value
    page.keyboard.type(credentials["password"])

3. The DOM is not your friend

Screen readers and accessibility trees are your friends. They provide semantic meaning that raw HTML doesn't.

# Instead of parsing HTML for buttons
soup.find_all('button', class_='submit-btn-v2')

# Use accessibility snapshots
snapshot = page.accessibility.snapshot()
# Returns structured data: button "Submit", textbox "Email", etc.

This makes your agent more robust to CSS class changes and layout shifts.

4. Implement aggressive timeouts

AI agents can get stuck in loops. Without timeouts, they'll burn through your API budget clicking the same broken element forever.

agent = Agent(
    task=task,
    llm=llm,
    max_steps=15,           # Hard limit on actions
    timeout=120,            # Total time limit
    step_timeout=30,        # Per-action limit
)

5. Log everything (but redact credentials)

When things go wrong (and they will), you need visibility. But you also can't log passwords.

def log_action(action: str, target: str):
    # Redact anything that looks sensitive
    if "password" in target.lower():
        target = "[REDACTED]"
    logger.info(f"Action: {action} -> {target}")

When AI agents beat traditional automation

AI browser agents shine when:

Sites change frequently - The agent adapts to new layouts
Workflows vary by account - Different users see different flows
Edge cases are endless - 2FA prompts, CAPTCHA, cookie banners
You'd rather not maintain selectors - Let the AI figure it out

They struggle when:

Speed matters - LLM calls add latency
Cost matters - Each action = API call
Reliability must be 100% - AI agents are probabilistic

The architecture that worked

After many iterations, here's what works:

Playwright for browser control - Fast, reliable, good DevTools integration
GPT-4o-mini for decisions - Good enough for navigation, much cheaper than GPT-4
Accessibility tree for page state - More stable than DOM parsing
Custom actions for sensitive operations - Keep credentials out of LLM context
Aggressive constraints - Limit what the agent can do

Real-world results

Building The Password App, I've now run thousands of password change operations. Success rates:

Simple sites (basic forms): ~95%
Complex sites (multi-step, 2FA): ~70%
Anti-bot protected sites: ~40%

The 40% is brutal but honest. Sites with Cloudflare, DataDome, or aggressive bot detection still win most battles.

What's next for AI browser agents

We're still early. Current limitations:

CAPTCHA - The eternal enemy
Bot detection - Getting harder to evade
Cost - $0.01-0.05 per operation adds up
Latency - 30-60 seconds for simple tasks

But the trajectory is clear. As vision models improve and costs drop, AI browser agents will handle increasingly complex web tasks.

If you're building AI browser automation, I'd love to hear what's working for you. Drop a comment or find me on Twitter.

Building something similar? The Password App automates password changes using the techniques described here. Free tier available.

Why We Don't Use Browser Extensions: The Clickjacking Problem

Sourabh Katti — Tue, 02 Dec 2025 01:33:14 +0000

At DEF CON 2025, security researchers disclosed a clickjacking vulnerability affecting the browser extensions of 1Password, Bitwarden, and LastPass. The attack allows malicious websites to steal autofilled credentials by overlaying invisible elements on password fields.

Here's what happened, why browser extensions are inherently vulnerable to this attack class, and why we chose a completely different architecture for The Password App.

The clickjacking attack explained

Clickjacking works by placing an invisible iframe or element over a legitimate page. When you think you're clicking a "Submit" button, you're actually clicking a hidden element that performs a different action.

For password managers, the attack flow looks like this:

You visit a malicious website that mimics a legitimate login page
Your password manager's browser extension autofills your credentials
An invisible iframe overlays the password field
When you click "Login," the hidden iframe captures your autofilled credentials
Your password is sent to the attacker's server

The user sees nothing wrong. The page looks normal. The password manager worked as expected. But the credentials are now in the attacker's hands.

Why browser extensions are vulnerable

Browser extensions operate in a hostile environment by design. They must:

Trust the page DOM: Extensions interact with webpage elements they don't control
Autofill into foreign contexts: Credentials are injected into third-party content
Run in the browser's sandbox: Limited ability to verify page authenticity
React to user actions: Must respond when users interact with password fields

This creates an inherent tension. The extension must be helpful (autofill passwords) while operating in an environment controlled by potentially malicious actors (the webpage).

The technical problem

Password manager extensions typically:

Detect login forms by examining DOM elements
Match the current URL against saved credentials
Inject the password into the detected field
Trust that the field is what it appears to be

Step 4 is where clickjacking attacks succeed. The extension fills the "real" password field, but that field is actually visible through an invisible iframe that captures the input.

Even sophisticated extensions with phishing detection can be fooled because:

The URL is legitimate (the attack works on real sites with injected malicious ads)
The DOM appears correct (until you account for invisible overlays)
User behavior is normal (clicking buttons they can see)

The 1Password, Bitwarden, LastPass disclosure

The DEF CON research demonstrated attacks against all three major password manager extensions:

Extension	Vulnerable	Attack vector
1Password	Yes	Invisible iframe overlay
Bitwarden	Yes	CSS opacity manipulation
LastPass	Yes	Z-index layering attack

At the time of this writing, none of the affected vendors have issued public statements about remediation timelines.

Why we chose desktop-only

When we built The Password App, we made a deliberate architectural decision: no browser extensions. Here's why:

1. Controlled environment

A desktop application runs in an environment we control. We're not fighting against malicious webpage code because we're not executing in the webpage context.

Browser extension: [Your Code] → [Webpage DOM] → [Unknown scripts]
Desktop app:       [Your Code] → [Our UI] → [Isolated browser instance]

2. No autofill, no autofill attacks

The Password App doesn't autofill passwords into webpages. Instead, our AI agent navigates to sites and fills credentials through a controlled browser instance that we manage.

The key difference:

Extension approach: Inject credentials into untrusted page context
Our approach: Control the entire browser session in isolation

3. Visual confirmation

Because password changes happen in a visible browser window, you can see exactly what's happening. There's no invisible iframe attack possible when you're watching the AI navigate to the password change form.

How clickjacking fails against our architecture

Let's walk through why a clickjacking attack can't steal credentials from The Password App:

Step 1: Attacker sets up malicious overlay
The attacker creates a page with hidden elements designed to capture password input.

Step 2: User initiates password change
You select an account in The Password App and click "Change Password."

Step 3: Isolated browser opens
Our AI agent opens a fresh browser instance with no extensions. It navigates directly to the account settings URL—not a malicious page.

Step 4: Credentials never touch the webpage
The AI identifies the password field and calls our secure credential injection function. The password travels through a separate channel, never entering the DOM in a way that JavaScript can intercept.

Step 5: Even if compromised...
Even if a malicious script somehow ran in our controlled browser, it couldn't exfiltrate the password because:

Domain locking prevents navigation to attacker URLs
The AI never has the password value in its context
Network requests are restricted to the target domain

Multiple defensive layers mean no single failure compromises credentials.

The broader problem with browser-based security

This isn't just about clickjacking. Browser extensions face a constant stream of attack vectors:

Attack type	Description	Extension vulnerable?	Desktop app vulnerable?
Clickjacking	Invisible overlays steal input	Yes	No
DOM manipulation	Malicious scripts modify forms	Yes	No (isolated browser)
Extension compromise	Malicious update pushed to extension	Yes	No (local only)
Cross-site scripting	Attacker injects scripts into trusted sites	Yes	No (domain locked)
Man-in-the-browser	Malware modifies browser behavior	Yes	Partially (isolated process)

The fundamental issue is that browser extensions must coexist with arbitrary webpage code. Every new web API, every browser update, every clever attacker creates new potential vulnerabilities.

What this means for users

If you use a password manager with a browser extension, you should:

Keep extensions updated - Vendors will likely patch this vulnerability
Be cautious on unfamiliar sites - Don't autofill on sites you don't fully trust
Consider the attack surface - Browser extensions add risk, even from trusted vendors
Use 2FA everywhere - A stolen password with 2FA is less damaging

If you're evaluating password security tools, ask:

Does this tool inject credentials into webpage contexts?
What happens if a malicious script runs alongside the extension?
How does the tool verify page authenticity before autofilling?

Our security architecture

The Password App takes a different approach entirely:

Zero-knowledge: Passwords never leave your Mac. They exist in memory only during the change process.

Credential isolation: The AI agent never sees actual password values. It calls functions like enter_password() that retrieve and inject credentials through a separate secure channel.

Domain locking: During password changes, the browser can only navigate to the target domain. Attempts to redirect elsewhere are blocked at the browser level.

No browser extension: We eliminated the attack surface entirely by not putting code into the browser context.

The bottom line

Clickjacking against password manager extensions isn't a theoretical risk—it's a demonstrated attack that works against the most popular tools. The affected vendors will likely patch this specific vulnerability, but the underlying problem remains: browser extensions operate in a hostile environment.

When we designed The Password App, we asked: "How do we handle credentials securely in a world where we can't trust the browser?" The answer wasn't to build a better browser extension. It was to avoid the browser extension model entirely.

Desktop-only. Local-only. Zero-knowledge. No extension attack surface.

Originally published at thepassword.app/blog

The Shai-Hulud Worm: How 500+ NPM Packages Became Credential-Stealing Malware

Sourabh Katti — Tue, 02 Dec 2025 01:31:47 +0000

In September 2025, security researchers discovered something unprecedented: a self-replicating worm spreading through the NPM package ecosystem, stealing developer credentials and automatically infecting more packages. Named "Shai-Hulud" after the giant sandworms from Dune, this attack represents a new era in supply chain security—and a warning about how quickly stolen credentials can cascade into catastrophe.

What is Shai-Hulud?

Shai-Hulud is the first successful worm attack in the NPM ecosystem. Unlike traditional malware that requires manual deployment, this worm spreads autonomously by stealing developer credentials and using them to infect additional packages.

Here's what makes it terrifying:

Self-replicating: When the malware finds NPM tokens on a compromised machine, it automatically publishes malicious versions of any packages that developer maintains
Exponential spread: Each new infection creates more infections, without any attacker involvement
Credential harvesting: The malware steals AWS, GCP, Azure credentials, GitHub tokens, SSH keys, and more
Destructive fallback: If exfiltration fails, the malware attempts to destroy the victim's entire home directory

The Timeline: How It Unfolded

September 2025: First Wave

The initial campaign was discovered when security researchers noticed suspicious activity in popular NPM packages. The attack spread through phishing emails impersonating NPM, tricking developers into revealing their credentials.

Key impacts:

500+ packages compromised including packages associated with CrowdStrike
@ctrl/tinycolor with over 2 million weekly downloads was infected
40+ packages across multiple maintainers compromised in the initial wave

November 2025: Shai-Hulud 2.0

A more aggressive second wave emerged, with researchers from Unit 42 and JFrog documenting the expanded attack:

25,000+ malicious repositories across approximately 350 unique GitHub users
Pre-installation execution: Unlike the first wave (post-install), the new variant executes during pre-install, dramatically widening the attack surface
Notable victims: Packages from Zapier, ENS Domains, PostHog, and Postman were affected
GitHub Actions backdoors: The malware drops workflow files that serialize and exfiltrate secrets

According to CISA's alert, this attack affects "tens of thousands" of GitHub repositories.

How the Attack Works

Step 1: Initial Compromise

Developers receive phishing emails that appear to come from NPM, requesting MFA credential updates. Those who fall for the phishing attack inadvertently grant attackers access to their NPM accounts.

Step 2: Package Infection

The attacker publishes a malicious version of a package the compromised developer maintains. This version includes hidden code in the installation scripts.

Step 3: Credential Harvesting

When someone installs the infected package, the malware scans for:

Credential type	Location scanned
NPM tokens	.npmrc files
GitHub tokens	Environment variables, config files
Cloud credentials	AWS, GCP, Azure credential files
SSH keys	~/.ssh directory

The malware uses TruffleHog to systematically find secrets across the filesystem.

Step 4: Autonomous Spreading

Here's where Shai-Hulud becomes unique: the worm uses stolen NPM tokens to identify other packages the victim maintains, then publishes malicious versions of those packages too—all without any human attacker involvement.

Developer A gets phished → Package X infected → 
Developer B installs Package X → Package Y, Z infected (B's packages) → 
Developer C, D, E install Y or Z → More packages infected...

Step 5: The Dead Man's Switch

If the malware's exfiltration channels are blocked, it triggers a destructive fallback that attempts to securely overwrite and delete all writable files in the user's home directory. This "scorched earth" approach ensures maximum damage even if the attack is partially blocked.

Why This Matters for Everyone (Not Just Developers)

You might think: "I'm not a developer. Why should I care about NPM packages?"

Here's why: the credentials stolen in Shai-Hulud attacks are the same credentials used to access your data.

When attackers steal:

AWS credentials → They can access databases containing user information
GitHub tokens → They can insert backdoors into software you use
Cloud API keys → They can access infrastructure running applications you depend on

The companies affected by Shai-Hulud—like Zapier, PostHog, and Postman—handle data for millions of users. A compromised developer credential can cascade into:

User database breaches
API key theft
Payment information exposure
Personal data leaks

How to Protect Yourself

If You're a Developer

CISA's mitigation recommendations include:

Immediately rotate all credentials: NPM tokens, GitHub PATs, SSH keys, cloud API keys
Audit dependencies: Run npm audit and examine your package-lock.json files
Check for Shai-Hulud repositories: Look for unfamiliar repositories in your GitHub account with "Shai-Hulud" in the description
Enable MFA everywhere: GitHub, NPM, and all cloud providers
Pin dependency versions: Lock versions to known-safe releases prior to September 16, 2025

If You're a Regular User

Even if you're not a developer, you should:

Use unique passwords for every account: If one password is compromised, only one account is affected
Enable 2FA on important accounts: Email, banking, anything with sensitive data
Check for breaches: Visit Have I Been Pwned to see if your credentials have been exposed
Change passwords on breached accounts: Don't wait—attackers act quickly

The Password Rotation Problem

Here's the uncomfortable truth: most people know they should change compromised passwords. Most people don't do it.

Why? Because changing passwords manually is tedious. If you have 100+ accounts and 30 of them use a compromised password, that's hours of work navigating to each site, finding the password change form, generating a new password, and updating your password manager.

This is exactly why we built The Password App: to automate the tedious part of credential hygiene so you actually get it done.

Lessons from Shai-Hulud

1. Supply Chain Attacks Are Escalating

Shai-Hulud represents a new sophistication in supply chain attacks. The self-replicating nature means a single successful phishing email can cascade into thousands of compromised packages—and millions of affected users downstream.

2. Credential Hygiene Matters More Than Ever

Every compromised credential is a potential entry point. Whether it's a developer's NPM token or your Netflix password, reused or weak credentials multiply risk.

3. Automated Attacks Require Automated Defenses

Attackers use automation to scale their efforts. Individual users and organizations need automation to keep up. Manually rotating 100 passwords after every breach isn't sustainable.

Take Action Today

The Shai-Hulud worm is a wake-up call. Supply chain attacks are getting more sophisticated, and credential theft cascades further than ever before.

You may not be able to control whether the software you use gets compromised. But you can control:

Your own credential hygiene: Unique passwords, 2FA enabled
Your response time: Change compromised passwords quickly
Your attack surface: Fewer reused passwords means less blast radius

Your credentials are only as secure as your weakest password. Make them all strong.

Sources

Originally published at thepassword.app/blog