How AI Browser Agents Handle MFA, CAPTCHA and Session Timeouts in Vendor Portals

Why Is Portal Authentication the Real Blocker, Not Data Extraction?

The hard part of vendor portal automation is getting logged in and staying logged in. Reading an invoice status table or filling a submission form is close to solved. What breaks a rollout is that each of your 40 customer portals guards its front door differently: one wants a six-digit code from an authenticator app, one texts a one-time password to a phone that sits in someone’s handbag, one throws a CAPTCHA after the fourth login of the day, one expires the session 15 minutes into a 40 MB attachment upload, and one disables the account after three failures.

That is why the objection from IT is not unreasonable. When finance asks for an AI browser agent to work the portals, IT hears a request to hand company credentials to software and walk it past the controls they were hired to defend. The answer is not to argue that the agent is safe. The answer is a per-portal authentication design, an evidence trail, and an honest list of the portals you will not automate.

Analyst coverage of agentic automation from firms such as Gartner consistently puts identity and access control ahead of model capability as the deployment constraint, and portal work is the clearest example. It is also why the sequencing advice in the 80/20 rule for portal automation matters so much: automate the large, well-behaved portals with clean authentication first and leave the awkward long tail until the pattern library is proven.

What Authentication Patterns Will an AI Browser Agent Actually Meet?

There are only about seven login patterns in the wild, and each has one correct handling approach. The distinction that matters is whether the factor is delegable. A factor that proves possession of a secret can be delegated to a controlled system that holds that secret. A factor deliberately bound to a physical human cannot, and no amount of engineering changes that.

Static password only. The simplest case and the easiest to govern badly. The credential lives in a secrets vault, is injected into the browser session at runtime, and never appears in a prompt, a configuration file or a log line.

TOTP authenticator app. At enrolment, the shared seed behind the QR code is stored in the vault rather than scanned into one person’s phone. The agent asks the vault for a freshly derived code at login. This is the single highest-value change you can make, because it converts a human-blocking factor into an unattended one without weakening the factor itself.

SMS or email one-time password. The destination moves from a personal device to a company-owned, access-controlled finance mailbox or number. The agent reads only messages matching the expected sender and format, consumes the code once, and writes an audit record saying a code was consumed, never the code.

Push-approval MFA. Someone has to tap approve, so batch the work. Schedule portal runs into one or two fixed windows per day, queue the approvals, and have a named finance user clear them in a few minutes rather than being interrupted 40 times.

Hardware security key and WebAuthn. Be honest: this is not automatable, by design. Credentials defined under the W3C Web Authentication standard and promoted by the FIDO Alliance are bound to a physical authenticator and the real origin, which is exactly the property that makes them phishing-resistant. If a portal mandates a hardware key, you need a separate service account on a different factor, the portal owner’s file transfer channel, or a manual process.

SSO and SAML to the buyer’s identity provider. Often the best outcome available, because the control moves into your own identity provider where conditional access, device posture and logging already exist. Ask the portal owner whether supplier SSO is supported before assuming it is not.

IP allowlisting. Not authentication on its own, but it changes the design. The agent must run from a stable, declared egress address, which also happens to be the strongest CAPTCHA suppression you have.

How Should Credentials Be Handled So IT Actually Signs Off?

The credential design is what converts the conversation from a debate into a review. Five rules cover almost every objection.

Credentials live in a secrets vault, not in the automation. The agent receives a short-lived reference and the value is injected at the moment of use. Nothing about a password or a code ever enters a prompt, a screenshot, an error message or a log. This is the control that most directly addresses the security risks of AI browser agents, where untrusted page content can attempt to manipulate an agent into disclosing what it holds; keep the secret outside the agent’s reasoning context and there is far less to disclose.

Use a scoped service account, never a named employee’s login. If the agent uses a person’s account, every portal action is attributed to someone who did not perform it, segregation of duties collapses, and the account keeps working after that person resigns. Auditors treat shared and borrowed credentials as a finding, and they are right to. Ask the portal owner for an integration account restricted to the specific tasks needed, typically invoice submission and status read, with no access to banking details or master data changes.

Rotate, revoke and review. Rotate passwords and TOTP seeds on a fixed schedule, tie revocation to your joiner-mover-leaver process so an offboarding triggers portal credential changes, and review the full credential inventory quarterly. Identity guidance such as the NIST digital identity guidelines and the governance material published by the Cloud Security Alliance are useful reference points when writing this policy, because they let you cite an external standard rather than defend a house rule.

Least privilege on the portal side and on your side. Only the finance users who need to see the run evidence should see it, and the vault entry should be readable by the automation identity alone.

The paperwork that goes with this, including the control narrative security teams ask for, is covered separately in the guide on getting IT security approval for portal automation. Use it rather than reinventing the review pack.

