Cross-domain agent knowledge migration and privacy barrier system

Abstract

The invention relates to the technical field of data privacy protection, in particular to a cross-domain agent knowledge migration and privacy barrier system, which comprises a migration request analysis and sensitive marking unit, an original migration module extraction and identification, authority control and domain exclusive elements marking unit, an operation log containing a domain label and a timestamp generation unit, and a privacy barrier unit. The dynamic privacy barrier processing unit replaces an identity label with a generalization identifier, deletes violation elements according to a target domain sovereignty rule to generate a compliance knowledge module, separates, encrypts and stores a domain label and a timestamp, performs hash processing on a log operation type, and stores the log operation type; the privacy disclosure blocking unit scans residual identity labels and undeleted permission elements through secondary verification, and inputs a compliance block into a migration channel after verification is passed, and the system realizes accurate desensitization and compliance verification of cross-domain knowledge migration, prevents privacy disclosure, and ensures cross-domain collaborative security of agents.

Description

Technical Field

[0001] The present invention relates to the field of data privacy protection technology, and in particular to a cross-domain intelligent agent knowledge transfer and privacy barrier system. Background Art

[0002] Data privacy protection is an important technology. Against the backdrop of increasingly widespread collaborative applications of intelligent agents in multiple fields, enabling capability sharing among intelligent agents in different fields through knowledge transfer is of great significance for improving the overall efficiency of the system and accelerating the implementation of intelligent applications. This technology breaks through the capability limitations of intelligent agents in a single field and provides support for cross-industry and cross-scenario intelligent collaboration. Traditional knowledge transfer methods that lack privacy protection mechanisms can no longer meet data security compliance requirements.

[0003] However, existing cross-domain intelligent agent knowledge transfer technologies have the core problems of incomplete privacy protection and insufficient compliance. Traditional solutions do not accurately identify and process sensitive elements such as identity identification and permission control in the transferred knowledge. Only simple desensitization methods are used, which can easily lead to the residual of original privacy information. At the same time, there is a lack of dynamic adaptation mechanism for the data sovereignty rules of the target domain. The migration module may contain content that violates the regulations of the target domain, and there is a lack of effective secondary verification links, which can easily lead to privacy leakage risks. The combination of these problems makes cross-domain knowledge transfer face compliance disputes, which not only damages the rights and interests of data subjects, but also restricts the large-scale application of cross-domain collaboration of intelligent agents, and it is difficult to meet the stringent requirements of data security and privacy protection. In order to solve this technical problem, we provide a cross-domain intelligent agent knowledge transfer and privacy barrier system. Summary of the Invention

[0004] The purpose of the present invention is to provide a cross-domain intelligent agent knowledge transfer and privacy barrier system to solve the problems raised in the above background technology.

[0005] 1. Because traditional solutions fail to accurately identify and process sensitive elements in migrated knowledge, simple desensitization can easily result in residual private information. Therefore, this case constructs a knowledge element map to mark sensitive levels and generates an encrypted migration package, completely eliminating the risk of private information leakage.

[0006] 2. Because traditional solutions lack dynamic adaptation to the target domain's data sovereignty rules and are prone to compliance disputes, this case analyzes the target domain rules to generate an adaptation strategy and performs a secondary verification of the migration package to ensure that knowledge migration meets the target domain's compliance requirements.

[0007] To achieve the above objectives, a cross-domain agent knowledge transfer and privacy barrier system is provided, which includes a transfer request parsing and sensitive tagging unit. When a source domain agent initiates a knowledge transfer request to a target domain agent, the system extracts the original transfer module in the request, automatically tags the identity identification elements, permission control elements, and domain-specific elements in the original transfer module, and generates a migration operation log containing the domain labels of the source domain agent and the target domain agent and the migration trigger timestamp. The system is characterized by also including: The dynamic privacy barrier processing unit replaces the identity elements with generalized identifiers and outputs a primary desensitization module. Based on the data sovereignty rules of the target domain, it deletes the permission control elements and domain-specific elements that violate the regulations in the primary desensitization module, generates a compliance knowledge module, and finally separates the domain label and migration trigger timestamp, stores them in the storage area, and performs hash digest processing on the operation type in the migration operation log, retaining only the operation type summary code; The privacy leakage blocking unit performs a secondary verification before the compliance knowledge module is transmitted. The first-level verification is to scan whether the compliance knowledge module has any remaining original identity identification elements, and the second-level verification is to verify whether the permission control elements have been completely deleted. If the verification fails, the cross-domain intelligent agent knowledge migration is interrupted and a privacy violation event is triggered. If the verification passes, the compliance knowledge module is input into the cross-domain intelligent agent knowledge migration channel.

[0008] Compared with the prior art, the present invention has the following beneficial effects: 1. Through three parallel tagging engines, based on the cross-domain identity feature library, permission syntax tree and domain knowledge graph, the identity identification, permission control and domain-specific elements in the original migration module are accurately located, and the tagging conflicts are resolved through the sensitivity level arbitration mechanism to ensure that no sensitive elements are missed. The dynamic privacy barrier processing unit further adopts a layered generalization replacement strategy to replace the identity identification with a generalized identifier without domain orientation, and combines the sovereign rule-driven filter to delete the permissions and domain elements that violate the regulations of the target domain. At the same time, logical placeholders are filled to ensure the integrity of the data structure, completely eliminating the risk of residual privacy information caused by simple desensitization.

[0009] 2. The first-level verification of the privacy leakage blocking unit uses a residual identification deep scanner to detect whether there is unmasked original identity information based on generalized identifier rules to ensure the thoroughness of identity desensitization. The second-level verification calls the permission element trace detector and combines the deletion operation traceability chain to bidirectionally verify whether the permission element is completely deleted to avoid omission of illegal permission statements. If the verification fails, the system immediately interrupts the migration and triggers a violation event, blocking the privacy leakage path from a technical level. At the same time, the deletion operation traceability chain is bound to the compliance knowledge module in encrypted form and can only be audited by authorized parties. This not only meets the compliance traceability requirements but also prevents the traceability information itself from becoming a new privacy risk point. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 It is an overall block diagram of the present invention.

[0011] The meaning of each number in the figure is: 1. Migration request parsing and sensitive marking unit; 2. Dynamic privacy barrier processing unit; 3. Privacy leakage blocking unit. DETAILED DESCRIPTION

