Retro Eye care Haitian Deep Dark Default

Data Encryption

The Data Encryption MCP feature plugin helps users plan, review, apply, and validate data encryption rule changes for ShardingSphere-Proxy logical databases. Actual encryption capability is provided by ShardingSphere-Proxy and its encryption algorithm plugins. This feature only generates and applies encryption rule DistSQL. It does not generate physical DDL, derived-column DDL, index suggestions, or data migration tasks.

Prerequisites

  • The current version supports logical databases exposed by ShardingSphere-Proxy only.
  • runtimeDatabases should point to Proxy logical databases, not physical storage databases.
  • This feature does not apply to direct database connections. The target database usually does not understand ShardingSphere encryption rule change statements and cannot expose Proxy-visible encryption algorithm plugins or rule state.
  • Users need to provide the target logical database, table, and column names. Planning does not inspect the real physical table structure.

Use through natural language

Users describe the encryption goal in an AI application that integrates ShardingSphere-MCP.

Examples:

  • Check whether <logic-database>.orders.status already has an encryption rule.
  • List data encryption algorithms available from the current Proxy.
  • Plan reversible encryption for <logic-database>.orders.status with equality query support, and preview it without execution.
  • Continue the previous plan with the AES algorithm and provide the key through a protected channel.
  • Confirm and execute the previous encryption rule plan, then validate the result.

Users should review encryption rule DistSQL, algorithm properties, rule column names, and side-effect scope before approving any side-effecting execution.

Describe an encryption requirement

When using natural language, include the following information when possible:

Information Description Example
Logical database, table, and column Specify the ShardingSphere-Proxy logical object to configure. “Configure encryption for <logic-database>.orders.status.”
Schema or namespace Recommended for multi-schema logical databases. “The schema is public.”
Operation type Create, alter, or drop an encryption rule. “Create an encryption rule” or “drop the encryption rule for this column.”
Encryption goal Describe whether reversible encryption, equality query, or LIKE query is required. “Use reversible encryption and support equality queries.”
Algorithm preference Specify an algorithm, or let MCP recommend one from algorithms available from Proxy. “List data encryption algorithms available from the current Proxy.” or “Prefer AES.”
Algorithm properties Sensitive values such as keys should be supplied through protected channels. “The key is supplied through a protected channel.”
Rule column names Provide column names used by the rule when cipher, assisted query, or LIKE query columns are required. “The cipher column name is status_cipher.”

Create, alter, and drop rules

Operation Natural language example Content to review
Create “Plan reversible encryption for orders.status, support equality queries, and preview first.” The new encryption rule, algorithms, properties, and rule column names.
Alter “Change the previous encryption plan to use AES, then preview it again.” The altered encryption rule and whether sibling encrypted columns are preserved.
Drop “Drop the encryption rule for orders.status and preview the impact first.” Whether the target column rule is dropped and whether sibling encrypted columns are preserved.

Review the encryption plan

After a plan is generated, review:

  • Whether the statements match the expected create, alter, or drop operation.
  • Whether logical, cipher, assisted query, or LIKE query column names in the rule DistSQL match expectations.
  • Whether keys, credentials, or other sensitive parameters are passed only through placeholders or protected channels.
  • Whether query capability, runtime rules, or existing business SQL may be affected.

Sensitive parameter handling

Encryption algorithms may require keys, salts, or other sensitive properties. Users can provide these values through secret reference objects and confirm the source and scope before execution.

Example:

{
  "primary_algorithm_properties": {
    "aes-key-value": {
      "secret_ref": "placeholder://secret-value-1"
    }
  }
}

When ShardingSphere-MCP returns model-facing plans, workflow resources, previews, execution results, validation results, recovery data, and error messages, recognized sensitive properties are masked. Built-in algorithms and custom algorithm properties marked as secret in algorithm property templates can be recognized and masked consistently. The secret_ref in a placeholder object only marks a sensitive slot for manual replacement. Planning, preview, execution results, and validation output do not echo secret_ref or real sensitive values. Undeclared custom properties should not be written in plaintext in normal conversations, logs, or ticket descriptions. If a rule change still contains sensitive placeholders, automatic execution returns secret_reference_manual_execution_required before side effects. Operators should replace real values outside MCP and the AI application, then execute manually.

Review Rule Column Names

Encryption rules may reference cipher, assisted query, or LIKE query columns. These column names are part of rule DistSQL only. ShardingSphere-MCP does not generate physical DDL for them or check whether the real physical table already has matching columns.

  • *_cipher is commonly used as the cipher column name.
  • If equality query is required, configure an assisted query column and assisted query algorithm in the rule.
  • If LIKE query is required, configure a LIKE query column and LIKE query algorithm in the rule.
  • If the real physical table needs new columns, indexes, or historical data processing, handle them outside ShardingSphere-MCP.

Preview, apply, and validate

Preview first, then review rule DistSQL and side-effect scope before execution.

Phase Natural language example User focus
Preview “Preview the previous encryption rule plan without executing it.” Inspect rule DistSQL, algorithms, and properties before execution.
Execute “Confirm and execute the previous plan.” Confirm that the side-effecting change has been reviewed.
Manual execution “Export a manual execution package without automatic execution.” Let operators review and execute in a controlled environment.
Validate “Validate whether the previous encryption rule has taken effect.” Check rule state and workflow execution result.

For the general review flow of rule changes, see Rule Change Flow.

Limitations

Supported scope

  • Supports ShardingSphere-Proxy logical databases only.
  • This feature does not apply to direct database connections.

Capability boundaries

  • ShardingSphere-MCP does not provide encryption algorithms and does not replace the user’s judgment on whether an encryption strategy satisfies business security requirements.
  • Planning results are reviewable change plans. Execution still requires user confirmation.
  • Planning and execution are limited to encryption rule DistSQL. Physical DDL, indexes, data migration, backfill, or data cleansing tasks are not generated or executed.
  • Dropping an encryption rule removes the rule only. It does not restore historical plaintext data, and unused physical columns or indexes still require manual cleanup.

Metadata boundaries

  • ShardingSphere-MCP plans rule DistSQL from Proxy-visible rule and algorithm state. Planning does not read or infer the real physical table structure.
  • If a physical column referenced by the rule does not exist, users should handle DDL and data processing outside ShardingSphere-MCP.

Identifier handling boundaries

  • ShardingSphere-MCP handles quoted, case-sensitive, keyword, whitespace, and Unicode object names. To keep generated SQL or rule change statements reviewable, object name content must not contain backticks, NUL, carriage returns, or line feeds.