Why Does CAPTCHA Appear, and Where Is the Policy Line?

CAPTCHA almost never appears because a portal detected intelligence. It appears because something looked anomalous: too many actions per minute, a datacentre or rotating IP range, a headless browser fingerprint, a cleared cookie jar on every run, or a burst of failed logins. Fix those and the challenge usually stops appearing.

Pace the agent at human speed. Real users do not submit nine invoices in 40 seconds. Add realistic dwell between steps and cap actions per minute per portal.

Use a stable, static egress IP. One declared address that the portal owner can allowlist is better for both sides than a rotating pool, which looks exactly like abuse.

Keep a persistent browser profile per portal. Preserving cookies and local storage between runs means the portal recognises a returning device instead of a brand new one every night.

Run a real browser, not an obviously headless one. Fingerprint mismatch is a common silent trigger.

Then the line that should not be crossed. If a CAPTCHA is deployed specifically to forbid automated access, solving it is not an engineering problem, it is a terms-of-service and security problem. The correct responses are to get your service account and egress IP allowlisted by the portal owner, to move to their supplier integration or file transfer channel, or to accept that the portal stays manual. Guidance from OWASP on automated threats is a reasonable framing to bring into that conversation, because it lets you explain to the buyer that you are asking to be distinguished from abuse rather than asking them to relax a control. Portals that are rigid about submission mechanics in general are a broader problem, examined in the piece on inflexible vendor portal invoice submission tools.

How Do You Survive Session Timeouts and Long Uploads?

A 15-minute idle timeout during a multi-file upload is the most common cause of a half-finished submission. The pattern that solves it has four parts: resumable units, idempotency, positive verification and mid-run re-authentication.

Break the task into the smallest units that the portal itself treats as complete. Create header, attach document, enter line data, confirm submission. Checkpoint after each one.

Attach an idempotency key to every unit, derived from something stable like the portal identifier plus the invoice number plus the document hash. Before performing a write, search the portal for that key. If it already exists, mark the step complete and move on. This is what stops a retry from submitting the same invoice twice, which is a far worse outcome than a failed run.

Never trust an HTTP 200. A silent logout typically returns a perfectly healthy status code with a login page in the body, and an agent that only checks status codes will happily type invoice lines into a username field. Assert on a post-login element that only exists inside the authenticated session.

Re-authenticate mid-run and resume. When the session-validity assertion fails, the agent runs the full login sequence again, including the second factor, and resumes from the last confirmed checkpoint rather than from the beginning.

run_id: RUN-2026-09-30-0041          # immutable, appears in every audit record
portal: customer-portal-a            # scoped service account, not a person
idempotency_key: portalA|INV-88213|sha256:9f2c...
steps:
  1 login                 status: done       session_assert: account_name_visible
  2 create_header         status: done       portal_ref: SUB-55120
  3 attach_pdf            status: done       screenshot: step3.png
  4 enter_lines           status: failed     reason: session_expired_silent_200
  5 confirm_submission    status: pending
recovery: re-auth -> verify SUB-55120 still open -> resume at step 4
guard: if portal already shows INV-88213 submitted, close run as complete

What Happens When the Agent Collides With Your Own AR Clerk?

Concurrency is the failure nobody plans for. A large share of vendor portals permit only one active session per account. When the agent logs in at 10:40 and the accounts receivable clerk is mid-submission, one of them gets evicted, and the evicted party usually loses unsaved work without understanding why.

There are three controls, in order of preference. Give the agent its own service account so the human and the agent never share a session identity. Where the portal will not issue a second account, assign an exclusive scheduling window, usually overnight, and publish it so the team knows the portal is agent-owned between those hours. Third, hold a per-portal lock in the orchestration layer so two parallel agent runs cannot target the same portal at once, which becomes essential the moment you start running portals in parallel for throughput.

The same discipline is what makes a large estate manageable rather than chaotic, as covered in the guide to scaling vendor portal management across 200 vendors.

How Do You Avoid Rate Limits and Account Lockouts?

Lockout is the outcome that damages the relationship with the customer, because someone at their end has to unlock the account and will ask why. The controls are unglamorous and effective: cap the number of login attempts per account per day well below the portal’s threshold, back off exponentially after any authentication failure rather than retrying immediately, stop entirely after two consecutive authentication failures and raise an alert instead of a third attempt, and cap actions per minute per portal so a burst never looks like scraping.

What Evidence Trail Will Security and Audit Ask For?

Keep this part short and technical, because the full review process belongs in the dedicated security approval guide. What an auditor wants from a portal run is the ability to reconstruct it completely: an immutable run identifier carried on every record, timestamped per-step screenshots showing what the agent saw and did, the service account identity used, the documents submitted with the portal’s own confirmation references, any human approval captured during the run with the approver’s identity, and a log entry recording that a one-time password was consumed without recording its value.

