Handling Approvals

UpServe agents use many tools on your behalf. Most are safe to run on their own — searching the web, taking notes, organising files. A few are not: installing a new skill, hiring a new teammate agent, clicking a “Pay” or “Send” button on an external site. Those land in your chat as an approval card and wait for your call. This page tells you what those cards mean and how to respond.

Why approvals exist

Agents are capable, but they cannot read your mind. UpServe draws a line between two kinds of actions:

• Safe to just do — read, search, summarise, take notes. The agent runs ahead.
• Worth a second look — anything that touches the outside world, costs money, deletes data, or submits a form. The agent pauses and shows an approval card.

This pattern is sometimes called “human in the loop” automation. It keeps the agent moving fast while making sure the high-stakes moves go through you.

Auto Execute vs Approval Required

Every tool sits in one of two modes.

• Auto Execute — the agent uses it without asking.
• Approval Required — the agent shows you a card each time before running it.

You can change this in Agent → Settings tab → Enabled Tools section. When you expand that section, each active tool shows a single button — either Auto Execute or Approval Required. Tapping or clicking the button flips that tool’s setting immediately.

The defaults are:

• Approval Required (default): installing a new skill, creating a new teammate agent, equipping a teammate with tools or skills, spawning a sub-agent, sharing a file externally, creating/updating/deleting a schedule, and POST/PUT/DELETE external API calls.
• Auto Execute (default): web search and reading, note-taking, GET-style API lookups, team chat, and similar read-only work.

On top of that, when an agent is driving a computer screen and reaches a risky step it spots itself — a payment confirmation, a “Send”, a consent dialog, a delete button — it asks you about that one specific click, even if the tool is otherwise set to Auto Execute.

If a tool’s approval prompt feels unnecessary, tap the button to switch it to Auto Execute. The reverse works too: a normally safe tool can be set to Approval Required when you want a closer eye on it. Either way, the setting applies to all runs including scheduled and webhook-triggered ones.

What the approval card shows

When an approval is needed, a card slides into the conversation. It includes:

• Which tool is about to run — for example skill_install, team_agent_create, or the skill’s display name.
• What it will do — a short summary of the inputs (skill name and description, teammate name, etc.).
• Why it’s needed — a one- or two-line reason the agent wrote for itself, especially for risky screen actions.
• Time left to answer — a countdown bar at the bottom. If you don’t respond in time, the card closes and the agent decides on its own whether to continue without that tool or try a different approach.

Approve, deny, or let it lapse

The card has two buttons.

• Approve — the agent runs the tool immediately and continues from the result.
• Deny — the agent skips the tool and looks for another way, or asks you again. If you add a short reason, the agent remembers your preference so it won’t propose the same thing again later.

You can also type a quick reply in the chat instead of clicking — this works while the card is showing and you are in a direct (non-autonomous) conversation. Words recognised as approval: “yes”, “ok”, “approve”, “allow”, “confirm”. Words recognised as denial: “no”, “deny”, “cancel”, “reject”, “disallow”. Anything else — or an ambiguous phrase — defaults to denial for safety.

If you ignore the card, the timer eventually runs out and the card closes itself. The agent learns “the user didn’t respond” and moves on without that tool, or revisits it next time.

Approvals during autonomous runs

Agents don’t only work while you’re chatting. They can wake up on schedule or be triggered by an incoming webhook, and the same approval may pop up in the middle of that background work. When that happens:

• The card lands in the agent’s chat as usual.
• If you have push notifications on, you’ll get an “Approval needed” alert.
• For schedule, heartbeat, and webhook runs, the wait time is extended automatically, because those runs assume you can’t reply right away. Push notifications are also sent whenever the timeout reaches 10 minutes or more — even on a regular chat session.
• If the approval or question comes from a Workstream — a separate piece of work the agent opened alongside your main conversation — it resolves automatically faster than one in the main conversation. This keeps a single Workstream from holding up the main conversation while it waits for you. The one exception is a question where the agent hands the screen over to you for something it can’t do itself (signing in, entering a verification code, and similar) — that waits for you to actually open the Workstream, with no shortened timer. See Workstreams to learn what a Workstream is.

To make sure you don’t miss these, enable push notifications in Notification Settings .

Common scenarios

1) Installing a new skill from the marketplace

When the agent decides “this skill would help with my task,” it calls the install tool. The card shows the skill’s name and description plus a short reason for needing it. If you trust the package, Approve; otherwise Deny with a note like “use a different approach this time.”

2) Adding a new specialist to a team

