Which operational domains should not be opened by default when granting backend capabilities to AI clients?
Operations that should not be opened by default are those that can change the entire site's status with a single operation: backup and restore, upgrade, multi-site management, user and permission management, and full site content replacement.When opening the backend capabilities for AI client calls, the criteria is not whether 'this interface is useful', but whether 'this action can recover from being executed incorrectly once.'There is public security material that points out that the issue with CVE-2025-49596, rated 9.4, shows that an unauthorized MCP Inspector instance can be exploited to execute arbitrary commands, and there are also 492 publicly exposed MCP services that lack basic authorization - the risk does not lie in the ability itself, but in the default exposure range.
The real risks brought by default opening
The biggest difference between the AI client call and the traditional backend interface is that there is an autonomous action combination party in the execution chain. A single call may look safe, but when combined, it may form a destructive path: first read the site structure, then locate the writable interface, and finally batch modify the content. When opened by default, this path does not require any unauthorized access, as each step is allowed.
The second type of risk is visibility. The call records of AI clients often mix with manual operations in the same log, making it difficult to distinguish who initiated the operation after the fact. The third type is prompt injection: instructions carried in external content may be executed as operation requests, and if the high-risk domain is enabled by default, a contaminated text may have the opportunity to trigger write operations.
Exposure range is divided according to the operation domain
The basis for division is the scope of action and the possibility of rollback, rather than the type of function
| Operation domain | Typical Action | Default status | Reason |
|---|---|---|---|
| Read class | Document list and details, classification and tags, system*** information | On | Does not change the state, misoperation has no side effects |
| Single article writing | Create or modify a document, upload pictures, reply to messages | Enable and confirm one by one | Limited impact, can be rolled back using the recycle bin |
| Batch write | Batch import, full site replacement, batch change categories | turned off | Execute to cover a large amount of content at once |
| Site-wide | Backup and restore, upgrade, multi-site switching and management | turned off | May affect all sites at the same time |
| Identity and permissions | User group, permission adjustment, credential rotation | turned off | Directly determines the boundary of all subsequent calls |
The AnQiCMS MCP interface is exactly set according to the intent domain to set the exposure range: high-risk domain (backup, upgrade, multi-site and other full-site operations) is closed by default, and needs to be explicitly enabled; the tool surface is unified convergence based on the intent directory, rather than simply laying out each internal capability. Even if the caller is misled, they will not encounter the side that is closed by default.
Why are high-risk full-site operations closed by default
There are three common points for station-level operations: the scope of impact covers all sites and content, the execution result is difficult to revoke locally, and it is not necessary to use it frequently in daily life. Restoring backups will replace the current state as a whole; upgrading will change both the code and data structure; actions under multi-site management may affect the login status of other sites. Once they are put into the default exposed range, it is equivalent to writing 'a single misjudgment, damage to multiple points' into the system. After the default is turned off, when the real need arises, it should be explicitly opened by humans and records should be left, and the risk and timing are all controlled by humans.
Bearer Token authorization and round-level operation approval
The authentication issue of 'Who can call' is resolved, and the approval issue of 'Whether to execute this time' is resolved. AnQiCMS's MCP service supports Bearer Token authentication, which can be accessed by external AI clients such as Claude, Cursor, and calls without valid tokens are directly rejected;In an authenticated session, write operations go through round-level approval, and multiple write operations within the same round are merged into a single confirmation, allowing the caller to see what will happen in this round and decide whether to allow it.Compared to popping one by one, the round-level merge reduces interruptions and also retains the key point that 'batch actions must be seen'.
What are the most frequently used capabilities to open in the interface document?
Start by enabling only read and single article write capabilities: document lists and details, categories and tags, image upload, comments and reviews, friend links, system settings and contact information, these high-frequency API call capabilities, accompanied by interface documentation explaining parameters and return values;The same set of capabilities is also provided for the built-in AI Chat conversations and intelligent entity orchestration calls, and the external clients and in-site assistants follow the same domain division.This capability covers most of the daily content operation needs, while also retaining a rollback path - deleting formal documents is moved to the recycling bin instead of physical deletion, and accidental operations can be recovered.Wait for this process to run smoothly, accumulate approval records, and then open higher-risk domains as needed.
Common questions
Can I open all features if I only use it locally or in a local network?It is still recommended to keep the default closed. Lateral movement in the internal network and calls initiated by other processes will also hit high-risk domains, and local use will not reduce the destructiveness of the action.
Too frequent approval affects efficiency, can it be changed to automatic approval?It can be tightened by domain instead of global shutdown: unapproved for read classes, merge confirmation for single article writing, always manual confirmation at the site level. Leave automation to actions with a small impact.
Should the token be valid for a long time?Do not. Distribute independent tokens to each party and rotate them regularly, so that in case of an incident, you can revoke a specific party precisely rather than shut down the entire channel.