That record set maps cleanly onto what SOC 2 evidence requests, Singapore’s Personal Data Protection Commission guidance and the accountability expectations set out by the European Data Protection Board all ask for in different words: know who or what accessed personal data, under what authority, when, and be able to show it. Retain run evidence for a defined period, usually 12 to 24 months for the structured log and a shorter window for screenshots because of storage cost and personal data exposure, and write the retention policy down before go-live rather than after the first request. Agents that learn from their own run history, as described in the piece on browser agent feedback loops in invoice delivery, depend on exactly the same record being captured properly.

What Belongs in a Portal Onboarding Runbook?

Before any credential is issued for a new portal, answer eight questions and store the answers with the portal record. This takes about 30 to 60 minutes per portal and removes most of the surprises that otherwise surface three weeks into production.

1. What is the authentication type? Log in manually once and write down exactly what is asked for.
2. Where is the second factor delivered, and who else can see that destination?
3. Can the portal owner issue a scoped service account, and what permissions does it need?
4. What are the idle timeout, absolute session length, failed-attempt lockout threshold and unlock path?
5. Does the portal allow concurrent sessions, and if not, which window belongs to the agent?
6. What do the terms of service say about automated access, and do we have written permission?
7. Is there a test account or a low-value document we can run end to end first?
8. Who is the escalation contact, who owns the credential internally, and what is the manual fallback?

Making this a standard intake step is what keeps onboarding fast rather than ad hoc, which is the same argument made in the guide to new client portal onboarding velocity.

What Do You Do When a Portal Cannot Be Automated Safely?

Some portals will not clear the bar. Hardware-key-only authentication, an explicit contractual prohibition on automated access, or a customer whose security team simply says no. Triage the long tail into four buckets rather than treating every portal as a problem to solve.

Automate now: delegable factor, service account available, no prohibition. Automate with a human step: push approval or a periodic manual unlock, batched into a window so the human cost is minutes per day. Escalate to the customer: ask for supplier SSO, a service account, an allowlisted IP, or their standard supplier integration route. Most large procurement platforms, including the supplier programmes run by vendors such as SAP Ariba and Coupa, have a documented integration path that is a better answer than browser automation for high-volume relationships. Leave manual and monitor: low volume, high friction, no path. Track the cost so the decision can be revisited.

The economics of that last bucket are worth taking seriously, because the true cost of the long tail is usually hidden in spreadsheets and individual habits rather than in any system, a problem examined in the analysis of long-tail client portals and custom invoice delivery.

How Does Peakflo Handle Portal Authentication in Practice?

The authentication patterns above are design requirements, not edge cases, and Peakflo’s AI Browser Agent is built around them rather than retrofitted.

What the platform provides against each blocker in this article:

• Credentials held in a vault, never in prompts or logs. Per-portal scoped service accounts replace a named employee’s personal login, so offboarding does not break the automation and an auditor does not find a shared password.
• Secure authentication handling. The agent authenticates into the target system as a discrete, isolated step, so credential material never enters the reasoning layer or the execution transcript.
• Resilience to interface and session change. Because the agent reasons about the live page instead of replaying recorded coordinates, a mid-run logout that renders as a login page is recognised as a logout rather than processed as success.
• Intelligent exception handling. Lockout thresholds, validation rejections and closed POs surface as routed exceptions with context, not as a failed batch discovered the next morning.
• Parallel execution with controlled concurrency. Work runs across many portals simultaneously while respecting each portal’s concurrent-session policy, which is what stops the agent fighting your own AR clerk for the same login.
• Full audit trail with per-step screenshots. This is the artefact that security and audit actually ask for, and it is the difference between a six-week review and a one-meeting approval. The paperwork side of that review is covered in detail in our guide to getting IT security approval for AR portal automation.
• Deployment in days. Onboarding a new portal is a configuration exercise, not a development project, which is what makes scaling past 200 vendor portals tractable.

Peakflo is SOC 2 Type II certified, CASA Tier 2 validated, PDPA compliant and GDPR-ready, with Azure and Google SSO, so the identity and compliance questions in a security review have documented answers before the first call. Where a buyer’s system does expose a supplier-integration channel, native SFTP and REST API integrations are the better route, and the browser agent is reserved for the portals that offer nothing else.

To walk a specific portal’s authentication flow with our team, request a demo.

Our Verdict: Authentication Design Decides Whether Portal Automation Ships

After working through the authentication patterns, the failure modes and the evidence requirements, the recommendation is straightforward.

Proceed when

• The portal uses a password, TOTP, one-time password or SSO factor that can be delegated to controlled infrastructure.
• The portal owner will issue a scoped service account, or at minimum agrees in writing that automated access is permitted.
• You can route the second factor to a company-owned destination rather than a personal phone.
• Your platform produces per-step screenshots and an immutable run identifier by default.