A team-leader agent may try to spin up a new teammate to handle part of the work. You’ll see the proposed name and role. Approve to let it hire the teammate, or deny and the leader will continue with the existing team.

3) Reaching a payment or “Send” step on an external site

When an agent is browsing the web and reaches a high-impact button — Post, Pay, Send, Delete, Agree — it asks before clicking. Read the reason on the card, then decide.

4) Exporting the agent’s own work as a reusable skill

When the agent packages what it built into a shareable skill, a skill review card appears — distinct from a regular approval card. On that screen you can edit the name, description, and file list before confirming. Confirming does not publish the skill immediately.

How the web browser decides what to approve

When an agent uses the web browser tool — opening pages, clicking buttons, typing into fields — the approval decision is based on what that action actually does to the page, not just the action type. The same “click” that opens a menu is auto-approved; the one that posts a message needs your sign-off.

Always auto-approved

These actions observe the page without changing anything and always proceed without a card:

• Snapshots, screenshots, scroll, hover, back/forward navigation
• Checking the current URL, page title, or whether a specific element is present
• Waiting for content to load

Always requires approval

The following are irreversible or high-stakes, so the agent always asks first:

• Clicking a button that the agent itself flags as an irreversible action — posting, sending, paying, deleting, unsubscribing, and similar. What the agent is about to do is shown in the approval card’s Intent field
• Clicking an auth button — “Sign in”, “Log in”, “Register”, “Create account” — when it is inside a form (navigating to a login page without a form context is auto-approved)
• Typing into a password field, card-number field, or one-time code (2FA) field
• Clicking a submit button whose form posts to a different website
• Any click or input inside a third-party widget — payment dialogs, OAuth pop-ups, and similar
• Uploading a file

Context-dependent actions

A plain text input can go either way. Typing into a search box is auto-approved; typing into a field inside a login form requires approval. The agent looks at the role and context of the target element to decide.

If the agent tries to click or type without having taken a fresh snapshot of the current page first, it always asks for approval — there is no element information available, so the safer default applies.

What “auto-approve next N times” actually counts

The toggle on an approval card — “auto-approve next N actions of this kind” — only counts meaningful actions: the kind that warrant approval in the first place. Snapshots, URL checks, and other automatically-passing reads do not consume from that count. You will not burn through N faster than expected.

Advanced

This section is for users who want to tune approval policy per tool or understand what may stall a background run.

How tools are classified for approval

There are three paths that generate an approval card.

Always requires approval (static classification)

These tools trigger an approval card on every call:

• skill_install — install a marketplace skill
• team_agent_create — add a new permanent teammate agent
• team_agent_equip — assign tools or skills to a teammate
• sub_spawn — spawn a one-shot sub-agent
• file_share — upload a file and create a public download link
• schedule_create / schedule_update / schedule_delete — manage scheduled runs

Conditionally requires approval (dynamic classification)

• External API calls (http_request): POST, PUT, PATCH, DELETE methods require approval. GET/HEAD/OPTIONS are auto-approved.
• Computer-screen control (computer_use): click, double_click, right_click, key, type, drag, and shell actions require approval. Screenshots and scrolls do not.
• Web browser (browser): see the “How the web browser decides what to approve” section above.

Review (separate flow)

• skill_export — when the agent packages its work into a skill. Instead of a regular approval card, a skill review screen opens where you inspect the name, description, and file list before confirming.

Actions blocked without a card

Some actions are rejected immediately — the agent gets a “blocked by policy” result with no user prompt. Common cases:

• A code execution command containing system-destructive patterns such as forced deletion of root or home paths, fork bombs, download-pipe-to-execute chains, filesystem formatting, or direct block-device writes.
• An action that is explicitly set to blocked in the agent’s configuration.

An agent that hits this block does not retry the blocked command; it looks for an alternative approach.

Per-tool approval toggle

In Agent → Settings tab → Enabled Tools, each tool has a single button that controls its approval behaviour.

• Auto Execute: all future calls go through without a card, including scheduled and webhook-triggered runs.
• Approval Required: an approval card appears every time the tool is called.

How the toggle works under the hood adapts to the tool’s built-in risk level. For a tool that is “Approval Required” by default (like skill install or team agent creation), switching to “Auto Execute” permanently grants that tool automatic pass-through. For a tool that is “Auto Execute” by default, switching to “Approval Required” escalates it so you are always prompted.

All per-tool approval settings live in that one button next to each tool — there is no separate panel to check.

The “auto-approve next N times” toggle on an approval card is separate: it creates a one-session grant that expires after N uses.

