Seamless 2FA handling for autonomous browser agents
Channel | Typical Form | Notes |
---|---|---|
Authenticator App | Time‑based (TOTP) or counter‑based (HOTP) 6‑digit codes generated from a shared secret. | Most secure and our preferred method when you can access the secret. |
SMS | One‑time code delivered by text message. | Requires a phone number on record with the service you automate. |
One‑time code delivered to a mailbox. | Requires an email address on record with the service you automate. |
/authentication
endpoint or using the authentication center.
At runtime the browser agent generates the current code itself, allowing fully autonomous logins with no external dependency.
Tip – This approach also works for SMS or email 2FA when the underlying service lets you switch to an authenticator‑app factor.
Pros | Cons |
---|---|
Zero delay — agent stays autonomous. | One‑time account update required. |
Dedicated channel per credential — no collision between tenants. | Forwarding rule needed if humans still log in. |
Pros | Cons |
---|---|
No changes to the service’s 2FA configuration. | Requires user attention within ~5 minutes (default expiry). |
Works with any factor type. | Potential overnight downtime if sessions expire unattended. |
Scenario | Best fit |
---|---|
You control the account and can export the seed. | Vault‑Stored Secret |
Shared team account; you want agents + humans to log in. | CC 2FA Proxy with forwarding |
Highly regulated service that forbids factor changes. | User‑Driven Submission |