Can AI agents log in to websites?

Where agents actually get stuck

Login itself is rarely the problem. The obstacles are the defences built to stop bots, and interface patterns that assume a human is watching.

• CAPTCHA and bot-detection challenges, which most agents cannot solve and will not try to.
• Two-factor codes sent to a phone or email the agent has no access to.
• Buttons that only respond to real mouse events, or inputs that need a paste-blocked keystroke sequence.
• Login modals that open over the page without changing the URL, so the agent never registers a state change.
• Silent failures: a wrong password returns the same page with a small red line the agent does not read as an error.

Should you let agents in at all?

That is a business decision, not a technical one. If your customers are starting to use assistants to check an order, renew a subscription, or pull an invoice, blocking every agent means blocking those customers.

The middle path most companies land on: allow agents on read-only and self-service journeys, keep hard verification on anything that moves money or changes credentials.

What to change

Make the authenticated path legible rather than clever.

• Give the login form stable, descriptive labels and names, not generated class strings.
• Return errors as visible text near the field, not only as colour or an icon.
• Change the URL when authentication state changes, so progress is observable.
• Offer an explicit route for automated access — an API key, a token, or a documented endpoint — for the journeys you are happy to open up.

How to know where you stand

The only reliable way is to run a real agent against your real sign-in flow and watch what happens. That is what PlateTale does: we drive the journey, record where the agent stalls, and hand you the specific fixes.