A cross-domain agent knowledge transfer and privacy barrier system

Abstract

The present application relates to the technical field of data privacy protection, in particular to a cross-domain intelligent agent knowledge migration and privacy barrier system, which comprises a migration request analysis and sensitive marking unit, extracts an original migration module and marks an identity, controls the authority and domain-specific elements, generates an operation log containing domain labels and time stamps, a dynamic privacy barrier processing unit replaces the identity with a generalized identifier, generates a compliant knowledge module according to the target domain sovereignty rules by deleting illegal elements, separates and encrypts the storage of domain labels and time stamps, performs hash processing on the log operation type, and a privacy leakage blocking unit scans the residual identity and non-deleted authority elements through two-level verification, and inputs the compliant module into the migration channel after verification, which realizes accurate desensitization and compliance verification of cross-domain knowledge migration, prevents privacy leakage, and ensures the safety of cross-domain collaboration of intelligent agents.

Description

Technical Field

[0001] This invention relates to the field of data privacy protection technology, and more specifically, to a cross-domain intelligent agent knowledge transfer and privacy barrier system. Background Technology

[0002] Data privacy protection is an important technology. With the increasingly widespread application of multi-domain intelligent agent collaboration, the ability to share the capabilities of intelligent agents in different domains 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 domain and provides support for intelligent collaboration across industries and scenarios. 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 suffer from core problems of incomplete privacy protection and insufficient compliance. Traditional solutions fail to accurately identify and process sensitive elements such as identity identifiers and access control in the transferred knowledge, and simply using desensitization methods can easily lead to the retention of original privacy information. At the same time, they lack a dynamic adaptation mechanism for the data sovereignty rules of the target domain, and the transfer module may contain content that violates the regulations of the target domain. Furthermore, the lack of an effective secondary verification step can easily lead to the risk of privacy leakage. These problems combined make cross-domain knowledge transfer subject to compliance disputes, which not only harms the rights and interests of data subjects but also restricts the large-scale application of intelligent agent cross-domain collaboration, making it difficult to meet the stringent requirements for data security and privacy protection. 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 this invention is to provide a cross-domain intelligent agent knowledge transfer and privacy barrier system to solve the problems mentioned in the background art.

[0005] 1. Because traditional solutions fail to accurately identify and process sensitive elements in the transferred knowledge, simple desensitization can easily lead to the retention of privacy information. Therefore, this case study constructs a knowledge element graph to mark sensitive levels and generates an encrypted migration package, which can completely eliminate the risk of privacy information leakage.

[0006] 2. Since traditional solutions lack dynamic adaptation to the data sovereignty rules of the target domain, they are prone to compliance disputes. Therefore, this case study generates an adaptation strategy by parsing the rules of the target domain and performs secondary verification on the migration package to ensure that the knowledge transfer meets the compliance requirements of the target domain.

[0007] To achieve the above objectives, a cross-domain intelligent agent knowledge transfer and privacy barrier system is provided, including a migration request parsing and sensitivity marking unit. When a source domain intelligent agent initiates a knowledge transfer request to a target domain intelligent agent, the system extracts the original migration module from the request, automatically marks the identity identification elements, access control elements, and domain-specific elements in the original migration module, and generates a migration operation log containing domain tags of the source and target domain intelligent agents and a migration trigger timestamp. The system is characterized by further comprising:

[0008] The dynamic privacy barrier processing unit replaces identity elements with generalized identifiers, outputs a primary desensitization module, deletes the access 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 migration trigger timestamp, stores them in the storage area, and performs hash digest processing on the operation types in the migration operation log, retaining only the operation type digest code.

[0009] The privacy leakage blocking unit performs a two-level verification before the compliance knowledge module is transmitted. The first-level verification scans whether the compliance knowledge module retains any original identity elements, and the second-level verification verifies whether the access 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.

[0010] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0011] 1. Through three parallel tagging engines, based on cross-domain identity feature library, permission syntax tree and domain knowledge graph, the system accurately locates identity identifiers, access control and domain-specific elements in the original migration module, and resolves tagging conflicts through a sensitivity level arbitration mechanism to ensure that no sensitive elements are missed. The dynamic privacy barrier processing unit further adopts a layered generalized replacement strategy to replace identity identifiers with generalized identifiers without domain orientation. Combined with the sovereignty rule-driven filter, it deletes permissions and domain elements that violate the target domain regulations, and fills in logical placeholders to ensure the integrity of the data structure, completely eliminating the risk of privacy information residue caused by simple desensitization.

[0012] 2. The first-level verification of the privacy leakage blocking unit uses a residual identifier deep scanner to detect the existence of un-de-identified original identity information based on generalized identifier rules, ensuring the thoroughness of identity de-identification. The second-level verification calls the permission element trace detector and combines the deletion operation trace chain to verify whether the permission elements have been completely deleted, avoiding omissions of illegal permission statements. Once the verification fails, the system immediately interrupts the migration and triggers a violation event, blocking the privacy leakage path from a technical perspective. At the same time, the deletion operation trace chain is bound to the compliance knowledge module in encrypted form, which can only be audited by authorized parties, satisfying compliance traceability requirements while preventing the traceability information itself from becoming a new privacy risk point. Attached Figure Description

[0013] Figure 1 This is an overall block diagram of the present invention.

[0014] The meanings of the labels in the diagram are as follows:

[0015] 1. Migration request parsing and sensitive labeling unit; 2. Dynamic privacy barrier processing unit; 3. Privacy leakage blocking unit. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] This invention provides a cross-domain intelligent agent knowledge transfer and privacy barrier system. Please refer to [link / reference]. Figure 1 As shown, it includes a migration request parsing and sensitivity marking unit 1. When the source domain agent initiates a knowledge migration request to the target domain agent, it extracts the original migration module in the request, automatically marks the identity elements, access control elements and domain-specific elements in the original migration module, and generates a migration operation log, which includes the domain tags of the source domain agent and the target domain agent and the migration trigger timestamp.

[0018] The process of automatically marking identity elements, access control elements, and domain-specific elements in the original migration module in the migration request parsing and sensitive marking unit 1 is configured with initial privacy element marking rules, which include three marking engines working in parallel:

[0019] 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 identification location;

[0020] The permission tagging engine parses the token declaration statement and role matrix definition block in the operation instruction based on the permission syntax tree, and marks the text segment containing access control keywords as permission control elements;

[0021] The domain tagging engine calls the domain knowledge graph comparison module to identify proprietary terms and data patterns strongly related to the source domain, and attaches domain-specific tags, as explained below:

[0022] When a source domain agent initiates a knowledge transfer request to a target domain agent, the transfer request parsing and sensitive labeling unit 1 first starts the extraction process of the original transfer module. Specifically, by parsing the protocol format of the request data packet, it locates the payload field that carries the knowledge content, extracts the original transfer module containing information such as algorithm model, decision rules, and data features, and stores it according to data type to prepare for subsequent sensitive element labeling.

[0023] The initial privacy element labeling rules further include a labeling conflict resolution mechanism. When the same data block is simultaneously labeled as different privacy element types by multiple labeling engines, an arbitration protocol based on the element sensitivity level is initiated.

[0024] Set the identity identification elements to the highest sensitivity level, the access control elements to the medium sensitivity level, and the domain-specific elements to the basic sensitivity level.

[0025] If the highest sensitivity level marker overlaps with the basic sensitivity level marker, the data block will be forcibly upgraded to the highest sensitivity level marker, and the conflict coordinates and arbitration results will be recorded in the migration operation log.

[0026] Based on this, the unit uses three parallel labeling engines to accurately identify and label sensitive elements according to the initial privacy element labeling rules. The specific working process of each engine is as follows:

[0027] For the identity tagging engine, its core is to achieve accurate matching through a pre-loaded cross-domain identity feature library. This library contains identity templates common to multiple domains, such as the "prefix + numeric sequence" format of user IDs (e.g., "user_001"), manufacturer-specific encoding rules for device codes (e.g., "SN-XXX-XXXX"), and certificate format features of organization authentication strings (e.g., X.509 format containing "CN=" and "O="). During recognition, the engine uses a combination of feature template matching and regular expression validation.

[0028] First, the strings in the original migration module are compared with templates from the feature library to filter out candidate fields that are suspected of being identity identifiers. Then, regular expressions (such as "^user_\d+$" for user ID) are used for secondary verification. After confirmation, identity identifier markers (such as "^user_\d+$") are inserted at the beginning and end of the field.<id>< / id> For example, inserting markers at both ends of "user_001" results in "". <id> user_001< / id> This clearly marks sensitive elements while preserving the original location information of the fields;