Web browser approval policy in detail

How element risk is classified

Click, type, fill, and select actions are classified using element information collected during the most recent snapshot. The classification considers the element’s visible text, accessibility label, whether it is a submit button, its input type, autocomplete hint, whether it sits inside a password form, and whether it is inside a cross-origin frame.

If that information is absent — because no fresh snapshot was taken or the element reference has expired — these mutation actions fall back to a safe-default: they always require approval.

Key press actions (Enter, Tab, Escape, and similar) dispatch a global keyboard event to whatever element currently has focus and carry no element reference, so the element information classification above does not apply. They auto-approve by default. An approval card appears only when the agent explicitly marks the action as dangerous — for example, when it knows pressing Enter will publish or submit a form.

Agent self-classification

Click and type actions are not classified by label-keyword matching. On sites like X, Reddit, and Slack, action verbs (“Post”, “Reply”, “Like”) appear as card-section labels, comment-icon accessibility labels, and input placeholders — keyword-based blocking produced false positives where comment-icon clicks and normal textarea typing were escalated even though the irreversible step was several clicks away.

Instead, the agent directly marks any call it believes to be irreversible (posting, sending, deleting, paying, unsubscribing, and similar) and includes a short intent description. That signal raises the call to the approval level and surfaces the agent’s stated intent in the approval card’s Intent field. Self-classification is escalation-only — it can never lower the deterministic rules described above.

Auth tokens

Auth-related words (“Sign in”, “Log in”, “Register”, “Create account”, and similar) on an element trigger approval only when a form context is also present — the element is a submit button or sits inside a password-bearing form. A page-header “Sign in” navigation link has no form context and is auto-approved — the guard distinguishes “navigating to a login page” from “submitting credentials”.

Sensitive autocomplete values

Write actions targeting fields typed as card number, security code, card expiry, one-time code (2FA), or password always require approval, based on the field’s autocomplete type.

Script execution actions

The browser’s script execution action runs static analysis before deciding. Approval is required when the script contains DOM writes, page navigation, network requests, storage writes, code injection patterns, or exceeds a length threshold.

The read-only structured query action — which can retrieve the current URL, page title, scroll position, and whether specific elements are present — always auto-approves without script analysis.

Limits of agent self-classification

An agent that marks a call as dangerous will trigger an approval card. This signal is escalation-only — if a call is already required to have approval based on the deterministic rules, the agent cannot override that downward to auto-execute. Marking an inherently safe action (snapshot, scroll, read-only query) as dangerous is silently ignored by the over-mark guard.

What happens after you deny

When you deny, the agent receives:

• A clear signal that the user explicitly declined.
• The reason you typed (if any).
• An instruction not to repeat the same suggestion.

The agent saves your preference as a “feedback” memory note, then either tries an alternative or asks you a clarifying question. The net effect is that the same proposal won’t keep coming back in future runs.

How long the agent waits

When a tool is set to Approval Required, the default wait time depends on the tool type:

• Code execution — about 5 minutes
• Driving a computer screen — about 10 minutes
• Installing a skill — up to 1 hour (so you can read the skill’s contents)
• Everything else — the default value

For schedule and heartbeat runs, these times are automatically multiplied by 4. For webhook runs, they are multiplied by 2. A single approval will never wait more than 24 hours total.

Approvals and questions raised inside a Workstream (a separate piece of work the agent opened alongside the main conversation) get one more cap on top of the above — 10 minutes for an approval, 15 minutes for a question — even if a schedule or heartbeat multiplier would otherwise extend it further. This keeps one Workstream from blocking the main conversation for long while it waits on you. The one exception: a question where the agent hands screen control over to you (sign-in, a verification code, and similar) skips this cap and keeps its original wait time, since actually opening the Workstream and acting on it takes real time. These numbers may be tuned as the feature stabilizes. See Workstreams for the concept.

Approvals in Shared (Snapshot) mode

When you open an agent via a share link (/share/...) or embed (/embed/...), the external session runs against a fixed allowlist of safe tools. Tools that require approval — like skill installs or agent creation — are not available in that session at all, so no card appears for them.

However, tools that are in the allowlist can still generate dynamic approval cards in some circumstances (for example, a browser action that reaches a high-risk element). External visitors may see those cards, but their responses have no lasting effect on your agent’s settings. When you use the same agent directly as its owner, the full approval policy applies as normal.

Related pages

• Core Concepts — balancing autonomy with human checks
• Build Your First Agent — default tools and scheduling
• Workstreams — what a Workstream is and how it differs from the main conversation