Data security multi-level permission management method and system for question-oriented intelligent agent

Abstract

The application discloses a data security multi-level permission management method and system for question number intelligent agents, and belongs to the technical field of data security. The method comprises the following steps: receiving a natural language query request and user identity information, obtaining permission information, performing permission verification before query, cutting candidate table field metadata when the permission verification is satisfied, and constructing a restricted query space; generating a candidate query statement in the restricted query space, injecting a mandatory permission predicate into a query block directly referencing a basic authorization table and verifying the integrity; performing query after performing granularity control, performing field deletion, mask processing and actual output granularity verification on the result, and outputting controlled result data after passing; updating permission constraints and their versions when the permission definition changes, and keeping the subsequent processing rules consistent. The application prevents unauthorized data contact from the source, cuts off the metadata leakage channel, guarantees the rigidity and integrity of permission control under complex query, and ensures smooth updating of security policies and data consistency.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and more specifically to a multi-level permission management method and system for data security of data-oriented intelligent agents. Background Technology

[0002] In existing technologies, one type of solution focuses on natural language query understanding and query statement generation, while the other type focuses on access control at the database object, field, or record level. The former type of solution typically focuses on the efficiency and accuracy of converting natural language into query statements, while the latter type of solution typically focuses on fine-grained authorization and access restrictions on given data objects.

[0003] However, in enterprise data query scenarios where query-based intelligent agents serve as the core interaction entry point, user input typically manifests as natural language questions rather than pre-constructed query statements. If access control is only implemented after the query statement is generated, issues such as unauthorized query objects being identified, unauthorized fields being included in the reasoning or generation process, and a lack of effective constraints on the granularity of result returns can easily arise. Furthermore, permission rules, field mapping relationships, and queryable structures continuously change during operation, further increasing the complexity of data security governance and collaborative query control.

[0004] Therefore, the existing technology has at least the following shortcomings: First, it lacks a pre-access permission verification mechanism for natural language query entry points; second, it lacks a mechanism for constructing a restricted query space that dynamically converges the query range based on the permission set and constrains subsequent query processing; third, it lacks a governance mechanism that implements differentiated and controlled output based on permission levels during the result return stage; and fourth, it lacks an update mechanism for continuously and synchronously maintaining query constraints after changes in permission rules. Summary of the Invention

[0005] To address the aforementioned technical issues, this invention proposes a multi-level data security permission governance method and system for query-based intelligent agents. This method implements pre-query permission verification, restricted query space construction, constrained query statement processing, and controlled result output during natural language querying. It also establishes a full-link data security governance mechanism covering identity recognition, query generation, query execution, result return, and dynamic updates. This ensures that the same request permission boundary is continuously and uniformly effective across the four levels of pre-query verification, query space construction, query statement generation, and result output, guaranteeing that each subsequent level cannot exceed the authorization scope defined by the preceding level, forming a closed-loop and non-bypass rigid data security defense.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] In a first aspect, embodiments of the present invention provide a multi-level permission governance method for data security for data-sensing agents, comprising the following steps: Receive a natural language query request and user identity information, the natural language query request and user identity information constitute the current request, obtain the permission information corresponding to the current request based on the user identity information, the permission information includes at least the executable operation, the range of accessible data, the range of accessible fields, the allowed output granularity and the permission version; Perform a pre-query permission check on the current request. If the permission conditions are not met, return restriction information. If the permission conditions are met, trim the candidate table field metadata according to the permission information to construct the restricted query space used by the current request. Within the restricted query space, candidate query statements are generated, and mandatory permission predicates are injected into each query block that directly references the base authorization table, and their integrity is verified. Granularity control is performed on the candidate query statement. The controlled output granularity is compared with the allowed output granularity and then the query is executed to obtain the structured query result. The structured query result is then subjected to field deletion, masking, and re-verification of the actual output granularity based on the accessible field range. After the verification is passed, the controlled result data after field control and granularity control is output. When the permission definition changes, update the permission constraints and their versions to ensure that subsequent restricted query space, query statements and output rules remain consistent.

[0008] Furthermore, the specific process of receiving the natural language query request and user identity information is as follows: Receive natural language query requests and identity credentials submitted by users; Parse the identity credentials to extract the user identifier and authentication type; When a valid identity cannot be obtained, the account requires login, or the account is denied access, a restriction message is returned and the request is terminated. When authentication is successful, the natural language query request and standard user context are output.

[0009] Furthermore, the specific process of obtaining the permission information corresponding to the current request based on the user's identity information is as follows: Parse user identity credentials to extract user identifiers, user master data, job role configurations, and connection parameters of existing enterprise permission interfaces; Call the enterprise's existing permission interface to obtain permission data, and merge the executable operation, the scope of the company or region that can be accessed, the scope of the fields that can be accessed, the granularity of the allowed output, and the permission version into a unified permission structure; The system deduplicates and merges the operation permissions and data ranges of valid roles. For multiple valid policies for the same field, it determines the effective policy in the order of deny, mask, and allow, and determines the final accessible data range according to the preset priority rules.

