Sealzi / JournalStoriesAboutWhat's Vauz? Support

Apple's Passwords app can now log into your accounts and change your passwords for you. Here's the question that raises.

All stories ↗

For as long as password managers have existed, they’ve done one of two things with a saved credential: hand it back to you so you can type it somewhere, or fill it into a form because you clicked something that told them to. Either way, a person was the one deciding that a specific website, right now, should receive a specific stored secret.

iOS 27, which Apple began shipping this month, changes that shape for the first time in a mainstream consumer product. Announced at WWDC in June and detailed further in August, the update gives the Passwords app a new capability: it can find an account with a weak or compromised password, sign into that account itself, navigate to the password-change page, generate a new strong password, and save it — without you typing anything, described by Apple as fixing a password “with a tap.” Apple says the feature runs on Apple Intelligence, split between on-device processing and Private Cloud Compute for anything heavier, with data “never stored” and used only to complete the task in front of it. It’s a real capability shipping to real phones, not a lab demo, and it’s worth taking seriously on its own terms before asking what it means for the rest of us.

What actually changed

Every password manager autofill has always done a version of this: read a stored value and put it into a field on a page. What iOS 27 adds is the step before that — deciding which page, which account, and when — and the step after it, deciding the transaction is complete and writing a new value back into storage. Those used to be the reader’s job. Now a piece of software running “agentically,” in Apple’s own phrasing, does both ends of it.

That’s a bigger grant of authority than it might look like at first. Filling a field is a single, reversible action a person triggers on purpose. Logging in, navigating a multi-step form, and confirming a change is a sequence of judgment calls: is this actually the account-settings page, or a page that looks like one? Did the site accept the new password, or silently fail? Is this the right account at all, if two saved entries share a username? A human doing this by hand notices when something looks off, because a familiar page suddenly looks slightly wrong. An agent has to be told, explicitly, what “looks wrong” means — or it has to be built to ask before it commits to anything.

A problem the industry already solved for humans

This isn’t a new question in the abstract. Password manager autofill spent 2025 dealing with a related one: researcher Marek Tóth showed at DEF CON that a page could trick a browser extension’s autofill into releasing stored data through invisible, layered elements — a person believed they were clicking a cookie banner and actually triggered a credential release. Roughly forty million installs across eleven password managers were affected. The rule the industry converged on — and the rule Vauz’s autofill is built on — was to stop treating “the browser said this counts as a click” as sufficient permission, and instead require an explicit approval — outside the page, naming the actual destination domain — every time a stored credential is about to leave the vault.

That rule was written for a human sitting at the keyboard, being fooled by a page. But what it establishes is more general than that: before a credential leaves storage and lands on a website, something has to confirm the destination is real and something has to get an affirmative yes. It doesn’t matter whether the entity being fooled, or the entity doing the confirming, is a person or code. The requirement is the same requirement.

What Apple has said, and what it hasn’t

To Apple’s credit, the company has been specific about where the computation happens and what it claims to do with your data — on-device where possible, Private Cloud Compute for the rest, nothing retained past the request. That’s a real, checkable architectural commitment, and it answers an important question: who else gets to see this.

It doesn’t answer a different question, which is what happens at the moment of action. Does the agent verify it has landed on the legitimate password-change page for that specific account before submitting anything, the way Vauz’s approval prompt names the domain before releasing a credential? Does changing five weak passwords in one pass ask for five separate confirmations, or does unlocking the feature once cover an entire batch run unattended? What happens if a site’s password-change flow doesn’t match what the model expects — does it stop and flag the account, or does it do nothing and quietly leave that one password as it was? As of this writing, Apple’s own materials describe the outcome the feature is meant to produce, not the guardrails that keep it from acting on the wrong page or the wrong account. That’s not an accusation that the guardrails are missing. It’s an honest statement that the specifics aren’t public yet, and a reader deciding whether to turn this on can’t currently check them the way you can check whether a lock actually engages.

The general test, for any tool that asks for this

You don’t need an opinion on Apple specifically to take something useful from this. Any product — a password manager, a browser, an email client — that offers to act on your stored credentials on your behalf is asking for a new kind of trust, and it’s fair to hold all of them to the same short list of questions before accepting it: Does it confirm the actual destination before a credential leaves storage, the way an approval prompt naming a domain does? Is each action something you approved individually, or did one moment of consent cover everything that follows? If something on the far end doesn’t match what was expected, does the tool stop and tell you, or proceed anyway? And can you find the answers to those questions in the vendor’s own documentation, rather than piecing them together from beta-testing reports and conference talks? A vendor that can answer plainly has thought about this on purpose. One that only describes the happy path hasn’t necessarily gotten it wrong — but you can’t yet tell, and that’s worth knowing before you hand the keys over.

Where Vauz sits

Vauz  doesn’t have an agent that logs into sites and changes passwords for you, not just yet. What Vauz does have is the piece of this that we could actually ship and describe in full: a credential only leaves the vault after a person approves it, outside the browser where no page can reach the prompt — Touch ID, or your V-Key if you’ve set one, or a plain confirmation dialog if you’ve set neither — and whichever of those you get, it names the real destination domain before anything moves.

Held to the test above, that answer isn’t perfectly clean, and it’s worth saying where. Approving a site covers it for two minutes rather than for exactly one release: a sign-in form split across two pages would otherwise ask twice, and a prompt on every single field is how you build something people switch off. So one moment of consent does cover a little of what follows, deliberately, and we wrote about what fits through that gap when we set the window out in full. Prompt for authentication on every autofill, in the extension’s settings, closes the window completely for anyone who would rather have the friction.

A human still has to be the one clicking. That’s a smaller promise than “this software will clean up your weak passwords while you sleep,” and we’d rather say so plainly than imply otherwise. But it’s a promise we can describe down to the mechanism, which is exactly the standard this whole question is about: not whether a tool is agentic, but whether it can tell you precisely what has to be true before it acts on your behalf, and let you check.

The question worth carrying forward, as more of what touches your passwords starts acting on its own, isn’t “is this convenient.” It’s the same one autofill had to answer after 2025’s clickjacking research, asked of a new kind of actor: before anything leaves the vault, what confirms it’s going to the right place, and who signed off?

Every release, your call

Vauz never fills a form without asking you first.

Vauz approves autofill outside the browser, where no web page can reach the prompt — Touch ID, or your V-Key — and the prompt names the actual site before anything leaves the vault. No agent stands between the ask and the click. The free plan stays completely free for life, with Plus and Premium available when you need more!

Use Vauz completely free — for, like, ever
© 2026 Sealzi. Where privacy matters.Sealzi.com ↗Vauz ↗RSS