Skip to main content

xAgent Approval Policies: Controlling Sensitive Tool Actions

Who This Is For​

This page is for ordinary users who need to confirm risky actions and administrators who need to configure security rules.

What It Is​

Approvals let a person confirm a specific risky operation before it runs. Approval policies define which tool operations can run directly, which require confirmation, and which should be rejected.

Users can submit a task normally. The session enters waiting_approval only when the Agent reaches a matching tool call. Approval resumes the preserved tool call; rejection prevents that operation from running.

Ordinary users only need to remember one thing: when the page asks for confirmation, check the action and its effect before allowing it to continue.

xAgent Approval Policy page showing rule types, risk levels, and approval decisions

When to Use It​

The current policy model can identify and control these main operations:

  • Workspace file reads, writes, and deletion.
  • Network requests and process execution.
  • Reading, writing, deleting, and transferring personal data such as email.
  • Creating sub-sessions.
  • Activating Skill drafts and submitting public Skills.

One tool call may produce several operation facts. xAgent merges their results with this priority: deny, approval, then allow.

How Ordinary Users Handle Approvals​

When a session is waiting for confirmation, handle it in this order:

  1. Check the action that will be performed.
  2. Check the involved file, external system, or recipient.
  3. Decide whether it matches the current task goal.
  4. If the work should only produce a draft, ask it not to send anything yet.
  5. Allow it to continue after confirming it is correct; reject it or add instructions when uncertain.

Do not approve an action just because the page says approval is required. The purpose of approval is to make users pause at an important point and verify it.

When a task originated from an IM connector and the original connection channel can still send messages, xAgent can send the approval notification back through that channel. Follow the notification format and reply with the approval reference plus the approve or reject wording. Only the first valid decision is accepted. The current release does not broadcast approvals from web-originated tasks to every IM channel.

How Administrators Configure Policies​

Administrators can maintain system-wide rules on the Approval Policies page. The page usually includes a policy overview, a visual editor, and advanced JSON.

Use the visual editor first where possible:

FieldHow to understand it
Atomic actionThe specific action type controlled by the rule
DecisionAllow directly, require approval, or reject
Resource scopeThe files, sessions, or external resources affected by the rule
RiskThe risk label for the action
Session typeWhether the rule applies to main sessions, sub-sessions, or all sessions
Data domainThe category of data covered by the rule
Sensitive actionWhether it involves sending, deletion, authorization, or another sensitive action
Host / URL prefixThe target scope for external requests

Policies are matched in order. The first matching rule takes effect. Put more specific and higher-risk rules first so a broad rule does not allow them too early.

System and Personal Policies​

Administrators maintain the system policy, while users can maintain a personal policy. The current beta evaluates the personal policy first and falls back to the system policy only when no personal rule matches or the personal rule uses inherit. An explicit personal match overrides the system decision.

The personal policy is therefore an override layer, not an add-only restriction layer. Enterprise environments that require administrator rules to be an immutable minimum baseline should evaluate whether personal policy editing is appropriate for the current beta.

Current Default Policy​

The default policy allows a main session to create sub-sessions and allows deletion in the current session's artifact directory. These actions require one-time approval by default:

  • Deleting other workspace files.
  • Transferring personal data to an external system.
  • Writing or deleting sensitive personal data.
  • Activating a Skill draft.
  • Submitting a Skill to the public library.

Other operations are allowed when no rule matches. Teams should add rules for network access, process execution, file writes, and external systems according to their risk requirements.

ScenarioRecommendation
Regular file readingAllow directly
Generating files in a workspaceAllow directly or require low-risk confirmation
Deletion, sensitive writes, or external sendingRequire approval
Access to an unknown external addressRequire approval or reject
Explicitly prohibited paths or systemsReject directly

Security requirements differ across teams. The current effective result is determined by the personal and system policies together.

Checks After Configuration​

Before saving, check:

  • Whether any direct-allow rule is too broad.
  • Whether deletion, sending, and external requests still require approval.
  • Whether the rule order works as intended.
  • Whether example hosts or paths were mistakenly used as real configuration.
  • Whether a personal approval policy needs additional rules.

After saving, use a low-risk test task to verify that the policy takes effect.

Notes​

  • Approval policies do not replace account permissions.
  • Do not put keys, tokens, or real passwords into policy descriptions.
  • System policies affect every user, so edit carefully.
  • Personal rules can currently override system decisions; confirm this behavior fits the deployment's governance requirements.
  • Keep human confirmation for high-risk actions even when they are technically executable.
  • If you are unsure about a rule's scope, begin with a stricter rule and relax it gradually.

Continue Reading​

Next Steps​

Last updated on