[0010] Furthermore, the specific process of the pre-query permission verification is as follows: Generate standard query objects, standard query ranges, time ranges, indicator fields, and request output granularity from natural language query requests using preset mapping relationships; Compare the standard query object with the range of executable operations and accessible fields, compare the standard query range with the range of accessible data, and compare the requested output granularity with the allowed output granularity.

[0011] Furthermore, the specific process of trimming the candidate table field metadata based on the permission information to construct the restricted query space used by the current request is as follows: Based on the current requested permission information, a copy of the restricted table field metadata is obtained by trimming the candidate table field metadata. The trimming includes deleting inactive tables and tables that are inaccessible to the current user, deleting fields that are denied access, and allowed fields that do not meet the role conditions. Fields that need to be masked retain the field marker and add a mask marker. The restricted table field metadata after trimming is used as the restricted query space, and the query agent does not receive the deleted table field metadata.

[0012] Furthermore, the specific process of generating candidate query statements within the restricted query space and injecting mandatory permission predicates into each query block that directly references the underlying authorization table is as follows: The candidate query statement is parsed into a query syntax structure, and the SELECT node with independent FROM or JOIN data source and condition scope is identified as the query block; For each query block, a parameterized mandatory permission predicate is generated based on the data range of the current request. For each query block that directly references the base authorization table, the mandatory permission predicate is added to the original user conditions of the original query block using a logical AND relationship, and the authorization value is passed using the binding parameter. If the data range specified by the user conditions is a subset of the accessible data range, the data range specified by the user conditions is determined as a valid data range; otherwise, restriction information is returned and the query ends. The outer query, natural language generation conditions, and query repair process do not delete, abandon, or overwrite the mandatory permission predicate.

[0013] Furthermore, the specific process for verifying the integrity of the mandatory permission predicate is as follows: Verify that the candidate query statement is a read-only single-row query, and that the tables and fields used all belong to the restricted query space; Normalize the table aliases, parameter identifiers, operator directions, and logical AND item order to form the expected permission predicate and the actual permission predicate for each query block that directly references the underlying authorization table; Verify that the normalized structure of the actual permission predicate is consistent with that of the corresponding expected permission predicate, and that the authorized value in the actual permission predicate does not exceed the range of valid data, and that there is no logic or bypass that would invalidate the forced permission predicate; The controlled query statement is formed only when all query blocks pass validation; if validation fails, the query execution phase is not initiated.

[0014] Furthermore, granularity control is performed on the candidate query statements. The controlled output granularity is compared with the allowed output granularity before the query is executed to obtain structured query results. Based on the accessible field range, the structured query results undergo field deletion, masking, and re-verification of the actual output granularity. After successful verification, the controlled result data after field and granularity control is output. The specific process is as follows: Compare the output granularity corresponding to the controlled query statement with the allowed output granularity; When the output granularity corresponding to the controlled query statement is finer than the allowed output granularity, the aggregation projection and grouping conditions are reconstructed according to the allowed output granularity before the query is executed to form a granularity-controlled query statement; when the output granularity corresponding to the controlled query statement is not finer than the allowed output granularity, the controlled query statement is directly determined as a granularity-controlled query statement. Execute the granularity-controlled query statement and obtain the structured query results, delete the fields that are denied access, perform predetermined masking processing on the fields with masking marks, and re-verify the actual output granularity after processing; When the actual output granularity is still finer than the allowed output granularity, no query results are output. The controlled result data for the language model to generate the response is separated from the complete structured query results, so that the language model only receives the controlled result data after field control and granularity control are completed.

[0015] Furthermore, the step of updating permission constraints and their versions when permission definitions change, to ensure consistency in subsequent restricted query space, query statements, and output rules, specifically includes: When table permissions, field permissions, data range, or permission definitions at the allowed output granularity change, a bypass update process is triggered to update the corresponding permission constraints and generate a new permission version. The bypass update process does not accept query requests and does not bypass the permission verification before querying; The permission constraint update is performed within a transaction. After the update is successfully committed, subsequent requests that have not yet constructed a restricted query space read the updated permission version and generate a restricted query space, a forced permission predicate, and output rules based on that permission version. If the update fails, roll back and continue using the previous valid version.

[0016] Secondly, embodiments of the present invention provide a multi-level access control system for data security of query agents, employing the method described in the first aspect, the system comprising: The request receiving and permission acquisition module is used to receive natural language query requests and user identity information, wherein the natural language query requests and user identity information constitute the current request, and to acquire permission information corresponding to the current request based on the user identity information. The permission information includes at least the executable operation, the range of accessible data, the range of accessible fields, the allowed output granularity, and the permission version. The pre-query permission verification module is used to perform pre-query permission verification on the current request and determine whether the permission conditions are met. The restricted query space construction module is used to trim the candidate table field metadata according to the permission information when the permission conditions are met, and construct the restricted query space used by the current request. The query statement generation and processing module is used to generate candidate query statements within the restricted query space, inject mandatory permission predicates into each query block that directly references the base authorization table, and verify its integrity. The query execution and result output module is used to perform granular control on the candidate query statement, compare the controlled output granularity with the allowed output granularity, execute the query, obtain the structured query result, and perform field deletion, masking, and re-verification of the actual output granularity of the structured query result according to the accessible field range. After the verification is passed, the controlled result data after field control and granularity control is output. The permission constraint update module is used to update permission constraints and their versions when permission definitions change, so that subsequent restricted query space, query statements and output rules remain consistent.