[0012] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0013] The present invention provides a cross-domain intelligent agent knowledge transfer and privacy barrier system, please refer to Figure 1 As shown, it includes a migration request parsing and sensitive marking unit 1. When the source domain agent initiates a knowledge transfer request to the target domain agent, it extracts the original migration module in the request, automatically marks the identity identification elements, authority control elements and domain-specific elements in the original migration module, and generates a migration operation log, which includes the domain labels of the source domain agent and the target domain agent and the migration trigger timestamp; The process of automatically marking the identity elements, permission control elements, and domain-specific elements in the original migration module in the migration request parsing and sensitivity marking unit 1 is configured with an initial privacy element marking rule, which includes three marking engines working in parallel: The identity tagging engine matches the user ID, device code, and organization authentication string in the original migration module with the pre-loaded cross-domain identity feature library and inserts an identity tag at the identified location; The permission marking engine parses the token declaration statements and role matrix definition blocks in the operation instructions according to the permission syntax tree, and marks the text segments containing access control keywords as permission control elements; The domain tagging engine calls the domain knowledge graph comparison module to identify proprietary terms and data patterns that are strongly related to the source domain and append domain-specific tags. The specific explanations are as follows: When the source domain agent initiates a knowledge transfer request to the target domain agent, the migration request parsing and sensitive labeling unit 1 first starts the extraction process of the original migration module. Specifically, it parses the protocol format of the request data packet, locates the payload field that carries the knowledge content, and extracts the original migration module containing information such as algorithm models, decision rules, and data features. It is then classified and stored according to data type to prepare data preprocessing for subsequent sensitive element labeling.

[0014] The initial privacy factor tagging rules further include a tagging conflict resolution mechanism. When the same data block is simultaneously tagged with different privacy factor types by multiple tagging engines, an arbitration protocol based on the factor sensitivity level is initiated: Set identity identification elements to the highest sensitivity level, permission control elements to the medium sensitivity level, and domain-specific elements to the basic sensitivity level; If the highest sensitivity level tag overlaps with the basic sensitivity level tag, the data block will be forcibly upgraded to the highest sensitivity level tag, and the conflicting coordinates and arbitration results will be recorded in the migration operation log.

[0015] On this basis, the unit uses three parallel tagging engines to accurately identify and tag sensitive elements based on the initial privacy element tagging rules. The specific working process of each engine is as follows: The core of the identity tagging engine is to achieve precise matching through a pre-loaded cross-domain identity feature library. The cross-domain identity feature library contains identity templates commonly used in multiple fields, such as the "prefix + numeric sequence" format of user IDs (such as "user_001"), manufacturer-specific encoding rules for device codes (such as "SN-XXX-XXXX"), and certificate format characteristics of institutional authentication strings (such as the X.509 format containing "CN=" and "O="). During recognition, the engine uses feature template matching and regular expression verification: First, the template in the feature library is used to compare the strings in the original migration module to filter out candidate fields that are suspected to be identity identifiers. Then, a regular expression (such as "^user_\d+$" for user ID) is used for secondary verification. After confirmation, identity identifier markers (such as " <id>< / id> ”), for example, after inserting markers at both ends of “user_001”, it becomes “ <id> user_001< / id> ", which clearly marks sensitive elements while retaining the original location information of the fields; The permission tagging engine relies on the permission syntax tree to implement structured parsing. The permission syntax tree is an abstract syntax tree model constructed according to the grammatical rules of the access control field. It contains the node types of the "keyword + parameter" structure of the token declaration statement (such as "granttoken:read on resource:A") and the "role-permission" mapping relationship of the role matrix definition block (such as "role:admin {perm:write, perm:delete}"). During parsing, the engine first decomposes the operation instructions into nodes of the abstract syntax tree according to the grammatical rules, traverses the nodes in the tree containing the access control keywords "grant", "revoke", "role", and "perm", and locates the corresponding text segments; then, these text segments are marked as permission control elements as a whole, such as adding "granttoken:read on resource:A" <perm>< / perm> " tag to ensure that the complete permission control logic unit is covered and avoid missed detection due to fragmented tags; The domain tagging engine completes the identification of unique elements by calling the domain knowledge graph comparison module. The domain knowledge graph contains the core concepts, term relationships, and data patterns of the source domain. The comparison module adopts a dual judgment mechanism of "concept similarity + pattern matching": First, the semantic similarity between the terms in the module and the core concepts in the source domain in the knowledge graph is calculated, and the highly similar terms are screened out. Then, the data structure is checked to see if it matches the unique pattern of the source domain. The results of the two are combined to identify the proprietary terms and data patterns that are strongly related to the source domain. Finally, domain-specific markers (such as " <dom>< / dom> ), for example, the medical field "ICD-10:I21.9" is marked as " <dom> ICD-10:I21.9< / dom> ", accurately delineates domain-specific information. When the three tagging engines work in parallel, they synchronize tagging progress in real time through shared memory to ensure that the original migration module is scanned without duplication or omission. This multi-engine collaborative tagging approach not only leverages the advantages of each engine in identifying specific sensitive elements, but also improves tagging efficiency through parallel processing. It provides a precise basis for sensitive element positioning for subsequent dynamic privacy barrier processing, making privacy protection targeted and comprehensive from the source.

[0016] The initial privacy factor tagging rules further include a tagging conflict resolution mechanism. When the same data block is simultaneously tagged with different privacy factor types by multiple tagging engines, an arbitration protocol based on the factor sensitivity level is initiated: As the three parallel tagging engines label the original migration module with sensitive elements, some data blocks may simultaneously possess characteristics of multiple sensitive elements (for example, a device authentication string containing a user ID, which is both an identity identifier and potentially associated with a domain-specific format). This can lead to the same data block being labeled with different types by multiple engines. To address this, the initial privacy element labeling rules further include a tag conflict resolution mechanism to ensure the uniqueness and accuracy of sensitive element labeling.

[0017] When the same data block is simultaneously labeled as different privacy factor types by multiple labeling engines, the system automatically initiates an arbitration protocol based on the factor sensitivity level.

