How should my agent handle users' passwords and logins?

Delegated access versus stored passwords, the security and breach-notification duties that come with holding credentials, and a safer design.

Short answer

Avoid holding passwords if you can. Use delegated access (OAuth and scoped tokens) wherever the service offers it. If you must store credentials, you take on security obligations, and a breach of usernames and passwords triggers notification duties in most states. The model itself should never see a raw password.

Why passwords are different

• Breach notification. State breach laws commonly treat a username or email address together with a password (or the security question and answer) as personal information, so a breach of stored credentials can require notice even when no financial or medical data is involved. Deadlines are getting tighter: California (since January 1, 2026), New York, and Washington now require notice without unreasonable delay and no later than 30 days after discovery, subject to statutory exceptions. Washington also requires instructions to change passwords, and some states don't let you rely only on an email account whose credentials were compromised to deliver the notice. These duties start when an incident meets a state's breach definition, not simply because your agent holds passwords.
• Security duties. The FTC treats unreasonable data security as an unfair practice, and some states require a written security program for personal information. Financial services may bring in the FTC's Safeguards Rule or banking regulators' expectations.
• Third-party terms. Many services prohibit sharing passwords with third parties. Using a user's password may breach their account terms even when the user agreed.
• Banking access. The CFPB finalized its open-banking rule (Section 1033) in October 2024 to move consumer financial data access onto regulated APIs. A federal court stayed its compliance deadlines in October 2025, and the agency is reconsidering key provisions, including third-party authorization, fees, and data security. The rule has not been repealed, but its timeline and final requirements are uncertain. Banks are moving away from password-based screen scraping either way, so plan for API access.

A safer design

• Delegated access first. Use OAuth or similar scoped tokens, and request the narrowest scopes that work.
• Keep secrets out of the model. Credentials should live in a vault and be injected by your code at the moment of use. They should never appear in prompts, model context, logs, traces, or analytics.
• Let the user handle sign-in steps. Hand one-time codes, MFA prompts, and security questions to the user rather than collecting them.
• Make access visible and revocable. Show users which accounts are connected, and let them disconnect each one. Delete tokens and credentials on disconnect and on account deletion.
• Least privilege across the agent. A tool that only needs to read should not hold credentials that can pay or delete.
• Log actions, not secrets. Record what the agent did and what the user authorized, without passwords or session tokens.
• Delegated access isn't a free pass. OAuth narrows what the agent can do, but the access still has to be permitted by the user's authorization, the service's terms, and the law.

What to tell users

Your privacy policy and connection screens should say which accounts the agent can access, what it can do there, how credentials are stored, and how to disconnect. These statements have to match the code exactly.

Checklist an agent can run against the codebase

• List every third-party account the agent can access, and whether it uses OAuth tokens, API keys, or stored passwords.
• Find where credentials and tokens are stored, and how they are encrypted.
• Search prompts, model context, logs, traces, and analytics for any path where a credential could appear.
• Check how MFA codes and security questions are handled.
• Check what disconnecting an account and deleting the user's account remove.
• List the scopes requested for each integration and flag any that are broader than the features need.

If this applies to you

An agent product review covers credential handling with the rest of the agent's authority model. Adding a new account integration is a pre-build feature check.