[0017] The beneficial effects of the above-described technical solutions provided in the embodiments of the present invention include at least the following: This invention performs pre-query permission verification during the natural language understanding stage, using three conditions—data range, field range, and output granularity—as entry thresholds. This directly intercepts non-compliant requests before the query is generated, reducing the possibility of the system accessing unauthorized data.

[0018] This invention constructs a request-level restricted query space, achieving visual isolation at the metadata level. The agent can only query tables and fields within the currently authorized scope, and unauthorized structures and fields are completely invisible to it, thereby cutting off the information leakage channel caused by metadata exposure.

[0019] This invention treats each query block that directly references the base authorization table as an independent security unit, injects parameterized mandatory permission predicates into each block and performs normalized signature verification on a block-by-block basis, ensuring that the entire query is rejected when any branch lacks permission conditions or has a bypass structure, so that permission control remains rigid and complete in complex queries.

[0020] This invention enforces a reduction in output granularity before query execution and performs field deletion, masking, and granular final verification on the result set after execution. The language model can only receive controlled result data after desensitization and convergence, thus building a data security barrier in the final stage.

[0021] This invention uses a permission version number mechanism to ensure that after each permission change, new requests automatically use the updated constraints to construct restricted spaces, permission predicates, and output rules, while requests that have already entered the execution process continue to use the old version, thus guaranteeing the smoothness of security policy updates and data consistency. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0023] Figure 1 This is a flowchart of a multi-level permission governance method for data security of a query-oriented intelligent agent provided in an embodiment of the present invention.

[0024] Figure 2 This is a structural diagram of a data security multi-level permission governance system for query-oriented intelligent agents provided in an embodiment of the present invention. Detailed Implementation

[0025] 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.

[0026] Example 1: To address the issues that query agents may access unauthorized metadata before generating queries, may miss data range constraints in complex query statements, and may output overly fine-grained data during the result return stage, this invention uses the permission information corresponding to the current request as the unified control basis, and sequentially implements permission verification before querying, construction of a restricted query space, processing of permission constraints for query statements, and controlled output of results.

[0027] The multi-level permissions referred to in this invention mean that the same request permission boundary is continuously effective at four processing levels: the query entry level is used to determine whether the query object and query scope meet the permission conditions; the query space level is used to trim the table field metadata visible to the query agent; the query statement level is used to inject mandatory permission predicates into the query blocks of each base table and verify their integrity; and the result output level is used to restrict the returned fields and result granularity. All four levels are associated with the same permission version, and the subsequent level must not expand the authorization boundary determined by the previous level.

[0028] Specifically, such as Figure 1 As shown, this embodiment of the invention discloses a multi-level permission governance method for data security of query-based intelligent agents, including the following steps: S1. Receives a natural language query request and identity credentials, and parses the user identifier and authentication type. If a valid identity cannot be obtained, the account requires login, or the account access is denied, it returns a restriction message and terminates; otherwise, it outputs the query request and standard user context.

[0029] S2. Based on the standard user context, read the user master data, role configuration, and existing permission interface data, and normalize them to form the current request permission information, which includes executable operations, accessible data range, accessible field range, allowed output granularity, and permission version. Field policies are decided in the order of deny, mask, and allow; if a valid data range cannot be formed, it is set to empty.

[0030] S3. Identify the query object, query scope, time, indicators, and request output granularity from the query request, and compare them with the current request permission information. If any comparison fails or the data range is empty, return the corresponding restriction information and end; if a required element is missing, return the element to be completed; if all elements are satisfied, output the verified query elements.

[0031] S4. Copy and trim the candidate table field metadata according to the current requested permission version, delete inaccessible tables and fields, and add tags to fields that need to be masked, forming a restricted query space that can only be used for this request. Query object selection, feature mapping, and query statement generation all only accept this restricted query space.

[0032] S5. Generate candidate query statements within the restricted query space. Parse the candidate statements into query blocks such as the main query, common table expressions, subqueries, and set query branches. Inject parameterized mandatory permission predicates into each query block that directly references the base authorization table. Normalize expected and actual predicates, verify the existence of predicates, the range of authorization values, and logical OR bypasses block by block, and verify the read-only nature of the statements and the whitelist of table fields; if any verification fails, do not proceed with query execution.

[0033] S6. Compare the output granularity of the controlled query statement output in the previous step with the allowed output granularity. When the output granularity is finer than the allowed output granularity, reconstruct the aggregation projection and grouping conditions before query execution to form a granularity-controlled query statement; when the output granularity is not finer than the allowed output granularity, directly determine the controlled query statement as a granularity-controlled query statement. Execute the granularity-controlled query statement, pass the authorization range value through binding parameters, obtain the structured query results, and record the permission version used by the query statement. Terminate execution if the database returns an error; error handling must not delete or relax the mandatory permission predicate.

