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 per tool in Agent → Settings tab → Enabled Tools section. Each tool has a toggle labelled Auto Execute or Approval Required. 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 you find a tool’s approval prompt unnecessary, flip the toggle to Auto Execute. The other way works too: a normally safe tool can be set to Approval Required when you want to keep a closer eye on it.

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.

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.

AUTO_DENY (blocked without a card)

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

A bash command containing patterns like rm -rf / (root or home paths), fork bombs, download-pipe-to-shell chains, mkfs.* filesystem formatting, or dd writes to raw block devices.
An agent hook explicitly configured to DENY the action.

An agent that receives AUTO_DENY does not retry the blocked command; it looks for an alternative approach.

Tool toggles and “Always Auto-Approve”

The agent’s Settings tab offers two independent approval controls:

Per-tool Auto Execute / Approval Required toggle (in the Enabled Tools section): permanently sets a tool to always run without a card or always ask. Applies to all runs including schedules and webhooks.
“Always Auto-Approve” section: a separate checkbox panel where checking a tool exempts all future calls of that tool from the approval prompt — also across autonomous runs.

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

The click / type / fill / select actions are classified using element metadata collected during the most recent snapshot. Fields collected per ref: visible text (text), aria-label, data-testid, submit-button flag (is_submit), form action origin (form_action), input type (input_type), autocomplete hint (autocomplete), password-form context (in_password_form), and cross-origin iframe origin (iframe_origin).

If metadata is absent — no fresh snapshot, stale ref, or sandbox template predates the feature — these mutation actions are fail-closed: they always resolve to REQUIRE_USER.

press (Enter, Tab, Escape, and similar key inputs) dispatches a global keyboard event to whatever element currently has focus and takes no ref parameter, so the element metadata classification above does not apply. It auto-approves by default. An approval card appears only when the agent explicitly marks the action as dangerous — for example, when it knows the current focus is on a form and pressing Enter would publish or submit it.

Agent self-classification (safety)

click / 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 aria-labels, and input placeholders — keyword-based blocking produced massive false positives where every comment-icon click and every textarea typing was escalated even though the irreversible commit was several steps away.

Instead, the agent attaches safety: {decision: "REQUIRE_CONFIRMATION", intent: "..."} to the tool call itself whenever it is about to perform an irreversible action (posting, sending, deleting, paying, unsubscribing, and similar). The signal escalates the call to REQUIRE_USER and the agent’s stated intent surfaces in the approval card’s Intent field. Self-classification is escalate-only — it can never lower the deterministic rules below.

Auth tokens

sign · login · log in · sign in · sign out · log out · register · create account in the element’s text / aria-label / data-testid trigger REQUIRE_USER only when a form context is also present (is_submit=True or inside a password-bearing form). A page-header “Sign in” navigation link is auto-approved — the form context guard distinguishes “going to the login page” from “submitting credentials”.

Sensitive autocomplete values

Write actions (type, fill) targeting fields with the following autocomplete attribute values always require approval:

cc-number cc-csc cc-exp cc-exp-month cc-exp-year cc-name cc-given-name cc-family-name one-time-code current-password new-password

evaluate vs probe

browser.evaluate runs static analysis on the script before deciding. A REQUIRE_USER classification fires on any of the following:

DOM writes: .innerHTML, .value = ..., .click(), .submit(), etc.
Navigation: location.href = ..., history.pushState(...), etc.
Network requests: fetch(), XMLHttpRequest, sendBeacon, new WebSocket
Storage writes: localStorage.setItem, document.cookie = ..., etc.
Code injection: eval(), new Function, setTimeout, setInterval
Script length over 1,000 characters

browser.probe reads structured data only — url, title, ready_state, scroll_position, selector_exists, selector_count, selector_text — and always auto-approves without any script analysis.

LLM escalation

The agent can escalate any call by adding safety: { decision: "REQUIRE_CONFIRMATION", intent: "..." } when it judges a mutation to be irreversible or high-stakes. This signal escalates only — the deterministic floor cannot be lowered by the LLM. Marking a read-only action (snapshot, scroll, probe) as REQUIRE_CONFIRMATION 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 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.

Core Concepts — balancing autonomy with human checks
Build Your First Agent — default tools and scheduling