[0018] Determination of "the same data block is marked by multiple marking engines at the same time": The system compares the marking coordinates output by each engine and the start and end indexes of the data block. If the coordinate overlap of two or more marks exceeds 80%, that is, most of the content of a data block is marked by two engines at the same time, it is determined to be a marking conflict. For example, in a certain text "user_001's device code in the medical system is SN-2023-005", "user_001" is marked by the identity marking engine, while "the device code in the medical system is SN-2023-005" is marked by both the domain marking engine and the identity marking engine, and the overlap reaches 90%, which triggers the conflict mechanism. The specific meaning of "different privacy element types" is: any combination of two or more of the identity identification elements, permission control elements, and domain-specific elements, such as "identity identification + permission control", "identity identification + domain-specific", and "permission control + domain-specific". The arbitration agreement based on the element sensitivity level is a set of judgment rules that set priorities according to the risk level of leakage of sensitive elements. Conflicting marks are arbitrated through preset sensitivity levels to ensure that high-risk elements are accurately marked first. The basis for determining the element sensitivity level is mainly based on the degree of harm that may be caused by the leakage of the elements. Identity identification elements are directly related to the unique identity of an individual or organization. Leakage will lead to the precise positioning of the privacy subject, and the risk is the highest. Permission control elements involve access permission configuration. Leakage may lead to unauthorized operations, and the risk is second. Domain-specific elements only reflect the characteristics of a specific domain. The scope of impact of leakage is limited, and the risk is the lowest. Based on the above basis, the system sets the identity identification element to the highest sensitivity level (level 3), the permission control element to the intermediate sensitivity level (level 2), and the domain-specific element to the basic sensitivity level (level 1). This setting not only complies with the core logic of data privacy protection, where identity information is the bottom line of privacy protection, but also takes into account the differentiated risks of permissions and domain information. When a tag conflict occurs, the system arbitrates according to the following logic: Extract all tag types and their sensitivity levels corresponding to the conflicting data blocks, compare the levels, and uniformly mark the data blocks as the element type with the highest level. If the highest sensitivity level tag (level 3) overlaps with the basic sensitivity level tag (level 1) (such as the identity identification element and the domain-specific element conflict), it will be forcibly upgraded to the highest sensitivity level tag. For example, in a hospital's equipment code "MED-SN-001 (belonging to the department: Cardiology)", "MED-SN-001" is marked by the identity tag engine (level 3), and "belonging to the department: Cardiology" is marked by the domain tag engine (level 1). The overlap is 85%. The system determines that the highest sensitivity level overlaps with the basic sensitivity level. Finally, the entire data block is marked as an identity identification element and " <id>< / id> " marker. At the same time, the system will record the conflict coordinates, conflict types and arbitration results in detail in the migration operation log, providing a traceable basis for subsequent audits. Through this conflict resolution mechanism, it can not only avoid desensitization omissions caused by label confusion, but also ensure that high-risk sensitive elements are processed first, so that the sensitive labels of the original migration module are both accurate and meet the core requirements of privacy protection, laying a solid foundation for the subsequent operations of the dynamic privacy barrier processing unit 2.

[0019] The generation process of the migration operation log is linked to the tagging operation. The logger captures the privacy factor type, location coordinates and conflict arbitration records output by the tagging engine in real time. At the same time, it extracts the registration domain label of the source domain agent and the registration domain label of the target domain agent from the knowledge migration request, and embeds the precise timestamp generated by the system clock synchronization. Finally, it is packaged into a structured log object and stored in the temporary cache area.

[0020] After completing the labeling of sensitive elements and conflict resolution, in order to ensure that the knowledge migration process is traceable and the operation is transparent, the generation of the migration operation log needs to be linked with the labeling operation to form a real-time closed loop of "labeling-recording". This linkage mechanism is achieved by establishing a data interaction channel between the logger and the labeling engine and the conflict arbitration module: when the identity labeling engine inserts the identity identifier, the logger immediately captures the privacy element type and location coordinates of the operation. When the permission labeling engine and the domain labeling engine complete the labeling, the logger synchronously collects the corresponding information in the same way. If the labeling conflict resolution mechanism is triggered, the logger will also capture the conflict coordinates (such as the index range "0x0050-0x0078" of the overlapping data block) and the arbitration results (such as upgrading to the highest sensitivity level label) in real time to ensure that each labeling operation and conflict handling are recorded immediately to avoid the loss of log information due to delays. At the same time, the logger needs to extract the registration domain tags of the source domain agent and the target domain agent from the knowledge migration request. The specific process is: Parse the metadata fields of the request (for example, in a request based on the HTTP protocol, the "X-Source-Domain" field stores the source domain label, and the "X-Target-Domain" field stores the target domain label). These labels exist in a structured form of "domain type + institution code" (such as "medical field_310001" represents the medical field intelligent entity of a medical institution in Shanghai, and "financial field_110002" represents the financial field intelligent entity of a financial institution in Beijing). After extraction, the system will perform format verification on the label to verify whether it contains the separator "_" between "domain type" and "institution code". If the format is incorrect, a request format exception prompt will be triggered to ensure the standardization of the label information. After obtaining the above information, the logger calls the system clock module to generate a timestamp accurate to milliseconds (such as "2024-05-20 15:30:22.123"), and packages the privacy factor type, location coordinates, conflict arbitration record, source / target domain labels, timestamp and other information into a structured log object in JSON format (for example: {"timestamp":"2024-05-2015:30:22.123","source_domain":"Medical_310001","target_domain":"Financial_110002","elements":[{"type":"Identity factor","coordinates":"0x0023-0x0045"},{"type":"Domain-specific factor","coordinates":"0x0060-0x0082"}],"conflict_records":[{"conflict_coordinates":"0x0050-0x0078","arbitration_result":"Upgraded to the highest sensitivity level"}]}). Finally, the log object is stored in a temporary cache area, providing a data source for the subsequent dynamic privacy barrier processing unit 2 to separate domain labels and timestamps, so that the entire log system not only supports privacy protection but also becomes a key link connecting the marking operation and subsequent processing links.