[0034] S7. Based on the field permission policy corresponding to the current request, delete the denied fields from the structured query results, perform predefined masking processing on the masked access fields, and retain the allowed fields. Re-verify the granularity of the processed actual output; if the actual output granularity is finer than the allowed output granularity, do not output the query results to the user or language model; if the verification passes, only provide the controlled result data after field and granularity control to the user or language model, and the request ends after the output is completed.

[0035] Step S8: When the permission definition changes, a bypass update process is triggered. The permission definition includes table permissions, field permissions, data range, and allowed output granularity. The bypass update process does not accept query requests and does not bypass the permission check before querying.

[0036] Specifically, the permission constraints are updated and a new permission version is generated within the transaction. After a successful update commit, subsequent requests that have not yet constructed a restricted query space read the new version; if the update fails, it is rolled back and the previous valid version is reused.

[0037] The following is a detailed description of the data security multi-level permission management method for query-oriented intelligent agents of the present invention: In practice, this invention typically meets the following conditions when implemented in specific application scenarios: users submit query requests via natural language; different users correspond to different data access ranges or field access ranges; the query agent needs to determine the authorization boundaries of the current request before generating the query statement; and the permission rules, field mapping relationships, or queryable structures may continuously change during operation.

[0038] Step S1: Receive query request and user identity information: Receive natural language query request and identity certificate, obtain user identifier from identity certificate, and read user status, job role, company and region information.

[0039] Step S2: Obtain the permission information corresponding to the current request: The natural language query request and the user identity information constitute the current request. Based on the user identity information, obtain the permission information corresponding to the current request. The permission information includes at least the executable operation, the range of accessible data, the range of accessible fields, the allowed output granularity, and the permission version.

[0040] Specifically, identity credentials, user master data, job role configurations, and permission data provided by the existing permission system will be unified into request-level permission information.

[0041] Permission data is obtained from identity credentials, user master data, job role configuration and adaptation interfaces of the enterprise's existing permission system, and arrays, separator values ​​and wildcard ranges are unified into a unified permission structure. The operation permissions and data ranges of valid roles are deduplicated and merged; for multiple valid policies on the same field, the effective policy is determined in the order of deny, mask, and allow. During the permission merging process, as a preferred implementation method, when both specific company scopes and regional scopes exist, the specific company scope is used first; if no specific company scope exists, the regional scope is then mapped to a set of companies. As a preferred implementation method, when there is a conflict between manual role configuration and automatic job matching results, the manual configuration is retained.

[0042] When the job position is not matched, mutually exclusive roles are matched, or the data source for non-administrator users' permissions is unavailable, the accessible data range will be set to empty, and the data will be processed as not meeting the permission conditions during the permission check before querying.

[0043] Permission information includes the operations that can be performed, the scope of companies or regions that can be accessed, the scope of fields that can be accessed, the granularity of allowed output, and the permission version.

[0044] Step S3: Perform pre-query permission verification and determine if permission conditions are met: Utilize field aliases, company and region mappings, time and business object mappings to generate a standard query object, standard query range, time range, indicator fields, and request output granularity from the natural language query request. Compare the standardized query object with the executable operations and field ranges, the query range with the accessible data range, and the request output granularity with the allowed output granularity. If any comparison fails, return restriction information containing the restriction type and end the process; if necessary elements such as company, time, or indicator are missing, return the elements to be completed; if all conditions are met, output the verified query elements and permission version.

[0045] Step S4: Construct a restricted query space: The restricted query space is a copy of the request-level metadata obtained by copying and trimming the metadata from the candidate table fields according to the current request permission information.

[0046] Once the permission conditions are met, copy the candidate table field metadata and perform pruning based on the current permission version. Pruning includes: deleting disabled tables and tables inaccessible to the current user; deleting fields that are denied access and allowed fields for which role conditions are not met; and retaining the field identifier for fields that require masking while attaching a mask tag.

[0047] The pruning results form the restricted query space for the current request. This restricted query space is shared for query object selection, feature mapping, and query statement generation. The query agent does not receive metadata of the deleted table fields.

[0048] Step S5: Generate and process query statements within the restricted query space: Generate candidate query statements only within the restricted query space. Parse the candidate query statements into query syntax structures, identify SELECT nodes with independent FROM or JOIN data sources and condition scope as query blocks, and identify query blocks in the main query, common table expressions, subqueries, and set query branches that directly reference the underlying authorization table.

[0049] Generate parameterized mandatory permission predicates based on the scope of accessible data currently requested; for each query block that directly references the underlying authorization table, append mandatory permission predicates with logical AND relationships in addition to the original user conditions of the query block, and pass authorization values ​​using binding parameters.

[0050] When the data range specified by the user conditions is a subset of the accessible data range, the data range specified by the user conditions is determined as a valid data range; when the data range specified by the user conditions is not a subset of the accessible data range, restriction information is returned and the query is terminated.

[0051] The outer query, natural language generation conditions, and query repair process must not delete, relax, or cover mandatory permission predicates.

