A browser agent should stop visibly when a CAPTCHA or unexpected sign-in step requires human handling. Preserve the task and last verified step, then hand access recovery to an authorised person through an approved process. Before resuming, verify the restored account and current page state. If an action may already have created a record, reconcile that outcome first. Missing evidence is a reason to remain blocked, not permission to repeat the action.
For custom AI agents, this exception path belongs in the workflow brief before the first portal task runs. The proposed approach below needs application controls and an agreed human process; it is not a claim that browser agents provide these safeguards automatically.
Identify the blocker without guessing its cause
Record what the agent actually sees: a CAPTCHA, additional verification prompt, access-denied message or unfamiliar page. Preserve the location and observation time, using non-sensitive references. Do not label a password incorrect when the screen merely requests another verification step.
Give the business task a visible status such as “Blocked: authorised sign-in required”. Keep this separate from its output status: the requested report is still unavailable, or the draft’s creation is still uncertain. Navigation progress should not hide either condition.
Assign a person who can resolve access, with a fallback owner if they are unavailable. The notification should explain what needs attention and link to the restricted task record. It should not ask colleagues to send passwords or verification codes in an ordinary chat.
Separate access recovery from permission to continue
OpenAI’s changelog dated 29 September 2026 announced Agents API computer use, describing website access approvals and sign-in as application responsibilities. This supports designing an explicit handoff; it does not promise that an agent can resolve every challenge. Check current product, account, plan and region eligibility before deployment. Source: OpenAI API changelog
Specify how an authorised operator reaches the accepted sign-in process and returns control. If that cannot be done in the existing session, the workflow may need a fresh authorised session followed by reconstruction from saved task evidence. Do not promise that every portal supports seamless resumption.
Treat a new permission request separately. Restoring access does not authorise broader permissions. The access owner should review the requester, requested access and destination before accepting.
MCP security guidance describes per-client consent and authorisation protections for MCP implementations. Those requirements apply in that protocol context, rather than imposing identical controls on every browser portal. Source: MCP security best practices
Save enough context to resume safely
Preserve the approved task, account reference, last verified step and attempted action. Distinguish “opened the draft form” from “requested draft creation”. The second leaves a possible business-system change to investigate.
Save evidence references rather than authentication material. A restricted screenshot may help explain a blocker, but check it for exposed personal information or secrets before attaching it. A handoff record needs useful context, not the entire browser history.
OpenAI’s function-calling guide explains that application code executes model-requested functions. Where that pattern is used, the application should enforce whether a paused task can execute another action; a written instruction alone should not be the only gate. Source: OpenAI function calling
Browser-access exception brief
Use this reusable brief for each blocked task. The rules are proposed operating decisions for the business to approve.
Reusable exception record and handling rules
Task and ownership
- Task ID / approved brief version: ______
- Requested output / permitted actions: ______
- Approved portal / account or entity reference: ______
- Access owner / fallback owner: ______
- Business task owner: ______
Blocker and checkpoint
- Observed blocker / message / observation time: ______
- Page or destination reference: ______
- Last verified step / supporting evidence reference: ______
- Attempted action / whether it could change a record: ______
- Outcome: no change attempted / verified result / uncertain: ______
- Relevant task or record matching details: ______
Human handling and decision
- Human action taken / person / time: ______
- Evidence reference, excluding passwords, codes and tokens: ______
- Restored account or entity verification: ______
- Current page and business-state verification: ______
- Reconciliation result / authoritative evidence reference: ______
- Handoff decision: resume / remain blocked / manual completion / cancel: ______
- Next permitted step / deciding owner: ______
- If still blocked, next review trigger / responsible person: ______
| Situation | Required handling and resume evidence |
|---|---|
| CAPTCHA or additional sign-in | Stop. Authorised person uses the permitted process. Record verification of the restored account context and current page state before resuming. |
| New permissions or unexpected destination | Remain blocked while the access owner verifies the requester, scope and destination. Record the decision; rejection does not permit a workaround. |
| Exactly one verified matching record | Record its reference and verified match to the task. Resume past creation only when that record represents the intended action. |
| No matching record found | Retry only when authoritative evidence establishes that creation did not occur and the task owner confirms retry remains authorised. Search absence alone is insufficient. |
| Multiple plausible matches, inaccessible evidence or unresolved uncertainty | Keep blocked. A responsible person reconciles the outcome before another creation attempt. |
| Human changed business state | Record the change and evidence. Identify the remaining permitted step without repeating completed work. |
| Access cannot be restored | Keep visible ownership. Record manual completion, cancellation or another approved route as the human decision. |
Resume checklist
- Original task remains authorised and has not been completed elsewhere.
- Restored account context and current page state have recorded verification.
- Every uncertain action has been reconciled; unresolved uncertainty keeps the task blocked.
- Human changes and evidence references are recorded.
- Next permitted step and handoff decision are explicit.
- Final task evidence will be checked separately from successful sign-in.
Work through ordinary, missing and duplicate outcomes
The following situations are hypothetical. Their handling rules are proposed, rather than measured results or vendor guarantees.
Ordinary recovery: an agent collecting a supplier report encounters a CAPTCHA before requesting the download. It records the last verified account and selected report period. An authorised operator handles the permitted challenge. The operator records the restored entity and current report page; the agent rereads the filters before continuing. Successful sign-in does not establish that the report was downloaded.
One verified match: a session expires after a request to create an internal draft. Staff find one draft matching the approved task reference, entity and intended contents. They record that evidence and authorise continuation from the existing draft. The agent skips creation.
Missing evidence: staff find no draft in the visible list. That alone does not establish non-creation: the available view may be incomplete. If an authoritative system check establishes that creation did not occur, the task owner can authorise a retry. If staff cannot obtain that evidence, the task remains blocked with an investigation owner.
Duplicate or ambiguous matches: staff find several plausible drafts, or one draft whose reference matches but contents differ. They do not choose the newest by assumption. The responsible person compares the records with the approved brief and resolves which, if any, represents the attempted action. Until then, another creation attempt stays blocked. Any correction or deletion requires separate authority.
Resume from the current state, not the old screen
“Login fixed” is an incomplete handoff. The operator may also have changed a filter, switched entities or completed the task manually. Require the record to say what changed and where the evidence can be checked.
Before releasing the pause, reread the current account, page and relevant business state. Confirm that the task owner still wants the work. A delayed task may have been cancelled or superseded while access was unavailable.
During a pilot, deliberately test an unresolved challenge and an unavailable operator. Check that the task remains visible, another worker cannot restart it independently, and the fallback owner receives enough context to decide. Agree review triggers suited to the workflow instead of inventing a universal timeout. This exception design is part of custom-agent workflow planning.
FAQ about browser-agent access blockers
Should the browser agent keep retrying a CAPTCHA?
The proposed rule is to stop and hand over through the permitted process. Repeated attempts do not resolve who is authorised to handle the challenge. Record the blocker and owner, and keep the business task visibly pending.
Can the agent resume as soon as the sign-in screen disappears?
Only after checking the restored account, entity and current page against the brief. The operator must also disclose any business actions completed during recovery. The next step follows verified current state, rather than the agent’s earlier assumption.
What if nobody can prove whether the draft was created?
Keep creation blocked and assign reconciliation to a person with suitable access. Neither an empty search result nor a missing confirmation justifies another attempt. Continue only when evidence resolves the outcome and the remaining action is authorised.
If your business needs help defining this handoff, our AI automation services can help scope the task. Use the AI agents versus automation comparison and custom AI agent definition to clarify the approach, then get in touch to discuss your portal and exception rules.