Approval and manual confirmation

How it works

Manual confirmation occurs before execution. When the agent is about to invoke a tool that produces real side effects, it pauses and displays the pending operation type, target, and parameters in the conversation, then waits for confirmation before proceeding. Four confirmation options are available: Allow this time, Deny this time, Always allow, and Always deny. Persistent options (Always allow / Always deny) are recorded as preferences and affect subsequent invocations of the same type, while one-time options apply only to the current invocation. The exact wording of each option is provided by the agent in the confirmation card.

Operations that require confirmation are categorized by type: execute command, modify file, delete file, move file, read file, search file, network access, and run tool. The type determines the scope of impact — delete and execute-command operations have the highest proportion of irreversible outcomes.

In addition to in-conversation confirmation, two control points exist outside the conversation. User pairing in an IM channel is a true approval step: requests enter a pending-approval list and are approved individually by an administrator. Publishing a data access control policy is a self-service confirmation step: a confirmation dialog listing the scope of impact appears before publishing, and no second-person approval is involved.

Usage notes

In-conversation manual confirmation is initiated by the agent during execution. All users encounter it, and no additional configuration is required.

Publishing data access control policies and approving IM pairing requests are performed by members who have the corresponding administrative permissions.

Handle in-conversation permission confirmations

Your confirmation decision determines the scope of subsequent execution. Focus on the operation type and target rather than just the prompt text.

1. Read the operation type and target on the confirmation card. The type describes what the invocation will do, and the target describes which object it will act on.

2. Choose Allow this time when the scope of impact is clear and acceptable. This is the recommended option because it does not leave a persistent authorization for subsequent invocations.

3. Choose Always allow when the same type of operation will occur repeatedly during the current task and you have verified that it is safe. Do not use Always allow for delete, deploy, overwrite, or outbound operations.

4. Choose Deny this time when the target or scope does not match your expectations, then provide additional constraints in the conversation so the agent can adjust its plan and retry.

5. Choose Always deny when the operation type should never occur in the current scenario, to prevent the agent from making repeated requests.

After confirmation, the execution result is displayed in a tool invocation card. You can expand it to verify the input parameters and return values. For operations that modify content, the changes are displayed as a diff showing added and removed lines. Verify the scope of changes before confirming. For more information, see Start a conversation.

Publish a data access control policy

A data access control policy controls which data rows and columns a member can actually see. It takes effect immediately upon publishing, so pre-publish verification is more important than post-publish correction.

You can save a policy as a draft first. A draft does not affect existing access. While the policy is in draft status, you can preview the permission effect by simulating an identity: select an identity, run a permission test, and check the effective permissions and final filter conditions for that identity. Publish the policy only after the preview results match your expectations.

After publishing, the policy takes effect immediately. Active conversations apply the new policy starting from the next conversation turn. To temporarily revoke the policy, disable it — disabling also takes effect immediately. For details about how policy rules are composed and how their effects are calculated, see Security and compliance.

Approve IM channel pairing requests

Access on the IM side is controlled by pairing approval. After a user sends a message to the bot in IM, a request is added to the pending list. The administrator verifies the pairing code and then approves the request. Approval takes effect immediately; unapproved accounts cannot initiate queries through the enterprise bot.

The enterprise bot is visible to all members in IM. Skipping pairing effectively opens the data query entry to all accounts, so pairing must be approved individually. When a person leaves their position, revoke the pairing. Once revoked, the account immediately loses the ability to use the IM channel. For more information, see IM channel management.

Verify before subscribing or unsubscribing

Subscribing to a capability directly incurs costs, while unsubscribing interrupts tasks that depend on that capability. Both actions are completed in the portal. The product does not provide an approval step, so verification relies on manual confirmation before the action.

Before subscribing, confirm that the capability corresponds to the engine and scenario you are actually using. Before unsubscribing, confirm that no running scheduled tasks depend on the capability — tasks discover that the capability is unavailable only when they are triggered. For more information, see AI capability center.

Apply to production environments

High-impact operations in scheduled tasks do not rely on in-conversation confirmation. Scheduled tasks run unattended, and unanswered confirmation requests cause the task to stall. Therefore, agents for these tasks should mount only read-only connectors, and write or outbound operations should be handled in manually initiated conversations.

Review the scope of persistent authorizations periodically. Once a persistent preference is set, it remains in effect indefinitely. Over time, the permission boundary gradually broadens, which conflicts with the principle of least privilege.

Schedule policy publishing outside task execution windows. A policy takes effect at the next conversation turn, and if publishing overlaps with a scheduled trigger, the data scope may differ between two consecutive executions of the same task.

FAQ

• Q: Can I revoke an Always allow selection?

  A: Yes. In a subsequent conversation, you can select a deny option for the same operation type. Always allow records a preference, not an irrevocable authorization. However, operations that have already been executed will not be rolled back.

• Q: Who confirms permissions when a scheduled task runs?

  A: Scheduled tasks run unattended in independent conversations and are not suited for in-conversation confirmation. Use agents that mount only read-only capabilities for these tasks. Steps that require writing or outbound sending should be handled in manually initiated conversations.

• Q: Can I verify a data access control policy immediately after publishing?

  A: Yes. Before publishing, verify the policy by previewing with a simulated identity. After publishing, start a new conversation as the target identity, initiate a query, and check whether the returned data scope matches the preview results.

• Q: Why do some operations not trigger a confirmation prompt?

  A: Read-only operations do not cause actual impact in most scenarios. Whether confirmation is required depends on the operation type and whether you have previously selected the option to always allow the operation. Check whether this operation type has been recorded as always allowed. If necessary, select a rejection option again.