[0052] Subsequently, the read-only structure, object whitelist, and query block permission predicate integrity verification are executed sequentially; if the actual predicate is missing, the authorized value is out of range, or there is logic or bypass, no executable controlled query statement is formed.

[0053] Verify that the candidate query statement is a read-only single-row query, and verify that all table fields used belong to the restricted query space; perform normalization on table aliases, parameter identifiers, operator directions, and logical AND item order, forming expected permission predicates and actual permission predicates for each query block that directly references the base authorization table; verify that the normalized structure signature of the actual permission predicate is consistent with the corresponding expected permission predicate, that the authorization values ​​in the actual permission predicate do not exceed the valid data range, and that there is no logic or bypass that would invalidate the mandatory permission predicate; only when all query blocks pass the verification is a controlled query statement formed, and if the verification fails, the query is not executed.

[0054] Step S6: Implement pre-execution granularity control for controlled query statements, execute granularity controlled query statements and obtain results: compare the output granularity corresponding to the controlled query statement with the allowed output granularity; When the output granularity of the controlled query statement is finer than the allowed output granularity, the aggregation projection and grouping conditions are reconstructed according to the allowed output granularity before the query is executed, thus forming a granularity-controlled query statement. When the output granularity of a controlled query statement is not finer than the allowed output granularity, the controlled query statement is directly identified as a granularity-controlled query statement. Execute granularized query statements and obtain structured query results; Only execute queries that complete permission verification and granular control, and record their permission versions.

[0055] Step S7: Process the results according to the field permission policy, verify the actual output granularity, and output in a controlled manner. When the permission definition changes, update the permission constraints and their versions, and allow subsequent requests that have not yet constructed a restricted query space to read the updated permission constraints. After obtaining the structured query results, delete the denied access fields, perform pre-defined processing on the mask fields, and verify the actual output granularity again. If the actual output granularity is still finer than the allowed output granularity, do not output the query results. The controlled result data for the language model to generate responses is separated from the complete structured query results; the language model only receives the controlled result data after field control and granularity control have been completed.

[0056] Step S8: When the definitions of table permissions, field permissions, data range, or allowed output granularity change, update the corresponding permission constraints within the transaction and generate a new permission version. After the update is complete, subsequent requests that have not yet constructed a restricted query space will read the new version and generate the restricted query space, query block forced permission predicate, and output rules using the same version; the update does not replace pre-query permission verification, nor does it directly trigger query execution.

[0057] Specifically, the query pre-validation conditions, restricted query space, mandatory permission predicates for query blocks, and result output rules are derived sequentially from the same request-level permission information. Mandatory permission predicates are injected and validated for each query block that directly references the base authorization table to prevent common table expressions, subqueries, or set query branches from bypassing the data scope. Furthermore, the controlled result data provided to the language model undergoes field and granular control. Permission merging, role rollback, specific masking methods, and permission constraint updates serve as supporting mechanisms for the aforementioned main process.

[0058] To further clarify the mathematical logic of the key decision conditions, data range constraints, and permission rules involved in the above steps, the formal definitions and decision rules used in this invention are explained below: For ease of description, the key variables used in the subsequent determination rules are defined with the following symbols: For the current user, For natural language query requests, This is the permission information currently being requested. Metadata for candidate table fields.

[0059] ; in, A set of executable operations. For the range of accessible data, This is the set of field permission policies corresponding to the current request. These policies include allow access, masked access, and deny access. To allow for output granularity, This is the authorized version. The restricted query space is obtained by trimming candidate metadata from the current request permission information: ; in, For the restricted query space, Crop is a pruning function that, based on the permission information corresponding to the current request, deletes tables that the current user cannot access and fields that are denied access to, and adds mask markers to fields that need to be masked; the pruning result forms a restricted query space that can only be used by the current request, and query object selection, feature mapping, and query statement generation only accept the restricted query space.

[0060] Determining the query range and handling query block permissions.

[0061]

[0062] in, The range of data specified for a natural language query request. This represents the range of valid data allowed to be used to generate the query statement after passing the pre-query permission check; symbol This indicates that the permission verification failed. When the query scope exceeds the limit, return the restriction information and terminate the query, without constructing a restricted query space or generating a query statement.

[0063] ; in, For query block The query conditions are generated based on the user's query requirements; Based on the valid data range The generated parameterized enforced permission predicate; symbols To enforce the use of a logical AND relation between the permission predicate and the user's query conditions, if the user does not specify other query conditions, ... It is considered a tautological condition.

[0064] Candidate query statements The query block set directly references the underlying authorization table, and each query block has an independent data source and condition scope. The query block permission verification rules are expressed as follows: ; in, For query block Based on the valid data range The expected mandatory permission predicates should be included; For query blocks after permission injection is completed The actual mandatory permission predicates extracted from the query do not include the time, metrics, and other business filtering conditions specified in the user's query request. This is a predicate structure signature formed after standardizing the permission fields, table aliases, operators, parameter identifiers, and logical structures. This is the set of authorized values ​​bound in the actual enforced permission predicate. For query block There exists a logical or bypass mechanism or other structure that can invalidate the mandatory permission predicate. The structure in question does not exist. This is only true if the candidate query is a read-only single-row query, and the tables and fields used are within the restricted query space, and... Only then is a controlled query statement formed. If any verification condition is not met, the query execution phase will not proceed.

