Why do we need a separate switch for high-risk operations like backup and upgrade when connecting to external AI clients

When connecting to external AI clients, operations such as backup, upgrade, and multi-site operations need to be set separately, because the caller has changed from 'the person sitting in the background' to 'a client that autonomously arranges intentions'. Once all capabilities are exposed at once, the impact of a single incorrect command is no longer limited to a single piece of content, but to the entire site's data. The AnQiCMS built-in MCP Server sets the exposure range based on intention domains,高危 domains are closed by default and need to be explicitly opened, and in conjunction with round-level operation approval, 'can call' and 'can land' are divided into two doors.

Why can't all capabilities be opened at once

When someone operates in the background, the risk is obscured by the interface itself: the delete entry is hidden in the second-level page, the full-site replacement requires selecting a range first, and there is a confirmation popup behind the upgrade button. These intercepts depend on 'someone watching the screen.'

After the external AI client takes over, this premise disappears. The client will decide on the next step to call based on the description of available capabilities, and it may call several interfaces in one task. If all capabilities are on the same exposed surface, any misinterpretation at any step in the task will directly fall on the production data, and no one can intercept it again in the middle.

The meaning of the separate switch is to leave the decision-making power to the site: which domains are visible to the outside world is decided by operations, not by the task description of the client.

Which high-risk domains are closed by default?

According to the scope of impact, the full-site operations are closed by default (DefaultOff), including data backup and recovery, system upgrade, and the ability to change the global state of multi-site management. The reading capabilities of the content domain are open by default, such as document lists and details, classification and tag queries, which are all low-risk read-only interfaces. The corresponding API call descriptions are in the interface documents.

Determine whether a domain should be closed by default, it's enough to look at two points: whether it can recover by itself after failure, and whether it affects a single piece of data or the entire site. Both backup and upgrade do not meet the requirements——recovery relies on existing backup files, and the impact is the entire database, so it is classified as a high-risk domain; uploading images belongs to the writing of a single asset, and the consequences of failure can be repaired at a fixed point.

What has round-level approval changed?

Even if the high-risk domain is explicitly enabled, it does not mean that write operations will be executed immediately. MCP supports round-level operation approval: within a round, client-generated write operations will be merged into a single confirmation, which will be approved by humans before being stored in the database, and the intent directory is responsible for classifying these operations by domain and describing them uniformly.

This brings about three practical changes: batch writes will not be split into dozens of separate confirmations, and humans see a summarized action; when confirming, you can see the complete scope of the operation, including how many documents will be affected; rejected operations will not be executed halfway, and the round will be rolled back as a whole.

Cooperate with Bearer authentication, adding an extra layer of control to the access interface: different clients can send different credentials, and when an abnormal call occurs, it can be traced to the specific access party instead of all requests sharing a single entry.

List of permissions review before access

Before enabling external client access, it is recommended to go through this list:

List the tasks first. Write down what the client is expected to complete, such as keyword search for articles, batch tagging, and generating column page copywriting. The task list determines the domains that need to be opened, and the capabilities that cannot list tasks should not be opened.

Further divide read and write. Separate queries and writes within the same domain, do not casually grant write permissions for read-only needs, as the client with write permissions may actively make changes.

Then try running. Run a round of real tasks according to the list on the test instance first, observe which capabilities the client actually used, and turn off the capabilities outside the list.

Finally, leave a trace. Confirm that the approval records of each operation can be traced to the发起方发起方and time, and be able to answer 'who approved this change in which round' when problems occur.

Exposed range comparison table

Common questions

All high-risk domains are closed, can the client still work?Yes. Daily content tasks can be handled on reading and single-item writing, the closure of high-risk domains does not affect posting, searching, and tag maintenance.

Can the domain that has been enabled be temporarily turned off?Yes. The exposed range can be adjusted by domain, it will be收回 after the temporary window ends, which is safer than long-term opening.

Will the approval slow down the batch task?One round can be merged into one confirmation, batch operations only need to be confirmed once, and the main time-consuming part is the scope verification before confirmation.

If the access party changes the client, do I need to issue a new certificate?It is recommended to rotate. After revoking the access credentials held by the old client, issue new ones to prevent historical access parties from continuing to call.