[0021] It is characterized by further comprising: Dynamic privacy barrier processing unit 2 replaces the identity identification elements with generalized identifiers, outputs a primary desensitization module, deletes the permission control elements and domain-specific elements that violate regulations in the primary desensitization module according to the data sovereignty rules of the target domain, generates a compliance knowledge module, and finally separates the domain label and migration trigger timestamp, stores them in the storage area, and performs hash digest processing on the operation type in the migration operation log, retaining only the operation type summary code; After the migration request parsing and sensitivity tagging unit 1 completes the tagging of sensitive elements, the dynamic privacy barrier processing unit 2 desensitizes the identity elements, replacing them with generalized identifiers through a layered generalization replacement strategy. This phased approach is implemented in stages: the first phase ensures accurate positioning and initial replacement of the identity identifier to avoid information distortion caused by indiscriminate processing; the second phase strips away domain attributes to eliminate domain specificity in cross-domain migration; and the third phase accurately backfills the desensitized information to ensure module structural integrity. This three-stage approach ensures thorough desensitization while also balancing data availability.

[0022] The process of replacing identity elements with generalized identifiers in the dynamic privacy barrier processing unit 2 adopts a hierarchical generalization replacement strategy: The first stage matches the original string covered by the identity marker and selects a replacement template based on its data type. The core of this stage is to select an adaptive replacement rule based on the type characteristics of the identity marker. The specific process is as follows: The system scans the original migration module for identifiers (such as " <id>< / id> ”) and extract the original string covered by the marker (such as “user_001”, “SN-2023-005”, “CN=A hospital, O=Medical system”). The type of the string is determined by the predefined type identification rules. The user ID usually contains the “user_” prefix and a digital sequence. The device code often contains the “SN-”, “DEV-” identifier and a date / serial number combination. The institution certification string follows the X.509 format (including the “CN=” and “O=” fields). The corresponding generalized template is called for different types. The user ID uses the “prefix + random The "alphanumeric combination" template is used ("user_001" is replaced by "usr_8F3D7"); the device code adopts the "universal identifier + the last 6 digits of the hash value" template ("SN-2023-005" is replaced by "Dev-7A2C91"); the institution authentication string adopts the "role identifier + anonymized organization code" template ("CN=a hospital, O=medical system" is replaced by "CN=Org_A, O=Inst_3"). By matching templates by type, the format of the replaced string can be guaranteed to be reasonable while avoiding direct exposure of the original identity information.

[0023] In the second phase, domain attribute cleaning is performed on the replaced strings, removing all modifiers containing source domain characteristics and generating a generalized identifier without domain specificity. The strings replaced in the first phase may still retain source domain characteristics (such as the "MED-" prefix for medical device codes), so domain attribute cleaning is required to eliminate domain specificity. The specific process is as follows: The system calls the registration information of the source domain agent (such as obtaining "medical domain_310001" from the migration operation log), loads the exclusive feature library of the field (including the "MED-" and "HOSP-" prefixes in the medical field, and the "BANK-" and "TRANS-" identifiers in the financial field), scans the replaced string, and deletes the modifiers containing the source domain features. For example, after the replacement in the medical field, "usr_MED_8F3D7" needs to delete "MED_" and become "usr_8F3D7", and after the replacement in the financial field, "Dev_BANK_7A2C9" needs to be replaced. 1" needs to delete "BANK_" and become "Dev_7A2C91". The format of the cleaned string is standardized (for example, all letters are capitalized and the number of digits is fixed) to ensure that it does not contain any features that can be associated with the source domain, and ultimately forms an identifier without domain orientation. The core of domain attribute cleaning is to cut off the association between the identifier and the source domain, avoid inferring the original domain information through feature words, and add a layer of protection for the privacy and security of cross-domain migration. After the identifier is generated, it needs to be accurately restored to the corresponding position of the original migration module to ensure the integrity of the module structure. The specific process is as follows: In the third stage, the generalized identifier is backfilled to the corresponding position of the original migration module to form a primary desensitization module. The position coordinates of the identity identification element are retrieved from the migration operation log (starting byte index "0x0023", ending byte index "0x0045"), the area to be replaced is determined, and the generalized identifier ("usr_8F3D7") generated in the second stage is written into the position corresponding to the original tag coordinates to overwrite the original identity string. After backfilling, the grammatical structure of the module is scanned. If the format is incorrect due to the replacement, the placeholder is automatically added to finally form a primary desensitization module. For example, in the original module, " <id> user_001< / id> After processing, "has access rights" becomes "usr_8F3D7 has access rights", which not only completes the identity desensitization but also maintains the integrity of the sentence. It also retains the necessary information structure for subsequent compliance processing based on the sovereign rules of the target domain, allowing the primary desensitization module to meet privacy protection requirements and have the basic conditions for further processing.

[0024] After completing the generalization processing of identity identification elements and generating the primary desensitization module, in order to ensure that the cross-domain migrated knowledge module complies with the security specifications of the target domain, the dynamic privacy barrier processing unit 2 deploys sovereignty rule-driven filters to perform compliance processing on the authority control elements and domain-specific elements according to the data sovereignty rules of the target domain. This process is a key link in achieving the adaptation of knowledge migration to the target domain rules. It can not only prevent illegal information from entering the target domain, but also ensure the availability of the module through structured processing. The data sovereignty rules of the target domain refer to the normative clauses on data access, privacy protection, and information usage formulated by the institution or industry to which the target domain intelligent body belongs. They cover the types of permissions prohibited from being introduced, domain-specific information restricted across domains, and data format specifications. These rules are stored in the form of parsable structured documents and contain clauses at three levels: "prohibited items", "restricted items", and "allowed items". Violation elements: refer to the content in the authority control elements or domain-specific elements in the primary desensitization module that matches the "prohibited items" and "restricted items" of the target domain data sovereignty rules. If these elements are not processed, they may violate the information security policy of the target domain. Among them, the dynamic privacy barrier processing unit 2 The data sovereignty rules of the target domain delete the operation of violating elements. A sovereign rule-driven filter is deployed. The filter loads the privacy compliance terms predefined in the target domain, scans the marked blocks of all permission control elements and domain-specific elements in the primary desensitization module, and physically deletes the element blocks that match the violation terms. At the same time, logical placeholders are filled in the deletion position to ensure the integrity of the data structure. An intermediate transition module is generated. The operation logic of deleting the violation elements according to the data sovereignty rules of the target domain is used. The target domain rules are converted into detection conditions through the sovereign rule-driven filter, and the violation elements in the module are located and deleted. At the same time, the data structure is maintained through placeholders to ensure the consistency of subsequent processing. The sovereign rule-driven filter simultaneously builds a deletion operation traceability chain when generating the compliance knowledge module, recording the type of the deleted element, the original location and the specific sovereign rule terms violated; This traceability chain is bound to the metadata segment of the compliance knowledge module in ciphertext form. Only when the target domain intelligent device needs to audit the privacy processing process, it can be decrypted and viewed with the authorization key. The specific process of the sovereign rule drive is as follows: The filter first retrieves the privacy compliance clause corresponding to the registration domain label of the target domain agent from the system rule library and parses it into a triple structure containing "rule ID-detection keyword-processing method" (such as rule ID: 001, detection keyword: "grant root permission", processing method: "physical deletion"; rule ID: 002, detection keyword: "medical case code", processing method: "physical deletion"). At the same time, to improve matching accuracy, the filter converts the natural language description in the clause into a regular expression ("prohibit the entry of medical records containing patient IDs" is converted to "^.*patient ID. Medical records. $"), forming a rule set that can be directly used for scanning. The filter traverses the primary desensitization module and identifies the permission control element marker (" <perm>< / perm> ”) and domain-specific element markers (“ <dom>< / dom> ”) to accurately locate the marked blocks of the two types of elements, recording the start and end coordinates of each block (such as the permissions block coordinates "0x0120-0x0150", and the domain-specific block coordinates "0x0200-0x0230"). For marked blocks nested in complex data structures, the filter will parse the hierarchical relationship ("the permissions block is located under the 'user_config' node") to ensure that no one is missed. The filter scans the content of each marked block line by line, matching the text with the detection keywords and regular expressions in the rule set: If the statements "grant root permission" and "revoke all restrictions" match the "prohibited items" in the permission control block, it is determined to be a permission violation element. If the domain-specific block contains the core terms of the source domain and the target domain rules clearly prohibit such information (the financial domain rule "prohibits the reception of medical genetic data"), it is determined to be a domain violation element. During the matching process, the filter will record the matched rule ID, block coordinates and specific violation text to form a violation list. For the element blocks in the violation list, the filter performs a physical deletion operation, that is, completely removes the text content of the block from the module. At the same time, in order to avoid the deletion operation from destroying the data structure of the module, a logical placeholder with the same format as the original block is filled in the deletion position. If the permission declaration statement (such as " <perm> grant root permissions< / perm> ”), then fill in “ <perm> [Compliance Adjustment: Permission Statement Removed]< / perm> ", if the data block is a domain-specific data block, fill in " <dom> [Compliance Adjustment: Field Data Removed]< / dom> The placeholder not only marks the deletion operation but also ensures the integrity of the module syntax. After processing all illegal elements, the filter performs overall syntax verification on the module, such as verifying the tag closure through the XML parser and checking the function structure through the code compiler. If there are syntax errors caused by deletion, they are automatically repaired and finally an intermediate transition module is generated. This process not only reflects the respect for the data sovereignty of the target domain, but also avoids the knowledge invalidation caused by "excessive deletion" through structured processing, so that cross-domain knowledge migration can achieve a balance between security and availability.

[0025] During the process of sovereign rule-driven filters generating compliance knowledge modules, to achieve traceability of the privacy processing process and prevent the traceable information itself from becoming a new privacy risk point, the system will simultaneously build a deletion operation traceability chain. This mechanism forms a closed loop with the deletion operation of the violating element, which not only meets compliance audit requirements but also ensures data security. When the filter performs the physical deletion operation of each violating element, it simultaneously triggers the traceability information collection mechanism, specifically recording three core contents: the type of the deleted element: whether it is a permission control element (marked as "PERM") or a domain-specific element (marked as "DOM"). For example, when deleting a "grant admin permission" statement, the type is recorded as "PERM"; the original location coordinates: accurate to the starting byte index and ending byte index in the module (such as "0x0120-0x0150"), and associated with the hierarchical structure of the location in the original migration module (such as "located in the third child under the 'Permission Configuration' node"); the specific sovereign rule clause violated: The matched rule ID and clause content ("Rule ID: 001, Clause: It is forbidden to receive declaration statements containing super administrator privileges") are recorded. This information is sorted by timestamp to form original traceability data for each record. The collected original traceability data is encapsulated into a structured traceability chain in JSON format. Each record contains the fields of "operation timestamp-element type-location coordinates-violation clause". The structured processing ensures that the traceability chain is readable and parsable, which facilitates the rapid location of key information during subsequent audits. To prevent unauthorized access to traceability information, the system uses an asymmetric encryption algorithm (such as RSA-2048) to encrypt the structured traceability chain. The public key is automatically generated by the system and used in the encryption process. The private key is saved by the administrator of the target domain intelligent body as an authorization key and is only enabled during audits. The encrypted traceability chain exists in ciphertext form and the content cannot be parsed by conventional means. The encrypted traceability chain is embedded in the metadata segment of the compliance knowledge module, that is, the descriptive information area of ​​the module header, through a special mark " <trace>< / trace> " defines the storage location, for example recorded in the module metadata as " <trace> Encrypted ciphertext content< / trace> This binding method ensures that the traceability chain is uniquely associated with the corresponding compliance knowledge module, avoiding audit confusion caused by the separation of traceability information and modules. When the target domain agent needs to audit the privacy processing process to verify whether there is excessive deletion or omission of illegal elements, it needs to obtain the traceability chain information through the following steps: The administrator submits an authorization request containing a private key to the system. The system uses key pairing verification to confirm the authority of whether the ciphertext encrypted by the public key can be decrypted by the private key. Access to the traceability chain is allowed only after the verification is passed. The system extracts the encrypted traceability chain in the metadata of the compliance knowledge module, decrypts it with the authorized private key to obtain structured JSON data, and then displays each traceability record through a visual interface, including the time, element type, location and violation reason of each deletion operation. The audit process itself will be recorded in the system log, including the audit time, operator, and summary of the viewed traceability chain content to ensure that the audit behavior is traceable and prevent the abuse of authorization keys. This mechanism, as an extension of the sovereign rule-driven filter, enables the entire dynamic privacy barrier processing process to not only have accurate violation processing capabilities, but also verifiable compliance endorsement, providing full-process protection for the safe implementation of cross-domain knowledge migration.

[0026] After the sovereign rule-driven filter generates the compliance knowledge module and constructs the deletion operation traceability chain, to further reduce the risk of privacy leakage during cross-domain transmission, the dynamic privacy barrier processing unit 2 uses the privacy metadata decoupler to separate and desensitize the sensitive metadata in the migration operation log. This process ensures the secure storage of core privacy information while preserving the log's operation traceability, forming a dual protection mechanism of "sensitive information isolation and operation trace retention." The privacy metadata decoupler first parses the structured format of the migration operation log and locates the source domain label, target domain label, and migration trigger timestamp using pre-set field identifiers. For example, from the log object {"source_domain":"Medical_310001","target_domain":"Financial_110002","timestamp":"2024-05-2015:30:22.123",...}, it accurately extracts the contents of three fields to form independent metadata fragments. The logic behind the stripping operation is that domain labels directly correlate to the agent's domain, while timestamps may indirectly reveal the temporal patterns of migration behavior. Both are private metadata that require strict protection and should not be transmitted with the main log body. The decoupler employs an innovative encryption strategy of "symmetric encryption + hash checksum": The stripped metadata fragments are first symmetric-encrypted using the AES-256 algorithm. The key is dynamically generated by the system and bound to the target domain identity to generate the encrypted ciphertext. The ciphertext is then hashed with SHA-256 to generate a checksum. For example, encrypting "Medical_310001|Financial_110002|2024-05-20 15:30:22.123" yields the ciphertext "j8F3...x9L2," with a hash checksum of "a7d2...f1c5." This layered encryption not only ensures that the metadata content cannot be leaked, but also verifies whether the ciphertext has been tampered with during the storage process through the check value. The system divides the physical server into independent isolated storage areas, uses hard disk partitions that are different from the cross-domain knowledge migration channel, and prohibits direct data interaction between the two. The decoupler writes the encrypted ciphertext and hash check value into the storage area through a dedicated interface and creates an index. The index key is the unique identifier of the compliance knowledge module. The storage area uses a hardware-level encryption chip to ensure that even if the physical storage medium is illegally accessed, the encrypted data cannot be cracked. This physical isolation design cuts off the association between sensitive metadata and the migration channel at the hardware level, avoiding the risk of collateral leakage during the transmission process. The decoupler traverses the fields that record the operation content in the migration operation log and extracts the natural language description text ("mark identity identification elements and trigger conflict arbitration" and "delete illegal permission control elements").These texts contain specific operational logic. If retained directly, they may leak the privacy processing rules of the system. Therefore, they need to be desensitized and converted. The irreversible conversion method of "semantic normalization + salt value hashing" is adopted to separate the domain labels and migration trigger timestamps, and store them in the storage area through the privacy metadata decoupler: The domain labels and timestamps are stripped from the migration operation logs, encrypted and stored in an independently constructed isolated storage area, physically isolated from the cross-domain agent knowledge migration channel; At the same time, the operation type description text in the log is irreversibly hashed, overwriting the operation details field in the original log to form a desensitized log containing only the operation type summary code: First, the operation description text is semantically normalized, unifying synonyms into standard expressions (e.g., "delete" and "remove" are unified into "delete") to ensure consistent formatting for descriptions of the same operation. A random salt value is then generated (each operation type has a unique salt value, such as "s@Lt_01" for "mark operation"). The normalized text and the salt value are concatenated and hashed using the SHA-512 algorithm to form a fixed-length operation type digest code. For example, the "delete illegal permission control element" is normalized and concatenated with the salt value "s@Lt_02" to produce the digest code "7f83...a2b1." The introduction of the salt value ensures that even if the text is identical, the digest codes for different operation types are different, enhancing the uniqueness and collision resistance of the hash result. The decoupler then overwrites the original "operation_details" field in the log with the calculated operation type digest code, while retaining other non-sensitive fields in the log, ultimately creating a desensitized log. For example, the "operation_details": "Delete illegal permission control elements" in the original log is replaced with "operation_hash": "7f83...a2b1". The desensitized log only reflects the existence of the operation and cannot infer the specific operation content. This not only meets the need for tracing operation traces but also avoids leaking privacy processing logic. Through the aforementioned operation of the privacy metadata decoupler, sensitive information in the migration operation log is completely stripped and desensitized. Domain labels and timestamps are securely stored through "encryption + physical isolation", and operation details are transformed through irreversible hashing to eliminate the risk of information leakage. This process, as the final step in the dynamic privacy barrier processing, not only continues the precise processing logic for sensitive elements mentioned above, but also provides a closed-loop guarantee for metadata security in cross-domain knowledge migration through innovative encryption and isolation methods. This enables the entire privacy barrier system to achieve a balance between privacy protection and compliance throughout the "processing-recording-storage" process.

[0027] The privacy leakage blocking unit 3 performs a secondary verification before the compliance knowledge module is transmitted. The primary verification is to scan whether the compliance knowledge module has any remaining original identity identification elements, and the secondary verification is to verify whether the authority control elements have been completely deleted. If the verification fails, the cross-domain intelligent agent knowledge migration is interrupted and a privacy violation event is triggered. If the verification passes, the compliance knowledge module is input into the cross-domain intelligent agent knowledge migration channel.

[0028] After the dynamic privacy barrier processing unit 2 completes the generation of the compliance knowledge module and the desensitized storage of the relevant metadata, to ensure that the generalization processing of the identity identification elements is thorough and without residue, the privacy leakage blocking unit 3 starts the first-level verification process. The first-level verification process of the privacy leakage blocking unit 3 activates the residual identification deep scanner, which builds detection rules based on the generalized identifier: Check whether there are any ungeneralized original identity strings remaining in the compliance knowledge module, and verify the integrity of the domain attribute cleaning of the generalized identifier. If any violation remains, a privacy violation event will be triggered and the leakage coordinates will be located. This link serves as a key line of defense before cross-domain knowledge migration, and forms a precise connection with the identity generalization processing mentioned above. Specifically, the system will enable a residual identification deep scanner, which first constructs a dual detection rule based on the generalized identifier features generated by the dynamic privacy barrier processing unit 2: first, extract the format template of the generalized identifier (such as the "usr_+6-digit alphanumeric combination" corresponding to the user ID, and the "Dev_+6-digit hash value" corresponding to the device code) as a benchmark for judging whether the string has been compliantly generalized; second, establish a reverse matching library of source domain identity features, which contains typical features of ungeneralized original identity strings (such as the "user_+number" prefix of the user ID and the "SN-+date" format of the device code). During verification, the scanner will traverse the full text of the compliant knowledge module byte by byte, and first check whether all strings containing identity identification features conform to the format template of the generalized identifier through the forward matching rule. For example, for "user_002" appearing in the module, it will be marked as a suspected ungeneralized original identity string because it does not conform to the "usr_+alphanumeric" template; at the same time, the scanner will call the reverse matching library to check the characters in the module. The prefix and structure of the string are compared for features. If text highly similar to the original identity identifier in the source domain is found ("SN-2023-006" is consistent with the encoding format of the ungeneralized device), it is directly determined to be a residual risk. To verify the integrity of the domain attribute cleaning of the generalized identifier, the scanner will extract the text content of each generalized identifier and perform keyword comparison with the source domain feature library (such as "MED-" in the medical field and "BANK-" in the financial field). For example, if the generalized identifier is "usr_MED_8F3D7", it is determined that the domain attribute cleaning is not thorough because it contains the source domain feature "MED-". If any of the above checks find residual violations, whether it is the presence of the ungeneralized original identity string or the residual source domain feature of the generalized identifier, the scanner will immediately trigger a privacy violation event and push a notification containing the violation type and risk level to the administrator through the system alert module. At the same time, with the help of the module's built-in coordinate positioning function, the starting and ending byte indexes of the violating content in the compliance knowledge module are accurately marked, providing precise guidance for subsequent problem troubleshooting. This verification process ensures the thoroughness of identity generalization and verifies the integrity of domain attribute cleansing through forward and reverse dual detection logic. It echoes the layered generalization strategy of the dynamic privacy barrier processing unit 2 mentioned above, further strengthening the privacy protection barrier for cross-domain knowledge transfer.

[0029] After completing the first-level verification to ensure that there are no residual identity elements, the privacy leakage blocking unit 3 immediately starts the second-level verification. The second-level verification process of the privacy leakage blocking unit 3 calls the permission element trace detector, which loads the deletion operation traceability chain recorded by the sovereignty rule-driven filter and performs two-way verification on the compliance knowledge module: Positive verification is performed to see whether all permission control element marking blocks have been deleted or replaced with placeholders, and reverse verification is performed to see whether there are permission control statements in the module that are not registered in the traceability chain. If an undeleted permission element or an unregistered permission statement is found, the verification is determined to have failed, focusing on the processing integrity of the permission control element. This link forms a closed-loop verification with the deletion operation of the sovereign rule-driven filter in the dynamic privacy barrier processing unit 2, further strengthening the privacy protection network. Specifically, the system calls the permission element trace detector, first extracts the deletion operation traceability chain ciphertext generated by the sovereign rule-driven filter from the metadata segment of the compliance knowledge module, decrypts it with the authorization key of the target domain, and parses out the type of the deleted permission control element, the original location coordinates and the corresponding sovereign rule clauses, which are used as the verification benchmark. In the positive verification stage, the detector locates the corresponding positions of these coordinates in the compliance knowledge module one by one based on the permission control element marking block coordinates recorded in the traceability chain, and checks whether the content of the area has been physically deleted or replaced with a preset logical placeholder (such as " <perm> [Compliance Adjustment: Permission Statement Removed]< / perm>”). For example, if the traceability chain shows that there was a permission control element of "grantadmin permission" at a certain coordinate, the detector will verify whether the original statement at that location has disappeared or whether it has been replaced by a placeholder. If it is found that the original statement has not been deleted and replaced, it will be directly marked as a verification exception. This process ensures that all permission elements that should be deleted are properly handled to avoid the retention of illegal content due to omissions. The reverse verification starts from the module as a whole. The detector traverses all text segments containing permission control features in the compliance knowledge module and compares the position coordinates of these text segments with the coordinates of the permission control elements registered in the traceability chain. If it is found that the coordinates of a permission-related text segment do not appear in the traceability chain, it is determined to be an "unregistered permission control statement". For example, if "revoke user read There is a statement with "permissions", but there is no corresponding deletion or retention record in the traceability chain, which means that the statement may not have passed the compliance check of the sovereign rule-driven filter and there is a potential risk. Once the forward verification finds the undeleted permission elements, or the reverse verification detects the unregistered permission statements, the detector immediately determines that the secondary verification has failed, and then interrupts the cross-domain knowledge migration process and triggers a privacy violation event. At the same time, the violation location, content and verification failure type are recorded in detail in the system log to provide accurate clues for subsequent investigation. Through forward and reverse two-way verification, the permission element trace detector ensures that "what should be deleted has been deleted" and eliminates "unreviewed retention", forming a logical closed loop with the previous permission element marking and deletion operations, making the processing of permission control elements controllable and verifiable throughout the process, adding another key guarantee for the compliance of cross-domain intelligent knowledge migration.

[0030] In the present invention, the migration request parsing and sensitive marking unit 1 extracts the original migration module and marks the identity, permission control and domain-specific elements, generates an operation log containing domain labels and timestamps, and the dynamic privacy barrier processing unit 2 replaces the identity with a generalized identifier, deletes the illegal elements according to the sovereignty rules of the target domain to generate a compliance knowledge module, separates and encrypts the storage domain labels and timestamps, and hashes the log operation type. The privacy leakage blocking unit 3 scans the residual identity and undeleted permission elements through secondary verification, and inputs the compliance module into the migration channel after the verification is passed. The system realizes accurate desensitization and compliance verification of cross-domain knowledge migration, prevents privacy leakage, and ensures the security of cross-domain collaboration of intelligent bodies.

[0031] The above shows and describes the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions are merely preferred examples of the present invention and are not intended to limit the present invention. Various changes and improvements may be made to the present invention without departing from the spirit and scope of the present invention. Such changes and improvements fall within the scope of the present invention. The scope of protection claimed in the present invention is defined by the appended claims and their equivalents.

Claims

1. A cross-domain agent knowledge transfer and privacy barrier system, comprising a transfer request parsing and sensitive marking unit (1), which extracts the original transfer module in the request when the source domain agent initiates a knowledge transfer request to the target domain agent, automatically marks the identity identification elements, authority control elements and domain-specific elements in the original transfer module, and generates a transfer operation log containing the domain labels of the source domain agent and the target domain agent and the migration trigger timestamp, characterized in that: Also includes: The dynamic privacy barrier processing unit (2) replaces the identity identification element with a generalized identifier, outputs a primary desensitization module, deletes the permission control elements and domain-specific elements that violate the regulations in the primary desensitization module according to the data sovereignty rules of the target domain, generates a compliance knowledge module, and finally separates the domain label and the migration trigger timestamp, stores them in the storage area, and performs hash digest processing on the operation type in the migration operation log, retaining only the operation type summary code; The privacy leakage blocking unit (3) performs a secondary check before the compliance knowledge module is transmitted, wherein the primary check is to scan whether the compliance knowledge module has the original identity identification elements remaining, and the secondary check is to verify whether the permission control elements are completely deleted. If the check fails, the cross-domain intelligent agent knowledge transfer is interrupted and a privacy violation event is triggered. If the check passes, the compliance knowledge module is input into the cross-domain intelligent agent knowledge transfer channel.

2. The cross-domain agent knowledge transfer and privacy barrier system according to claim 1, characterized in that: The process of automatically marking the identity elements, permission control elements and domain-specific elements in the original migration module in the migration request parsing and sensitive marking unit (1) is configured with an initial privacy element marking rule, which includes three marking engines working in parallel: The identity tagging engine matches the user ID, device code, and organization authentication string in the original migration module with the pre-loaded cross-domain identity feature library and inserts an identity tag at the identified location; The permission marking engine parses the token declaration statements and role matrix definition blocks in the operation instructions according to the permission syntax tree, and marks the text segments containing access control keywords as permission control elements; The domain tagging engine calls the domain knowledge graph comparison module to identify proprietary terms and data patterns that are strongly related to the source domain, and attaches domain-specific tags.

3. The cross-domain agent knowledge transfer and privacy barrier system according to claim 2, characterized in that: The initial privacy factor tagging rules further include a tagging conflict resolution mechanism. When the same data block is simultaneously tagged with different privacy factor types by multiple tagging engines, an arbitration protocol based on the factor sensitivity level is initiated: Set identity identification elements to the highest sensitivity level, permission control elements to the medium sensitivity level, and domain-specific elements to the basic sensitivity level; If the highest sensitivity level tag overlaps with the basic sensitivity level tag, the data block will be forcibly upgraded to the highest sensitivity level tag, and the conflicting coordinates and arbitration results will be recorded in the migration operation log.

4. The cross-domain agent knowledge transfer and privacy barrier system according to claim 3, characterized in that: The generation process of the migration operation log is executed in conjunction with the marking operation. The logger captures the privacy element type, location coordinates and conflict arbitration records output by the marking engine in real time, and extracts the registration domain label of the source domain agent and the registration domain label of the target domain agent from the knowledge migration request, and embeds the precise timestamp generated by the system clock synchronization, and finally packages it into a structured log object and stores it in a temporary cache area.

5. The cross-domain agent knowledge transfer and privacy barrier system according to claim 1, characterized in that: The process of replacing the identity identification element with the generalized identifier in the dynamic privacy barrier processing unit (2) adopts a hierarchical generalization replacement strategy: The first stage matches the original string covered by the identity marker and selects a replacement template based on its data type; The second stage cleans the replaced strings by domain attributes, removes all modifiers containing source domain characteristics, and generates a generalized identifier without domain specificity. In the third stage, the generalized identifier is backfilled into the corresponding position of the original migration module to form a primary desensitization module.

6. The cross-domain agent knowledge transfer and privacy barrier system according to claim 1, characterized in that: The dynamic privacy barrier processing unit (2) deletes the illegal elements according to the data sovereignty rules of the target domain, deploys a filter driven by the sovereignty rules, loads the privacy compliance terms predefined in the target domain, scans the marked blocks of all permission control elements and domain-specific elements in the primary desensitization module, performs physical deletion on the element blocks that match the illegal terms, and fills the deleted positions with logical placeholders to ensure the integrity of the data structure, thereby generating an intermediate transition module.

7. The cross-domain agent knowledge transfer and privacy barrier system according to claim 6, characterized in that: The sovereign rule-driven filter simultaneously builds a deletion operation traceability chain when generating the compliance knowledge module, recording the type of deleted elements, original location and specific sovereign rule clauses violated; The traceability chain is bound to the metadata segment of the compliance knowledge module in encrypted form and can only be decrypted and viewed using the authorized key when the target domain intelligent device needs to audit the privacy processing process.

8. The cross-domain agent knowledge transfer and privacy barrier system according to claim 1, characterized in that: Separating domain labels and migration trigger timestamps and storing them in the storage area is achieved through the privacy metadata decoupler: The domain labels and timestamps are stripped from the migration operation logs, encrypted and stored in an independently constructed isolated storage area, physically isolated from the cross-domain agent knowledge migration channel; At the same time, the operation type description text in the log is irreversibly hashed to overwrite the operation details field in the original log, forming a desensitized log containing only the operation type summary code.

9. The cross-domain agent knowledge transfer and privacy barrier system according to claim 1, characterized in that: The first level verification process of the privacy leakage blocking unit (3) activates the residual identification deep scanner, which builds detection rules based on the generalized identifier: Check whether there are any ungeneralized original identity strings remaining in the compliance knowledge module, and verify the integrity of the domain attribute cleansing of the generalized identifier. If any violation remains, a privacy violation event will be triggered and the leakage coordinates will be located.

10. The cross-domain agent knowledge transfer and privacy barrier system according to claim 1, characterized in that: The secondary verification process of the privacy leakage blocking unit (3) calls the permission element trace detector, which loads the deletion operation traceability chain recorded by the sovereignty rule-driven filter and performs two-way verification on the compliance knowledge module: The forward verification checks whether all permission control element mark blocks have been deleted or replaced with placeholders, and the reverse verification module checks whether there are permission control statements that are not registered in the traceability chain. If undeleted permission elements or unregistered permission statements are found, the verification is deemed to have failed.

Images