[0065] Controlled output results: ; ; in, This refers to a controlled query statement that passes read-only structure verification, restricted query space whitelist verification, and permission predicate integrity verification. To compare the output granularity of controlled query statements with the allowed output granularity When the output granularity is finer than the allowed output granularity, the aggregation projection and grouping conditions of the query statement are reconstructed before query execution to form a granularity-controlled query statement. When the output granularity is not finer than the allowed output granularity, maintain the original query structure and let .

[0066] To obtain structured query results by executing granularity-controlled query statements; Based on the set of field permission policies The system removes the denied access field, performs predefined masking on the masked access field, and retains the allowed access field, thus forming the final controlled output. Verify again before outputting. The actual output granularity is determined. If the actual output granularity is finer than the allowed output granularity, the query results will not be output to the user or the language model.

[0067] All the above formulas use the current request permission information. Same permission version in .

[0068] The following two examples illustrate the multi-level permission management method for data security of the present invention for query-oriented intelligent agents: I. Joint control of regional permissions and output granularity: The following uses the energy consumption table T_energy_consumption in the project as an example to illustrate the end-to-end processing. This table includes at least the fields stat_date, region_code, region_name, company_code, company_name, and water_qty.

[0069] The user permission context is as follows: the role is a regional administrator; company codes JX001 and JX002 are allowed, corresponding to Jiangxi Example Company 1 and Jiangxi Example Company 2 respectively; allowed fields are company_code, company_name, stat_date, and water_qty; the maximum output permission level is L2, and the maximum allowed granularity is company daily level; the user does not have data access permissions for Zhejiang company codes ZJ001 and ZJ002.

[0070] The user's query is to retrieve detailed water consumption data for all companies in Jiangxi and Zhejiang provinces in June 2026. The target table is T_energy_consumption, the metric field is water_qty, the time range is June 1, 2026 to June 30, 2026, the requested region includes Jiangxi and Zhejiang, and the requested output granularity is the raw data.

[0071] Pre-query permission verification maps the company candidates in the question to a set of companies in Jiangxi. Together with Zhejiang Company Then combine with the authorized company Comparison. The Zhejiang region does not belong to the authorized company set, and the original detailed granularity is finer than the daily company level allowed by L2; therefore, this request does not meet the permission conditions. The returned restriction types are query scope exceeding permissions and output granularity being too fine, terminating this request, without constructing a restricted query space or generating a query statement. The user resubmits the query for the daily water consumption of each company in Jiangxi in June 2026 based on the restriction information; the identified query scope is... The requested output granularity is at the company daily level, and the permission verification passed before querying.

[0072] The restricted query space only retains the energy consumption table and the `company_code`, `company_name`, `stat_date`, and `water_qty` fields; the mandatory permission predicate is `company_code IN (:authorized_company_1,:authorized_company_2)`, with binding parameters JX001 and JX002 respectively; the maximum output granularity is `company_day`. If the candidate SQL contains a CTE or a subquery, all query blocks that directly read the energy consumption table must include this predicate.

[0073] The query statement generated by permission injection and based on the allowed output granularity is as follows: SELECT company_name, stat_date,SUM(water_qty) AS daily_water_qty FROMT_energy_consumption WHERE company_code IN (:authorized_company_1,:authorized_company_2) AND stat_date>= :start_date AND stat_date<:end_dateGROUP BY company_name, stat_date ORDER BY company_name, stat_date. In the binding parameters, start_date is 2026-06-01 and end_date is 2026-07-01.

[0074] During the query generation and processing phase, it was confirmed that the query was a single SELECT query, all fields were located in the restricted query space, and the query block reading the base table contained complete company permission predicates and no OR bypass was present. The final output did not include Zhejiang companies, did not return original record-level details, but instead returned a daily water consumption summary for authorized companies in Jiangxi, sorted by company and date. The audit log included user ID, permission version, original query, identification scope, rejected scope, output granularity control action, actual executed SQL, bound parameter summary, base table, and query time.

[0075] II. Multi-query block forced permission predicate injection: When a candidate SQL statement contains both a daily-level public table expression (daily_scope) and a monthly-level public table expression (monthly_scope), and both public table expressions directly read the underlying authorization table T_energy_consumption, the two public table expressions are registered as query blocks that require company permission predicates, without omitting permission checks because the outer query only references the public table expression name.