Wait or stay manual when

• The portal mandates a hardware security key or platform authenticator with no alternative factor.
• The terms of service prohibit automated access and the customer will not allowlist you.
• The only available login belongs to a named employee and no service account is possible.
• Volume is low enough that the credential governance overhead exceeds the manual effort saved.

Our recommendation: treat authentication as a per-portal design decision with a written runbook, not as a platform feature you assume works. Expect to find roughly 6 or 7 distinct patterns across a 40-portal estate, expect 10 to 20 percent of portals to need a human step, and expect a small residue that stays manual. A programme that says so openly gets through security review considerably faster than one that promises everything works.

Conclusion

Portal automation does not fail on parsing invoices. It fails at the login screen, in the fifteenth minute of an upload, and in the security review where nobody can explain where the password lives. The fix is not cleverness against the control. It is a vault instead of a spreadsheet, a service account instead of a borrowed login, delegable factors handled properly and undelegable ones declared honestly, human-speed pacing instead of CAPTCHA arms races, resumable checkpoints with idempotency keys instead of blind retries, an exclusive run window instead of session collisions, and a screenshot trail with an immutable run identifier so audit never has to take your word for anything.

Build the eight-question runbook once, apply it to every new portal, and the conversation with IT stops being an argument. If you want to see what that evidence trail looks like in practice, request a demo.

Frequently Asked Questions

Can an AI browser agent get past multi-factor authentication?

An AI browser agent does not bypass multi-factor authentication. It completes the factor legitimately when the factor is delegable: deriving a time-based code from a seed held in a secrets vault, reading a one-time password from a shared monitored finance mailbox, or pausing for a human to approve a push. Hardware security keys are not delegable.

How does a browser agent handle TOTP authenticator codes?

During enrolment the shared secret behind the authenticator QR code is stored in a secrets vault rather than on one person’s phone. At login the agent requests a freshly derived six-digit code from the vault, uses it once, and never writes it to a log. The seed is rotated on the same schedule as the password.

Where should SMS and email one-time passwords be sent?

Send them to a shared, access-controlled finance mailbox or a dedicated number owned by the company, never an individual employee’s personal device. The agent reads only messages matching the expected sender and pattern, records that it consumed a code, and leaves the message for audit review.

What happens when a portal uses a hardware security key?

Hardware keys and platform authenticators using WebAuthn are deliberately bound to physical presence and the real origin, so they cannot be automated. The honest answers are to request a separate service account with a different factor, use the portal’s supplier integration or file transfer channel, or keep that portal manual.

Should we give the agent an employee’s portal login?

No. A named employee’s personal login is a standard audit finding because every action the agent takes is attributed to a person who did not perform it, and the account survives in the portal after that person leaves. Use a scoped service account with least-privilege permissions instead.

Why does a portal suddenly start showing CAPTCHA?

CAPTCHA is usually triggered by velocity, a new or shared egress IP address, a headless browser fingerprint, or a burst of failed logins. Slowing pacing to human speed, using a stable allowlisted egress IP and keeping a persistent browser profile removes most triggers without touching the challenge itself.

Is it acceptable to solve CAPTCHA automatically?

No. If a CAPTCHA exists specifically to prohibit automated access, defeating it is a terms-of-service and security problem rather than an engineering problem. The correct responses are to have the portal owner allowlist your service account and egress IP, use their supplier integration channel, or leave the portal manual.

How do you stop a session timeout from corrupting an invoice upload?

Break the task into resumable units with a checkpoint after each one, attach an idempotency key derived from the invoice number and portal, and verify the portal’s own record before marking a step complete. On timeout the agent re-authenticates and resumes from the last confirmed checkpoint.

How does an agent detect a silent logout that returns HTTP 200?

Never trust the status code. The agent asserts on a post-login element that only exists inside the authenticated session, such as the account name or a submission table header. If that assertion fails, the run is treated as logged out, re-authenticated and resumed rather than continuing blindly.

What stops the agent from double-submitting an invoice on retry?

An idempotency key plus a read-before-write check. Before resubmitting, the agent searches the portal for the invoice number and the document reference it would create. If a matching submission already exists, the step is recorded as already complete and the retry is suppressed.

What if the agent and a human clerk use the same portal login at once?

Many portals ban concurrent sessions and evict whichever session logged in second, so both parties lose work. The fix is either a separate account for the agent or an exclusive scheduling window, typically overnight, with a lock that prevents a second agent run starting on the same portal.

What evidence will security and audit ask for after a portal run?

An immutable run identifier, timestamped per-step screenshots, the service account used, the documents submitted with their portal confirmation numbers, any human approval captured during the run, and a log that records that a one-time password was consumed without recording the code itself.