Apple announced something at WWDC26 that sounds genuinely useful and slightly terrifying at the same time.
In iOS 27, iPadOS 27, and macOS 27, the Passwords app will be able to use Apple Intelligence and Safari to automatically change weak or compromised website passwords. Instead of warning you that an old password appeared in a breach and sending you off to fix it yourself, Apple’s new agentic password-changing feature can navigate the website, sign in, replace the password with a strong one, save it, and show the work as a Live Activity.
That solves a real security problem.
People ignore compromised-password warnings. They put them off because changing a password is annoying, the website hides the setting, the account asks for another verification step, or the user has 40 other warnings waiting behind it. A warning that never becomes action is not much of a control.
But there is an important line between detecting a risky password and changing the credential that controls somebody’s account.
Detection is observation.
Changing the password is authority.
The question is not whether AI can find the change-password button. The question is how much authority we should give it after it does.
As of June 8, 2026, these operating systems and this feature are in developer beta. Apple has announced the capability, but the detailed security architecture, supported-site requirements, failure handling, and approval model are not yet fully documented publicly. That means some of the biggest questions do not have confirmed answers yet.
Those questions are exactly what security professionals should be asking before this becomes a normal consumer feature in the fall.
I do not want to start from the position that automating password changes is automatically bad.
Apple’s Passwords app already identifies reused, weak, and compromised credentials. Apple’s platform security documentation explains that its Password Monitoring feature uses privacy-preserving techniques to compare saved credentials against a curated list of leaked passwords without revealing the user’s passwords to Apple. The existing process then tells the user there is a problem and directs them to the website to change it.
That last step is where security advice often dies.
Research has repeatedly shown that users do not reliably change breached passwords, and when they do, they may replace them with something similar or reuse the new password elsewhere. NIST’s current Digital Identity Guidelines say services should force a password change when there is evidence of compromise, permit password managers, and block known compromised passwords.
Apple’s feature could connect those pieces.
If Passwords detects a compromised credential, generates a unique strong replacement, updates the website, and saves the new credential correctly, that can reduce the time an exposed password remains useful to an attacker. It could also help normal users get the security benefit of unique passwords without asking them to fight through every website’s account settings.
That is a meaningful improvement.
The danger is that the same automation has to operate inside one of the least trustworthy environments we have: the open web.
Changing a website password looks simple when a person does it.
Open the site. Sign in. Find account settings. Enter the current password. Generate a new one. Submit it. Save it.
An agent has to understand and perform that entire workflow. Depending on the website, it may also have to handle redirects, pop-ups, unusual password rules, multiple accounts on the same domain, reauthentication prompts, MFA challenges, confirmation emails, expired sessions, or a page that changed since the agent was trained or tested.
This is not just text generation. It is an agent taking action with a sensitive credential.
The joint Five Eyes guidance on the careful adoption of agentic AI services makes the core risk clear: an agent’s privileges directly determine the risk it can introduce. The guidance recommends least privilege, strong oversight, human approval for high-impact actions, detailed logging, and fail-safe behavior when the system is uncertain.
A password-changing agent has at least three powerful capabilities:
That is a lot of trust to place in any automated system, whether Apple calls it AI, agentic automation, or something else.
The first risk I keep coming back to is prompt injection.
Browser agents have to read websites to understand what is on the page and decide what to do next. But websites are not neutral interfaces. They contain text, scripts, advertisements, embedded frames, user-generated content, and other material controlled by third parties.
Anthropic’s own research on prompt injection in browser use says every webpage an agent visits is a potential attack vector and that no browser agent is immune to prompt injection. The UK’s National Cyber Security Centre makes the deeper problem clear in its warning that prompt injection is not SQL injection: current large language models do not enforce a reliable security boundary between instructions and data inside a prompt.
That matters here because the agent is reading a website while holding authority to change an account credential.
Imagine a compromised website, malicious advertisement, injected support widget, or attacker-controlled account page containing hidden instructions intended for an AI agent:
I am not saying Apple’s implementation will blindly follow instructions like these. Apple may isolate credentials from the model, restrict what actions the agent can take, validate origins, and use deterministic controls around the final change. I hope it does.
But until Apple documents those boundaries, “the AI runs on device” is not a complete security answer.
On-device processing can improve privacy. It does not make hostile web content trustworthy.
One architectural question matters more than almost any other:
Does the AI model ever receive the current password or the newly generated password in its context?
The safest answer is no.
The model may need to recognize that a page contains a current-password field, a new-password field, and a confirmation field. It does not need to know the actual secret placed inside them. A separate, tightly controlled credential service should perform the fill operation only after verifying the website origin, the intended account, and the approved action.
The agent should be able to say, “Fill the verified current-password field for this account.”
It should not be able to read, copy, summarize, transform, or send the password itself.
That separation matters because models operate on context. Anything placed into model context becomes part of a much larger attack surface involving prompts, logs, memory, debugging, telemetry, and unexpected behavior. Apple’s existing Password Monitoring design goes to significant lengths to avoid revealing passwords even to Apple. The agentic password-changing feature should preserve that same instinct at every step.
There is also a less dramatic but very practical risk: the agent changes the password successfully on the website but fails to save the new credential correctly.
Now the old password no longer works, the new password is unknown to the user, and the Passwords app may not have a usable copy.
That can happen for plenty of boring reasons:
Traditional software has transaction controls for this kind of problem. It verifies state, handles failures, and avoids leaving systems halfway through a sensitive change. Websites do not expose one consistent password-change transaction, though. The agent is operating across thousands of independently designed interfaces with different rules and failure modes.
Safari already supports the W3C’s /.well-known/change-password URL, which lets a website advertise where its password-change page lives. That is useful because it reduces some guesswork. It does not provide a standardized, atomic password-rotation API or prove that the agent completed the workflow correctly.
Before I trust automated password changes, I want to know how Apple verifies success, protects the new credential before submission, detects a partial failure, and helps the user recover when the site and the vault disagree.
The feature is supposed to help the legitimate user. Security still has to ask what happens when the device or user session is not fully under the legitimate user’s control.
Apple has invested heavily in protections such as Face ID, Touch ID, the Secure Enclave, and Stolen Device Protection. Those controls matter. But an agent that can rotate many account passwords creates a powerful action path on the device.
If malware, an attacker with an unlocked session, or somebody who knows the device passcode can trigger or influence that workflow, the impact may extend beyond viewing saved credentials. The attacker may be able to change account passwords, disrupt the user’s access, invalidate sessions, or create confusion across multiple services.
This is where automation changes the blast radius.
A person manually changing one password is one action. An agent able to work through a queue of compromised passwords can perform many sensitive actions quickly. That speed is the feature when the user is in control. It becomes the risk when the wrong person or process is in control.
Apple should require fresh biometric approval for sensitive commits, place sensible limits on bulk changes, and make the user clearly approve which accounts are about to be modified. A device being unlocked should not automatically mean every saved website credential is available for agentic rotation.
Websites do not all treat a password change the same way.
Some revoke every active session. Some keep existing sessions alive. Some trigger fraud alerts. Some require MFA. Some send confirmation links. Some temporarily lock the account. Some connect the password to legacy applications, email clients, shared devices, or business workflows that do not update automatically.
For a personal streaming account, a failed rotation may be annoying.
For a business admin account, financial service, primary email account, or shared family credential, it can be disruptive or dangerous.
This is also where passwords collide with better authentication options. If a website supports passkeys, moving the user toward a phishing-resistant passkey may be more valuable than repeatedly rotating the password. The FIDO Alliance explains that passkeys replace shared passwords with cryptographic key pairs and are designed to resist phishing.
That does not mean Apple should never rotate passwords. Compromised passwords still need to be invalidated, especially when they remain a fallback path. It means the agent should understand that “change the password” is sometimes only one step in securing the account.
I made the same point in my passkeys article: the weakest remaining authentication or recovery path can still decide the outcome.
An agent that changes the password but leaves a weak recovery email, SMS fallback, or attacker-controlled session untouched may produce a reassuring green checkmark without actually restoring control of the account.
Apple says the password-changing process appears as a Live Activity. That is a good start because users should be able to see that a sensitive operation is happening.
But visibility during the action is not the same as accountability after it.
Users need a durable, understandable record:
The agent should also stop and escalate when it encounters anything outside the narrow password-change task. It should not decide on its own that changing a recovery email, disabling MFA, answering security questions, or modifying account permissions is a reasonable next step.
The Five Eyes agentic AI guidance recommends that high-impact actions require human approval and that systems fail safely when uncertain. Password rotation should be treated as a high-impact action, especially when the account protects email, money, business systems, healthcare information, or identity infrastructure.
I like the goal of this feature. I am not ready to trust the implementation just because it comes from Apple.
Before the fall release, these are the controls I would want Apple to document and security researchers to test:
The AI should never receive plaintext passwords in its model context, logs, memory, or telemetry. A separate credential broker should fill secrets only into verified fields on a verified origin.
The agent should be able to change the password and nothing else. It should not modify MFA, recovery methods, account permissions, profile information, or trusted devices.
The user should select the account and approve the final password change with Face ID, Touch ID, or another fresh secure-intent check. Bulk changes should require clear review and sensible limits.
Website text, scripts, support widgets, ads, and embedded content should never be able to persuade the agent to reveal a secret, navigate to an unrelated origin, or perform a different security action.
The system should verify the exact website and account before filling or changing anything. Redirects and cross-domain flows should receive extra scrutiny, not automatic trust.
Apple should verify that the new password works and is safely stored, clearly report partial failures, retain enough protected state to support recovery, and avoid retry loops that create lockouts.
Users should have a durable history of what changed, when, why, and with what result. Managed environments should have a way to restrict or disable the feature for business credentials.
This feature deserves focused adversarial testing during the beta period. Researchers should be encouraged to test prompt injection, malicious redirects, ambiguous forms, multiple-account confusion, partial failures, and abuse from a compromised local session.
Those are not unreasonable demands. They are the minimum questions that come with giving an agent authority over authentication secrets.
Apple may have built a feature that meaningfully improves password security for millions of people.
That is what makes this worth taking seriously.
Most users are not going to manually work through a long list of compromised credentials. If Apple can safely turn warnings into completed fixes, reduce password reuse, and move more people toward strong credentials and passkeys, the result could be a real security win.
But convenience does not reduce the sensitivity of the action.
An AI agent operating in Safari is still processing untrusted websites. A password change can still lock out a user, disrupt connected systems, or create a false sense that an account is secure. On-device intelligence can still be manipulated by hostile input. An unlocked device can still be the wrong trust boundary for bulk account changes.
This is the broader lesson with agentic AI: the risk is not only whether the model gives a wrong answer. The risk is what the system is allowed to do with that answer.
I wrote recently that agentic AI is security’s next blind spot because it can act. Apple’s password-changing feature is a nearly perfect example. It takes a security recommendation that used to end with a human decision and gives software the ability to carry it through.
That can be useful.
It can even be safer than relying on people to fix every compromised password themselves.
But the more authority an agent receives, the less room there is for vague promises about privacy and intelligence. Apple needs to show the boundaries, the approval points, the failure modes, and the audit trail.
Because once an AI can change the key to your account, “it usually gets it right” is not a security model.