[0076] The source code is as follows: WITH daily_scope AS (SELECT company_code, company_name, stat_date ASperiod_start, SUM(water_qty) AS water_qty, 'DAY' AS granularity FROM T_energy_consumption WHERE company_code IN (:authorized_company_1, :authorized_company_2) AND stat_date>= :start_date AND stat_date<:end_date GROUP BYcompany_code, company_name, stat_date), monthly_scope AS (SELECT company_code, company_name, DATE_TRUNC('month', stat_date) AS period_start, SUM(water_qty) AS water_qty, 'MONTH' AS granularity FROM T_energy_consumptionWHERE company_code IN (:authorized_company_1, :authorized_company_2) ANDstat_date>= :start_date AND stat_date<:end_date GROUP BY company_code, company_name, DATE_TRUNC('month', stat_date)) SELECT company_code, company_name, period_start, water_qty, granularity FROM daily_scope UNION ALL SELECT company_code, company_name, period_start, water_qty, granularity FROM monthly_scope.

[0077] In the source code above, the expected predicates of `daily_scope` and `monthly_scope` are compared with the actual predicates during the query generation and processing phases, respectively. Only when both query blocks contain company authorization set binding parameters, neither has an OR bypass, and the authorization value does not exceed... Only queries with an outer UNION ALL clause are allowed to execute; if any query block is missing a predicate, the entire SQL returns a permission predicate incomplete error.

[0078] Example 2: like Figure 2 As shown, based on the same inventive concept, embodiments of the present invention also provide a multi-level access control system for data security for query-based intelligent agents, the system comprising: The request receiving and permission acquisition module is used to receive natural language query requests and user identity information, wherein the natural language query requests and user identity information constitute the current request, and to acquire permission information corresponding to the current request based on the user identity information. The permission information includes at least the executable operation, the range of accessible data, the range of accessible fields, and the allowed output granularity. The pre-query permission verification module is used to perform pre-query permission verification on the current request and determine whether the permission conditions are met. The restricted query space construction module is used to trim the candidate table field metadata according to the permission information when the permission conditions are met, and construct the restricted query space used by the current request. The query statement generation and processing module is used to generate candidate query statements within the restricted query space, inject mandatory permission predicates into each query block that directly references the base authorization table, and verify its integrity. The query execution and result output module is used to perform granular control on the candidate query statement, compare the controlled output granularity with the allowed output granularity, execute the query, obtain the structured query result, and perform field deletion, masking, and re-verification of the actual output granularity of the structured query result according to the accessible field range. After the verification is passed, the controlled result data after field control and granularity control is output. The permission constraint update module is used to update permission constraints and their versions when permission definitions change, so that subsequent restricted query space, query statements and output rules remain consistent.

[0079] Since these systems and the principles they address are similar to the aforementioned multi-level access control method for data security oriented intelligent agents, the implementation of this system can refer to the implementation of the aforementioned method, and the repetitions will not be repeated.

[0080] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0081] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A multi-level access control method for data security of query-based intelligent agents, characterized in that, Includes the following steps: Receive a natural language query request and user identity information, the natural language query request and user identity information constitute the current request, obtain the permission information corresponding to the current request based on the user identity information, the permission information includes at least the executable operation, the range of accessible data, the range of accessible fields, the allowed output granularity and permission version; Perform a pre-query permission check on the current request, and return restriction information if the permission conditions are not met; When the permission conditions are met, the candidate table field metadata is trimmed according to the permission information to construct the restricted query space used by the current request; Within the restricted query space, candidate query statements are generated, and mandatory permission predicates are injected into each query block that directly references the base authorization table, and their integrity is verified. Granularity control is performed on the candidate query statement. The controlled output granularity is compared with the allowed output granularity and then the query is executed to obtain the structured query result. The structured query result is then subjected to field deletion, masking, and re-verification of the actual output granularity based on the accessible field range. After the verification is passed, the controlled result data after field control and granularity control is output. When the permission definition changes, update the permission constraints and their versions to ensure that subsequent restricted query space, query statements and output rules remain consistent.

2. The method as described in claim 1, characterized in that, The specific process of receiving natural language query requests and user identity information is as follows: Receive natural language query requests and identity credentials submitted by users; Parse the identity credentials to extract the user identifier and authentication type; When a valid identity cannot be obtained, the account requires login, or the account is denied access, a restriction message is returned and the request is terminated. When authentication is successful, the natural language query request and standard user context are output.

3. The method as described in claim 1, characterized in that, The specific process for obtaining the permission information corresponding to the current request based on the user's identity information is as follows: Parse user identity credentials to extract user identifiers, user master data, job role configurations, and connection parameters of existing enterprise permission interfaces; Call the enterprise's existing permission interface to obtain permission data, and merge the executable operation, the scope of the company or region that can be accessed, the scope of the fields that can be accessed, the granularity of the allowed output, and the permission version into a unified permission structure; The system deduplicates and merges the operation permissions and data ranges of valid roles. For multiple valid policies for the same field, it determines the effective policy in the order of deny, mask, and allow, and determines the final accessible data range according to the preset priority rules.

4. The method as described in claim 1, characterized in that, The specific process of pre-query permission verification is as follows: Generate standard query objects, standard query ranges, time ranges, indicator fields, and request output granularity from natural language query requests using preset mapping relationships; Compare the standard query object with the range of executable operations and accessible fields, compare the standard query range with the range of accessible data, and compare the requested output granularity with the allowed output granularity.