[0029] The permission tagging engine relies on the permission syntax tree for structured parsing. The permission syntax tree is an abstract syntax tree model built according to the syntax rules of the access control domain. It includes node types such as the "keyword + parameter" structure of token declaration statements (e.g., "granttoken:read on resource:A") and the "role-permission" mapping relationship of role matrix definition blocks (e.g., "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 syntax rules, traverses the tree for nodes containing the access control keywords "grant", "revoke", "role", and "perm", and locates their corresponding text segments; then, it marks these text segments as permission control elements, for example, adding "" to "granttoken:read on resource:A". <perm>< / perm> "Tags ensure that complete access control logic units are covered, avoiding missed detections due to fragmented tags;

[0030] The domain labeling engine identifies specific elements by calling the domain knowledge graph comparison module. The domain knowledge graph contains core concepts, terminological relationships, and data patterns of the source domain. The comparison module employs a dual judgment mechanism of "concept similarity + pattern matching degree."

[0031] First, the semantic similarity between terms in the module and core concepts of the source domain in the knowledge graph is calculated to filter out terms with high similarity. Then, it is checked whether the data structure matches the unique patterns of the source domain. Combining the results of both methods, specialized terms and data patterns strongly related to the source domain are identified. Finally, domain-specific markers (such as "...") are added to these elements. <dom>< / dom> For example, "ICD-10:I21.9" in the medical field is marked as "". <dom> ICD-10: I21.9< / dom> This approach precisely identifies domain-specific information. When the three tagging engines work in parallel, they synchronize tagging progress in real time through shared memory, ensuring that the scan of the original migration module is thorough and complete. This multi-engine collaborative tagging method leverages the advantages of each engine in identifying specific sensitive elements while improving tagging efficiency through parallel processing. It provides accurate sensitive element location data for subsequent dynamic privacy barrier processing, making privacy protection targeted and comprehensive from the outset.

[0032] The initial privacy element labeling rules further include a labeling conflict resolution mechanism. When the same data block is simultaneously labeled as different privacy element types by multiple labeling engines, an arbitration protocol based on the element sensitivity level is initiated.

[0033] During the process of three parallel labeling engines labeling sensitive elements in the original migration module, some data blocks may simultaneously possess characteristics of multiple sensitive elements (such as device authentication strings containing user IDs, which are both identity identifiers and may be associated with domain-specific formats). This can lead to the same data block being labeled as different types by multiple engines. Therefore, the initial privacy element labeling rules further include a labeling conflict resolution mechanism to ensure the uniqueness and accuracy of sensitive element labeling.

[0034] When the same data block is simultaneously marked as different privacy element types by multiple marking engines, the system will automatically initiate an arbitration protocol based on the element sensitivity level.

[0035] The determination of "the same data block being marked by multiple marking engines simultaneously": The system compares the marking coordinates output by each engine with the start and end indices of the data block. If the coordinate overlap of two or more marking engines exceeds 80%, meaning that most of the content of a data block is marked by two engines simultaneously, it is determined to be a marking conflict. For example, in the 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, with an overlap of 90%, thus triggering the conflict mechanism. The specific meaning of "different privacy element types" refers to any combination of two or more of the following: identity elements, access control elements, and domain-specific elements, such as "identity + access control", "identity + domain-specific", and "access control + domain-specific". The arbitration protocol based on element sensitivity level is a set of judgment rules that prioritizes based on the degree of risk of sensitive element leakage. It arbitrates conflict markers through preset sensitivity levels to ensure that high-risk elements are marked accurately first. The determination of element sensitivity level is mainly based on the degree of harm that may be caused after element leakage. Identity elements are directly associated with the unique identity of an individual or organization. Leakage will lead to the precise location of the privacy subject, which is the highest risk. Access control elements involve access permission configuration. Leakage may lead to unauthorized operations, which is the second highest risk. Domain-specific elements only reflect the characteristics of a specific domain. The scope of impact of leakage is limited, which is the lowest risk. Based on the above, the system sets identity elements to the highest sensitivity level (level 3), access control elements to the medium sensitivity level (level 2), and domain-specific elements to the basic sensitivity level (level 1). This setting aligns with the core logic of data privacy protection, where identity information is the bottom line for privacy protection, while also taking into account the risks of differences in permissions and domain information. When a tag conflict occurs, the system arbitrates according to the following logic:

[0036] Extract all tag types and their sensitivity levels corresponding to conflicting data blocks, compare the levels, and uniformly tag the data blocks with the highest-level feature type. If the highest sensitivity level tag (level 3) overlaps with the basic sensitivity level tag (level 1) (e.g., identity elements conflict with domain-specific elements), then it is forcibly upgraded to the highest sensitivity level tag. For example, in a hospital's equipment code "MED-SN-001 (Department: Cardiology)", "MED-SN-001" is tagged by the identity tagging engine (level 3), while "Department: Cardiology" is tagged by the domain tagging engine (level 1), with an overlap of 85%. The system determines that the highest sensitivity level overlaps with the basic sensitivity level, and ultimately tags the entire data block as an identity element and inserts "...". <id>< / id>The system will record the conflict coordinates, conflict type and arbitration result in detail in the migration operation log, providing a traceable basis for subsequent audits. Through this conflict resolution mechanism, it can avoid the omission of desensitization due to chaotic marking, and ensure that high-risk sensitive elements are processed first. This makes the sensitive marking of the original migration module both accurate and in line with the core requirements of privacy protection, laying a reliable foundation for the subsequent operation of the dynamic privacy barrier processing unit 2.

[0037] The migration operation log generation process is executed in conjunction with the tagging operation. The log recorder captures the privacy element type, location coordinates, and conflict arbitration records output by the tagging engine in real time. At the same time, it extracts the registered domain tags of the source domain agent and the target domain agent from the knowledge migration request, embeds the precise timestamp generated by the system clock synchronization, and finally packages them into a structured log object and stores it in a temporary cache area.

[0038] After completing the marking of sensitive elements and conflict resolution, to ensure the traceability and transparency of the knowledge transfer process, the generation of the migration operation log must be executed in conjunction with the marking operation, forming a real-time closed loop of "marking-recording". This linkage mechanism is achieved by establishing a data interaction channel between the logger, the marking engine, and the conflict arbitration module: when the identity marking engine inserts an identity identifier, the logger immediately captures the privacy element type and location coordinates of the operation; when the permission marking engine and the domain marking engine complete the marking, the logger synchronously collects the corresponding information in the same way. If the marking conflict resolution mechanism is triggered, the logger will also capture the conflict coordinates (such as the index range of overlapping data blocks "0x0050-0x0078") and the arbitration result (such as upgrading to the highest sensitivity level marking) in real time, ensuring that every marking operation and conflict handling is recorded immediately, avoiding the loss of log information due to delays. At the same time, the logger needs to extract the registered domain tags of the source domain agent and the target domain agent from the knowledge transfer request. The specific process is as follows:

[0039] The system parses the request's metadata fields (e.g., in HTTP-based requests, 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 format of "domain type + institution code" (e.g., "medical domain_310001" represents a medical domain agent of a medical institution in Shanghai, and "financial domain_110002" represents a financial domain agent of a financial institution in Beijing). After extraction, the system performs format validation on the labels, verifying whether they contain the underscore ("_") separating the "domain type" and "institution code". If the format is incorrect, a request format error message is 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 (e.g., "2024-05-20"). 15:30:22.123”, and packaged information such as privacy element type, location coordinates, conflict arbitration record, source / target domain label, timestamp, etc. into a structured log object in JSON format (e.g., {"timestamp":"2024-05-2015:30:22.123","source_domain":"medical_domain_310001","target_domain":"financial_domain_110002","elements":[{"type":"identity element","coordinates":"0x0023-0x0045"},{"type":"domain-specific element","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 to provide a data source for the subsequent separation of domain labels and timestamps by the dynamic privacy barrier processing unit 2. This makes the entire log system not only support privacy protection but also a key link connecting the tagging operation and subsequent processing steps.

[0040] Its characteristic is that it further includes:

[0041] The dynamic privacy barrier processing unit 2 replaces the identity identification elements with generalized identifiers, outputs a primary desensitization module, deletes the access 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 migration trigger timestamp, stores them in the storage area, and performs hash digest processing on the operation types in the migration operation log, retaining only the operation type digest code.

[0042] After the migration request parsing and sensitive labeling unit 1 completes the labeling of sensitive elements, the dynamic privacy barrier processing unit 2 needs to de-identify the identity elements. This is done by replacing them with generalized identifiers using a hierarchical generalization replacement strategy. The reason for this phased implementation is threefold: the first phase ensures accurate location and initial replacement of identity elements, avoiding information distortion caused by indiscriminate processing; the second phase removes domain attributes, eliminating domain-specificity in cross-domain migration; and the third phase achieves accurate backfilling of de-identified information, ensuring the integrity of the module structure. These three phases progress step-by-step, ensuring both thorough de-identification and data usability.

[0043] The process of replacing identity elements with generalized identifiers in the dynamic privacy barrier processing unit 2 adopts a layered generalized substitution strategy:

[0044] The first stage matches the original string covered by the identity identifier and selects a replacement template based on its data type. The core of this stage is to select an appropriate replacement rule based on the type characteristics of the identity identifier. The specific process is as follows:

[0045] The system scans the original migration module for identifiers (such as "..."). <id>< / id> The text segment containing the identifiers (e.g., "user_001", "SN-2023-005", "CN=a hospital, O=medical system") is extracted. The string type is determined using predefined type identification rules. User IDs typically contain a "user_" prefix followed by a numeric sequence; device codes often include "SN-" or "DEV-" identifiers combined with a date / serial number; and organization authentication strings follow the X.509 format (including "CN=" and "O=" fields). The corresponding generalized template is called for each type. User IDs use a prefix + random identifier..." The template uses an alphanumeric combination (replacing "user_001" with "usr_8F3D7"), the device code uses a "general identifier + last 6 digits of hash value" template (replacing "SN-2023-005" with "Dev-7A2C91"), and the organization authentication string uses a "role identifier + anonymized organization code" template (replacing "CN=a hospital, O=medical system" with "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 the direct exposure of the original identity information.

[0046] The second stage involves cleaning the replaced string by removing all modifiers containing source domain features, generating a generalized identifier without domain specificity. The string after the first stage of replacement may still retain source domain features (such as the "MED-" prefix in medical device coding), therefore, domain specificity needs to be eliminated through domain attribute cleaning. The specific process is as follows:

[0047] The system retrieves the registration information of the source domain agent (e.g., obtaining "Medical Domain_310001" from the migration operation log), loads the domain-specific feature library (containing the "MED-" and "HOSP-" prefixes for the medical domain, and the "BANK-" and "TRANS-" identifiers for the financial domain), scans the replaced string, and removes modifiers containing source domain features. For example, in the medical domain, "usr_MED_8F3D7" needs to have "MED_" removed, becoming "usr_8F3D7", and in the financial domain, "Dev_BANK_7A2C9" needs to be replaced. 1. The string "BANK_" needs to be deleted, becoming "Dev_7A2C91". The cleaned string needs to be standardized (e.g., all letters are uppercase, and the number of digits is fixed) to ensure it doesn't contain any features that could be associated with the source domain. This results in a domain-neutral identifier. The core of domain attribute cleaning is severing the association between the identifier and the source domain, preventing the inference of original domain information through feature words, and adding a layer of protection for privacy and security during cross-domain migration. After generating the identifier, it needs to be accurately restored to the corresponding position in the original migration module to ensure the integrity of the module structure. The specific process is as follows:

[0048] The third stage involves backfilling the generalized identifier into the corresponding position in the original migration module, forming a primary desensitization module. The location coordinates of the identity elements (starting byte index "0x0023", ending byte index "0x0045") are retrieved from the migration operation log to determine the area to be replaced. The generalized identifier ("usr_8F3D7") generated in the second stage is written into the position corresponding to the original marker coordinates, overwriting the original identity string. After backfilling, the module's syntax structure is scanned. If a format error occurs due to replacement, placeholders are automatically added, ultimately forming the 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 statement. This preserves the necessary information structure for subsequent compliance processing based on the sovereignty rules of the target domain, enabling the primary desensitization module to meet privacy protection requirements and provide the basic conditions for further processing.

[0049] After completing the generalization processing of identity elements and generating the primary desensitization module, to ensure that the knowledge module migrated across domains complies with the security specifications of the target domain, the dynamic privacy barrier processing unit 2 deploys a sovereignty rule-driven filter to perform compliance processing on access control elements and domain-specific elements according to the data sovereignty rules of the target domain. This process is a key step in achieving knowledge migration and adaptation to the rules of the target domain. It can both prevent illegal information from entering the target domain and ensure the usability of the module through structured processing. The data sovereignty rules of the target domain refer to the normative clauses formulated by the organization or industry to which the intelligent agent belongs regarding data access, privacy protection, and the scope of information use. These rules cover prohibited access types, restricted cross-domain domain-specific information, and data format specifications. These rules are stored in the form of parsable structured documents, containing three levels of clauses: "prohibited items," "restricted items," and "allowed items." Violation elements refer to the content in the access control elements or domain-specific elements in the primary desensitization module that matches the "prohibited items" or "restricted items" of the data sovereignty rules of the target domain. 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, according to the rules of the target domain, performs compliance processing on access control elements and domain-specific elements according to the rules of the target domain. The operation of deleting non-compliant elements according to the data sovereignty rules of the target domain involves deploying a sovereign rule-driven filter. This filter loads predefined privacy compliance clauses of the target domain, scans all access control elements and domain-specific element marker blocks in the primary de-identification module, performs physical deletion on element blocks matching the non-compliant clauses, and simultaneously fills logical placeholders at the deletion locations to ensure data structure integrity, generating an intermediate transition module. Based on the operation logic of deleting non-compliant elements according to the data sovereignty rules of the target domain, the sovereign rule-driven filter transforms the target domain rules into detection conditions, locates the non-compliant elements in the module and performs deletion, while maintaining the data structure through placeholders to ensure the coherence of subsequent processing. When generating the compliance knowledge module, the sovereign rule-driven filter simultaneously builds a deletion operation traceability chain, recording the type, original location, and specific sovereign rule clauses violated by the deleted elements.

[0050] This traceability chain is bound in encrypted form to the metadata segment of the compliance knowledge module. It can only be decrypted and viewed using an authorized key when the target domain intelligent device needs to audit the privacy processing. This reveals the specific process of the sovereign rule driver:

[0051] The filter first retrieves the privacy compliance clauses corresponding to the registered domain tags of the target domain agent from the system rule base, parsing them into a triple structure containing "rule ID - detection keyword - processing method" (e.g., rule ID:001, detection keyword: "grant root permission", processing method: "physical deletion"; rule ID:002, detection keyword: "medical domain case code", processing method: "physical deletion"). Simultaneously, to improve matching accuracy, the filter converts the natural language descriptions in the clauses into regular expressions (e.g., "prohibit the input of medical records containing patient IDs" is converted to "^.*patientID"). Medical records. $”, forming a rule set that can be directly used for scanning. The filter traverses the primary desensitization module and identifies the access control element marker (“$”). <perm>< / perm> ") and domain-specific element markers (" <dom>< / dom> The filter precisely locates the marked blocks of two types of elements, recording the start and end coordinates of each block (e.g., the coordinates of the permission block are "0x0120-0x0150", and the coordinates of the domain-specific block are "0x0200-0x0230"). For marked blocks nested in complex data structures, the filter parses the hierarchical relationship ("the permission block is located under the 'user_config' node") to ensure no omissions in the location. 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.

[0052] If the permission control block contains statements that match "grant root permission", "revoke all restrictions", and "prohibited items", it is considered a permission violation. If a domain-specific block contains core terms from the source domain and the target domain rules explicitly prohibit such information (e.g., the financial domain rule "prohibits receiving medical gene data"), it is considered a domain violation. During the matching process, the filter records the matched rule ID, block coordinates, and specific violation text, forming a violation list. For 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, to avoid the deletion operation from damaging the module's data structure, logical placeholders with the same format as the original block are filled at the deletion position. If the deleted item is a permission declaration statement (such as "..."), the filter will not delete it. <perm> Grant root privileges< / perm> If ), then fill in "". <perm> [Compliance Adjustment: Permission statements have been removed]< / perm> If the deleted data block is a domain-specific data block, then fill in "". <dom> [Compliance Adjustment: Domain Data Has Been Removed]< / dom>The placeholders both mark the deletion operation and ensure the integrity of the module's syntax. After processing all violations, the filter performs overall syntax validation on the module, such as verifying tag closure through an XML parser and checking function structure through a code compiler. If there are syntax errors caused by deletion, they are automatically corrected, and finally, an intermediate transition module is generated. This process not only reflects respect for the data sovereignty of the target domain, but also avoids knowledge invalidation caused by "excessive deletion" through structured processing, achieving a balance between security and usability in cross-domain knowledge transfer.

[0053] During the process of generating compliance knowledge modules using the sovereign rule-driven filter, to ensure the traceability of the privacy processing and prevent the traceability information itself from becoming a new privacy risk point, the system simultaneously constructs a deletion operation traceability chain. This mechanism forms a closed loop with the deletion operation of the violation element, satisfying both compliance audit requirements and ensuring data security. When the filter executes the physical deletion operation of each violation element, it simultaneously triggers the traceability information collection mechanism, specifically recording three core items: the type of the deleted element: clearly identifying whether it is an access 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 start and end byte indices in the module (e.g., "0x0120-0x0150"), and associated with the hierarchical structure of this location in the original migration module (e.g., "located as the 3rd sub-item under the 'Permission Configuration' node"). The specific sovereign rule clause violated:

[0054] The system records the matched rule ID and clause content ("Rule ID: 001, Clause: Prohibit receiving statements containing super administrator privileges"). This information is sorted by timestamp, forming raw traceability data record by record. The collected raw traceability data is encapsulated into a structured traceability chain in JSON format. Each record contains the fields "Operation Timestamp - Element Type - Location Coordinates - Violation Clause". The structured processing ensures the traceability chain is readable and parsable, facilitating quick 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, while the private key is stored as an authorization key by the administrator of the target domain agent and is only enabled during audits. The encrypted traceability chain exists in ciphertext form and cannot be parsed by conventional means. The encrypted traceability chain is embedded in the metadata segment of the compliance knowledge module, i.e., the description information area of ​​the module header, and is marked with a special tag. <trace>< / trace> "Define the storage location, for example, record it as '" in the module metadata. <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 a target domain agent needs to audit the privacy processing procedure to verify whether there is excessive deletion or omission of non-compliant elements, the traceability chain information must be obtained through the following steps:

[0055] The administrator submits an authorization request containing the private key to the system. The system verifies the permissions by checking whether the ciphertext encrypted with the public key can be decrypted by the private key. Only after successful verification is access to the traceability chain allowed. The system extracts the encrypted traceability chain from 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 reason for violation for each deletion operation. The audit process itself is recorded in the system log, including the audit time, operator, and summary of the traceability chain content viewed, ensuring that the audit behavior is traceable and preventing the abuse of the authorized key. 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 handling capabilities but also verifiable compliance endorsement, providing end-to-end protection for the secure implementation of cross-domain knowledge migration.

[0056] After the sovereign rule-driven filter generates a compliance knowledge module and constructs a deletion operation traceability chain, to further reduce the risk of privacy leakage during cross-domain transmission, the dynamic privacy barrier processing unit 2 separates and de-identifies sensitive metadata in the migration operation log through a privacy metadata decoupler. This process ensures the secure storage of core privacy information while retaining the operation traceability function of the log, forming a dual protection of "sensitive information isolation + 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 through preset field identifiers. For example, from the log object {"source_domain":"medical_domain_310001","target_domain":"financial_domain_110002","timestamp":"2024-05-2015:30:22.123",...}, the contents of the three fields are accurately extracted to form independent metadata fragments. The logic behind the stripping operation is that domain labels directly relate to the domain to which the agent belongs, while timestamps may indirectly reveal the temporal patterns of migration behavior. Both are sensitive metadata that requires strict protection and should not be transmitted with the main log file. The decoupler employs an innovative encryption strategy of "symmetric encryption + hash verification": first, the stripped metadata fragments are symmetrically encrypted using the AES-256 algorithm, with the key dynamically generated by the system and bound to the target domain identity to generate encrypted ciphertext; then, the ciphertext is hashed using SHA-256 to generate a verification value. For example, encrypting "Medical Domain_310001|Financial Domain_110002|2024-05-20 15:30:22.123" yields the ciphertext "j8F3...x9L2", with a hash verification value of "a7d2...f1c5". This layered encryption ensures that metadata content is not leaked and verifies whether the ciphertext has been tampered with during storage through checksums. The system divides the physical server into independent, isolated storage areas, using different hard drive partitions than the cross-domain knowledge migration channel, and disables direct data interaction between the two. The decoupling unit writes the encrypted ciphertext and hash checksum into this storage area through a dedicated interface and creates an index, with the index key serving as a unique identifier for the compliant 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 severs the association between sensitive metadata and the migration channel at the hardware level, avoiding the risk of leakage during transmission. The decoupling unit traverses the fields recording operation content in the migration operation log and extracts the natural language description text ("Mark identity elements and trigger conflict arbitration", "Delete illegal access control elements").These texts contain specific operational logic. If they are directly retained, they may leak the system's privacy processing rules. Therefore, they need to be desensitized and transformed. An irreversible transformation method of "semantic normalization + salt hashing" is adopted to separate the domain label and migration trigger timestamp and store them in the storage area through a privacy metadata decoupler.

[0057] Domain tags and timestamps are stripped from the migration operation logs, encrypted, and stored in an independently constructed isolated storage area, which is physically isolated from the cross-domain intelligent agent knowledge migration channel;

[0058] Simultaneously, the operation type description text in the log is subjected to irreversible hash transformation, overwriting the operation detail field in the original log, forming a de-identified log containing only the operation type digest code:

[0059] First, the operation description text is semantically normalized, unifying synonyms into standard expressions (e.g., "delete" and "remove" are unified as "delete") to ensure consistent formatting for descriptions of the same operation. Then, random salt values ​​are generated (each operation type corresponds to a unique salt value, such as "s@Lt_01" for "mark operation"). The normalized text is concatenated with the salt value, and a hash value is calculated using the SHA-512 algorithm to form a fixed-length operation type digest code. For example, after normalizing "delete violation access control element" and concatenating the salt value "s@Lt_02", the digest code "7f83...a2b1" is calculated. The introduction of salt values ​​ensures that even with identical text, different operation types will have different digest codes, enhancing the uniqueness and collision resistance of the hash results. The decoupler uses the calculated operation type digest code to overwrite the original "operation_details" field content in the log, while retaining other non-sensitive fields in the log, ultimately forming a desensitized log. For example, in the original log, "operation_details": "Delete illegal access control elements" is replaced with "operation_hash": "7f83...a2b1". The anonymized log only reflects the existence of the operation and cannot deduce the specific operation content. This satisfies the need for operation traceability while avoiding the leakage of privacy processing logic. Through the above operations of the privacy metadata decoupling device, sensitive information in the migration operation log is completely stripped and anonymized. Domain tags and timestamps are securely stored through "encryption + physical isolation", and operation details are eliminated from the risk of information leakage through irreversible hash transformation. This process, as the final step in the dynamic privacy barrier processing, not only continues the precise processing logic of sensitive elements mentioned above, but also provides a closed-loop guarantee for the metadata security of cross-domain knowledge migration through innovative encryption and isolation methods. This ensures that the entire privacy barrier system can achieve a balance between privacy protection and compliance throughout the "processing-recording-storage" process.

[0060] Privacy leakage blocking unit 3 performs a two-level verification before the compliance knowledge module is transmitted. The first-level verification scans whether the compliance knowledge module retains any original identity elements, and the second-level verification verifies whether the access 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.

[0061] After the dynamic privacy barrier processing unit 2 completes the generation of the compliance knowledge module and the anonymized storage of related metadata, in order to ensure that the generalization processing of identity elements is thorough and residue-free, the privacy leakage prevention unit 3 initiates the first-level verification process. The first-level verification process of the privacy leakage prevention unit 3 enables the residual identifier deep scanner, which constructs detection rules based on the generalized identifier:

[0062] The system matches whether there are any ungeneralized original identity strings remaining in the compliance knowledge module and verifies the completeness of the domain attribute cleaning of the generalized identifier. If any violation remains, a privacy violation event is triggered and the leakage coordinates are located. This step 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 activate a residual identifier deep scanner. This scanner first constructs a dual detection rule based on the generalized identifier features generated by the dynamic privacy barrier processing unit 2: First, it extracts the format template of the generalized identifier (such as "usr_ + 6-digit alphanumeric combination" for user ID and "Dev_ + 6-digit hash value" for device code) as a benchmark for judging whether the string has undergone compliant generalization; Second, it establishes a reverse matching library of source domain identity features, containing typical features of ungeneralized original identity strings (such as the "user_ + number" prefix for user ID and the "SN- + date" format for device code). During verification, the scanner will traverse the full text of the compliance knowledge module byte by byte. First, it checks whether all strings containing identity identifier features conform to the format template of the generalized identifier through the forward matching rule. For example, "user_002" appearing in the module 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 scanner compares the prefix and structure of the string for features. If it finds text that is highly similar to the original identity identifier in the source domain ("SN-2023-006" is consistent with the encoding format of the ungeneralized device), it is directly judged as a residual risk. In terms of verifying the completeness of the domain attribute cleaning of the generalized identifier, the scanner will extract the text content of each generalized identifier and compare it 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 judged as incomplete domain attribute cleaning because it contains the source domain feature "MED-". If any of the above checks finds the violation residue, whether it is the existence 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 alarm module. At the same time, with the help of the built-in coordinate positioning function of the module, the scanner accurately marks the start and end byte index of the violation content in the compliance knowledge module, providing precise guidance for subsequent problem investigation. This verification process, through both forward and reverse detection logic, ensures the thoroughness of identity generalization and verifies the integrity of domain attribute cleaning. 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.

[0063] After completing the first-level verification to ensure that no identity elements remain, Privacy Leakage Prevention Unit 3 immediately initiates the second-level verification. The second-level verification process of Privacy Leakage Prevention Unit 3 involves calling the Permission Element Trace Detector, which loads the deletion operation trace chain recorded by the Sovereign Rule-Driven Filter to perform two-way verification on the Compliance Knowledge Module.

[0064] The forward verification process checks whether all access control element marker blocks have been deleted or replaced with placeholders. The reverse verification module checks for access control statements not registered in the traceability chain. If any undeleted access control elements or unregistered access control statements are found, the verification fails, focusing on the completeness of access control element processing. This step, together with the deletion operation of the sovereign rule-driven filter in the dynamic privacy barrier processing unit 2, forms a closed-loop verification, further strengthening the privacy protection network. Specifically, the system calls the access control element trace detector, which first extracts the deletion operation traceability chain ciphertext generated by the sovereign rule-driven filter from the metadata segment of the compliance knowledge module. After decryption using the authorization key of the target domain, it parses out the type, original location coordinates, and corresponding sovereign rule clauses of the deleted access control elements, using this as the verification benchmark. In the forward verification phase, the detector locates the corresponding positions in the compliance knowledge module one by one according to the access control element marker block coordinates recorded in the traceability chain, checking whether the content in that area has been physically deleted or replaced with preset logical placeholders (such as "..."). <perm> [Compliance Adjustment: Permission statements have been removed]< / perm>For example, if the traceability chain shows that a certain coordinate once contained the permission control element "grantadmin permission", the detector will verify whether the original statement is no longer present at that location, or whether it has been replaced by a placeholder. If the original statement is found to have been neither deleted nor replaced, it will be directly marked as a verification anomaly. This process ensures that all permission elements that should be deleted are properly handled, avoiding the retention of illegal content due to omissions. 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 the coordinates of a permission-related text segment are not found in the traceability chain, it is determined to be an "unregistered permission control statement". For example, if the module contains "revoke user read", it will be considered an unregistered permission control statement. The presence of a "permission" statement, but with no corresponding deletion or retention record in the traceability chain, indicates that the statement may not have undergone compliance checks by the sovereign rule-driven filter, posing a potential risk. If forward verification detects an undeleted permission element, or reverse verification detects an unregistered permission statement, the detector immediately determines that the secondary verification has failed, thus interrupting the cross-domain knowledge transfer process and triggering a privacy violation event. Simultaneously, the system log records the violation location, content, and verification failure type in detail, providing precise clues for subsequent investigation. Through bidirectional verification (forward and reverse), the permission element trace detector ensures that "what should be deleted has been deleted" and prevents "unreviewed retention," forming a logical closed loop with the aforementioned permission element marking and deletion operations. This makes the processing of permission control elements fully controllable and verifiable, adding another crucial layer of protection for the compliance of cross-domain intelligent agent knowledge transfer.

[0065] In this invention, the migration request parsing and sensitive marking unit 1 extracts the original migration module and marks it with identity identifiers, access control, and domain-specific elements, generating an operation log containing domain tags and timestamps. The dynamic privacy barrier processing unit 2 replaces the identity identifiers with generalized identifiers, deletes non-compliant elements according to the target domain sovereignty rules to generate a compliant knowledge module, separates and encrypts the domain tags and timestamps, hashes the log operation types, and the privacy leakage blocking unit 3 scans for residual identity identifiers and undeleted permission elements through secondary verification. After the verification is passed, the compliant module is input into the migration channel. This system achieves accurate desensitization and compliance verification for cross-domain knowledge migration, prevents privacy leakage, and ensures the security of cross-domain collaboration of intelligent agents.

[0066] The foregoing has shown and described 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 embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A cross-domain intelligent agent knowledge transfer and privacy barrier system, characterized in that, The system includes a migration request parsing and sensitivity marking unit (1). When a source domain agent initiates a knowledge migration request to a target domain agent, it extracts the original migration module from the request, automatically marks the identity elements, access control elements, and domain-specific elements in the original migration module, and generates a migration operation log containing the domain tags of the source and target domain agents and the migration trigger timestamp. The process of automatically marking the identity elements, access 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 parallel marking engines: 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 identification location; The permission tagging engine parses the token declaration statement and role matrix definition block in the operation instruction based on the permission syntax tree, and marks the text segment 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 attach domain-specific tags. The initial privacy element labeling rules further include a labeling conflict resolution mechanism. When the same data block is simultaneously labeled as different privacy element types by multiple labeling engines, an arbitration protocol based on the element sensitivity level is initiated. Set the identity identification elements to the highest sensitivity level, the access control elements to the medium sensitivity level, and the domain-specific elements to the basic sensitivity level. If the highest sensitivity level label overlaps with the basic sensitivity level label, the data block will be forcibly upgraded to the highest sensitivity level label, and the conflict coordinates and arbitration results will be recorded in the migration operation log. This also includes: The dynamic privacy barrier processing unit (2) replaces the identity identification element with the Panhua identifier, outputs the 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 the 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 digest code; The privacy leakage blocking unit (3) performs a second-level verification before the compliance knowledge module is transmitted. The first-level verification is to scan whether the original identity identification elements remain in the compliance knowledge module, 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.

2. The cross-domain intelligent agent knowledge transfer and privacy barrier system according to claim 1, characterized in that: The generation process of the migration operation log is executed in conjunction with the tagging operation. The log recorder captures the privacy element type, location coordinates and conflict arbitration records output by the tagging engine in real time. At the same time, it extracts the registered domain tags of the source domain agent and the target domain agent from the knowledge migration request, 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.

3. The cross-domain intelligent agent knowledge transfer and privacy barrier system according to claim 1, characterized in that: The process of replacing identity elements with generalized identifiers in the dynamic privacy barrier processing unit (2) adopts a layered generalized replacement strategy: The first stage involves matching the original string covered by the identity identifier marker and selecting a replacement template based on its data type. The second stage involves cleaning the replaced string by removing all modifiers that contain features of the source domain, and generating a generalized identifier without domain orientation. The third stage involves backfilling the generalized identifiers into the corresponding positions of the original migration modules to form the primary desensitization module.

4. The cross-domain intelligent agent knowledge transfer and privacy barrier system according to claim 1, characterized in that: The dynamic privacy barrier processing unit (2) deletes non-compliant elements according to the data sovereignty rules of the target domain. It deploys a sovereignty rule-driven filter, which loads the privacy compliance clauses 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 non-compliant clauses, and fills logical placeholders at the deletion positions to ensure the integrity of the data structure, and generates an intermediate transition module.

5. The cross-domain intelligent agent knowledge transfer and privacy barrier system according to claim 4, characterized in that: The sovereign rule-driven filter simultaneously constructs a deletion operation traceability chain when generating the compliance knowledge module, recording the type, original location, and specific sovereign rule clauses violated by the deleted element. This traceability chain is bound to the metadata segment of the compliance knowledge module in encrypted form, and can only be decrypted and viewed with an authorized key when the target domain smart device needs to audit the privacy processing.

6. The cross-domain intelligent 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 a privacy metadata decoupler. Domain tags and timestamps are stripped from the migration operation logs, encrypted, and stored in an independently constructed isolated storage area, which is physically isolated from the cross-domain intelligent 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 de-identified log containing only the operation type digest code.

7. The cross-domain intelligent 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) enables the residual identifier deep scanner, which constructs detection rules based on generalized identifiers: The system checks whether any ungeneralized original identity strings remain in the compliance knowledge module and verifies the completeness of the domain attribute cleansing of the generalized identifier. If any violation remains, a privacy violation event is triggered and the leak coordinates are located.

8. The cross-domain intelligent 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 trace chain recorded by the sovereignty rule-driven filter to perform two-way verification on the compliance knowledge module: The forward verification checks whether all permission control element marker blocks have been deleted or replaced with placeholders. The reverse verification module checks whether there are permission control statements that are not registered in the traceability chain. If any permission elements that have not been deleted or permission statements that have not been registered are found, the verification is deemed to have failed.

Images