5. The method as described in claim 1, characterized in that, The specific process of trimming the candidate table field metadata based on the permission information and constructing the restricted query space used by the current request is as follows: Based on the current requested permission information, a copy of the restricted table field metadata is obtained by trimming the candidate table field metadata. The trimming includes deleting inactive tables and tables that are inaccessible to the current user, deleting fields that are denied access, and allowed fields that do not meet the role conditions. Fields that need to be masked retain the field marker and add a mask marker. The restricted table field metadata after trimming is used as the restricted query space, and the query agent does not receive the deleted table field metadata.

6. The method as described in claim 1, characterized in that, The specific process of generating candidate query statements within the restricted query space and injecting mandatory permission predicates into each query block that directly references the base authorization table is as follows: The candidate query statement is parsed into a query syntax structure, and the SELECT node with independent FROM or JOIN data source and condition scope is identified as the query block; For each query block, a parameterized mandatory permission predicate is generated based on the data range of the current request. For each query block that directly references the base authorization table, the mandatory permission predicate is added to the original user conditions of the original query block using a logical AND relationship, and the authorization value is passed using the binding parameter. If the data range specified by the user conditions is a subset of the accessible data range, the data range specified by the user conditions is determined as a valid data range; otherwise, restriction information is returned and the query ends. The outer query, natural language generation conditions, and query repair process do not delete, abandon, or overwrite the mandatory permission predicate.

7. The method as described in claim 1, characterized in that, The specific process for verifying the integrity of the mandatory permission predicate is as follows: Verify that the candidate query statement is a read-only single-row query, and that the tables and fields used all belong to the restricted query space; Normalize the table aliases, parameter identifiers, operator directions, and logical AND item order to form the expected permission predicate and the actual permission predicate for each query block that directly references the underlying authorization table; Verify that the normalized structure of the actual permission predicate is consistent with that of the corresponding expected permission predicate, and that the authorized value in the actual permission predicate does not exceed the range of valid data, and that there is no logic or bypass that would invalidate the forced permission predicate; The controlled query statement is formed only when all query blocks pass validation; if validation fails, the query execution phase is not initiated.

8. The method as described in claim 1, characterized in that, The process of performing granular control on the candidate query statement, comparing the controlled output granularity with the allowed output granularity, executing the query, obtaining structured query results, and then performing field deletion, masking, and re-verification of the actual output granularity based on the accessible field range, is as follows: After successful verification, the controlled result data after field control and granularity control is output. Compare the output granularity corresponding to the controlled query statement with the allowed output granularity; When the output granularity of the controlled query statement is finer than the allowed output granularity, the aggregation projection and grouping conditions are reconstructed according to the allowed output granularity before the query is executed, thus forming a granularity-controlled query statement. When the output granularity corresponding to the controlled query statement is not finer than the allowed output granularity, the controlled query statement is directly determined as a granularity-controlled query statement. Execute the granularity-controlled query statement and obtain the structured query results, delete the fields that are denied access, perform predetermined masking processing on the fields with masking marks, and re-verify the actual output granularity after processing; When the actual output granularity is still finer than the allowed output granularity, no query results are output. The controlled result data for the language model to generate the response is separated from the complete structured query results, so that the language model only receives the controlled result data after field control and granularity control are completed.

9. The method as described in claim 1, characterized in that, The process of updating permission constraints and their versions when permission definitions change, ensuring consistency in subsequent restricted query space, query statements, and output rules, specifically includes: When table permissions, field permissions, data range, or permission definitions at the allowed output granularity change, a bypass update process is triggered to update the corresponding permission constraints and generate a new permission version. The bypass update process does not accept query requests and does not bypass the permission verification before querying; The permission constraint update is performed within a transaction. After the update is successfully committed, subsequent requests that have not yet constructed a restricted query space read the updated permission version and generate a restricted query space, a forced permission predicate, and output rules based on that permission version. If the update fails, roll back and continue using the previous valid version.

10. A multi-level access control system for data security for query-based intelligent agents, characterized in that: The system comprises: The request receiving and permission acquisition module is used to receive natural language query requests and user identity information, wherein the natural language query requests and user identity information constitute the current request, and to acquire permission information corresponding to the current request based on the user identity information. The permission information includes at least the executable operation, the range of accessible data, the range of accessible fields, the allowed output granularity, and the permission version. The pre-query permission verification module is used to perform pre-query permission verification on the current request and determine whether the permission conditions are met. The restricted query space construction module is used to trim the candidate table field metadata according to the permission information when the permission conditions are met, and construct the restricted query space used by the current request. The query statement generation and processing module is used to generate candidate query statements within the restricted query space, inject mandatory permission predicates into each query block that directly references the base authorization table, and verify its integrity. The query execution and result output module is used to perform granular control on the candidate query statement, compare the controlled output granularity with the allowed output granularity, execute the query, obtain the structured query result, and perform field deletion, masking, and re-verification of the actual output granularity of the structured query result according to the accessible field range. After the verification is passed, the controlled result data after field control and granularity control is output. The permission constraint update module is used to update permission constraints and their versions when permission definitions change, so that subsequent restricted query space, query statements and output rules remain consistent.

Images