Intelligent agent tool calling authority control system based on terminal user identity

Abstract

The invention relates to the technical field of identity verification, and particularly discloses a terminal user identity-based agent tool calling permission control system, which comprises a receiving module for receiving a tool calling request initiated by a terminal user; the processing module is used for acquiring real-time user attributes from the user attribute service based on the user identity identification; the user identity identification and the real-time user attribute are combined to form a dynamic permission context; the matching module is used for establishing an authority strategy database based on original strategy data collected from a plurality of strategy data sources, inputting the dynamic authority context into the authority strategy database for rule matching, and outputting an authority judgment result; and the control module is used for executing corresponding tool calling control operation according to the permission judgment result. According to the method, the calling process of the agent tool is safer and more transparent and has dynamic adaptive capacity, and the compliance and risk prevention and control capacity of an enterprise in a sensitive business scene are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of identity verification technology, and more specifically to an intelligent agent tool access control system based on end-user identity. Background Technology

[0002] Existing intelligent agent systems suffer from a serious flaw: the separation between access control and the actual user's identity when invoking external tools. Once an intelligent agent is granted tool access, all users with access to that agent can use all its functions equally, making it impossible to differentiate control based on the actual user's identity.

[0003] When users with different access levels access sensitive tools through the same agent, the system only identifies the agent's identity but cannot distinguish the specific operator behind it. This allows lower-privilege users to indirectly gain higher-privilege operational capabilities. This privilege amplification effect exposes enterprise data assets to unauthorized access risks, makes internal compliance requirements difficult to implement, and renders security boundaries ineffective. Furthermore, because permission assessment lacks the ability to perceive real-time user attributes (such as department, job level, and geographical location), dynamic, fine-grained access control cannot be achieved, creating significant security vulnerabilities when agents handle sensitive business processes. Summary of the Invention

[0004] The purpose of this invention is to provide a smart agent tool access control system based on end-user identity, thereby solving the above-mentioned technical problems.

[0005] The objective of this invention can be achieved through the following technical solutions: A smart agent tool access control system based on end-user identity includes: Receiving module: Receives tool call requests initiated by end users. The tool call requests include user identification. Processing module: Based on user identity, obtain real-time user attributes from user attribute service. Real-time user attributes include user department, user job level, and user geographical location. The user identity identifier is combined with the real-time user attributes to form a dynamic permission context. The dynamic permission context is a structured data object containing user identity fields and real-time user attribute fields. Matching module: Based on the collection of raw policy data from multiple policy data sources to build a permission policy database, the dynamic permission context is input into the permission policy database for rule matching, and the permission determination result is output. Control module: Executes corresponding tool call control operations based on the permission determination result.

[0006] As a further aspect of the present invention: the step of obtaining real-time user attributes includes: Send the user's identity identifier to the user attribute service; By querying the user attribute database through the user attribute service, the user's department, job level, and geographical location corresponding to the user's identity identifier can be obtained; The acquired user department, user job level, and user geographical location are combined to form real-time user attributes; Specifically, when the corresponding user department, user rank, or user geographical location does not exist in the user attribute database, the user department and / or user rank and / or user geographical location that do not exist in the user attribute database are obtained from the backup data source and used as substitutes to generate real-time user attributes.

[0007] As a further aspect of the present invention, the step of forming a dynamic permission context includes: Extract the user's unique identifier from the user's identity document; The initial data is obtained by combining the user's unique identifier with the user's department, job level, and geographical location from the real-time user attributes. Add timestamp information to the initial data, and encapsulate the timestamped initial data into a structured data object to form a dynamic permission context.

[0008] As a further aspect of the present invention: the step of inputting the dynamic permission context into the permission policy library for rule matching includes: Match the user identity field and real-time user attribute field in the dynamic permission context with the condition part of the permission policy rule; When the user identity field and the real-time user attribute field in the dynamic permission context meet the conditions of the permission policy rule, the permission policy rule is selected. Output the action part of the selected permission policy rule as the permission determination result; When multiple permission policy rules are selected, the final applicable permission policy rule is determined and output according to the preset priority rules.

[0009] As a further aspect of the present invention: establishing a permission policy database includes: The policy data source includes enterprise access management policy documents and operation log records. The raw policy data includes textual clauses in the enterprise access management policy documents and successful call records in the operation log records. The collected raw strategy data is preprocessed to remove duplicate and invalid data; Initial permission policy rules are generated based on the preprocessed raw policy data. The initial permission policy rules include a condition part and an action part. The condition part defines the combination of user identity and real-time user attributes when the tool is allowed to call. The action part defines the operation that the system will perform when the condition part is met, including allowing the call and denying the call. Store the generated initial permission policy rules into the permission policy database; The stored initial permission policy rules are verified for consistency to ensure that there are no logical conflicts between the rules. The initial permission policy rules that pass the verification are used as permission policy rules. Once the number of permission policy rules reaches the preset value, the permission policy library is established.

[0010] As a further aspect of the present invention, establishing a permission policy database also includes: The operation log records are parsed to extract the successful call records corresponding to each user identity. Each successful call record includes several tool call events. The tool call events are sorted in chronological order to obtain the user behavior sequence. Each tool call event includes the tool type, call timestamp, and permission determination result. Analyze user behavior sequences to identify recurring continuous tool call patterns, and define each identified continuous tool call pattern as a task template; the continuous tool call pattern consists of multiple tool types in a fixed order. The number of times each task template appears in history is counted. When the number of occurrences exceeds a preset threshold, the task template is marked as a high-frequency task template. For each high-frequency task template, the real-time user attributes at the time of execution are extracted as the typical context of the high-frequency task template. Compare the high-frequency task templates and their typical contexts with the text clauses parsed from the enterprise's access control policy documents; When a high-frequency task template and its typical context cannot find a matching permission rule in the text terms, a compensation policy rule is generated. The condition part of the compensation policy rule is set to the typical context of the high-frequency task template, and the action part is set to allow the call. The compensation strategy rules are also stored in the permission strategy database.

[0011] As a further aspect of the present invention: the step of performing corresponding tool call control operations based on the permission determination result includes: When the permission determination result indicates that the call is allowed, the tool call execution command is generated and sent to the intelligent agent; When the permission determination result is "call denied", a call denial instruction is generated and sent to the user, and the following steps are executed: Generate denial reason explanations based on dynamic permission context and matched permission policy rules; Add a statement explaining the reason for rejection to the message sent to the user; Recommendations for alternative tools based on user identification and real-time user attributes; Add alternative tool suggestions to the messages sent to end users; Record the execution information of tool call requests to the audit log. The execution information includes user identity, dynamic permission context and permission determination result.

[0012] The beneficial effects of this invention compared to the prior art are as follows: This invention introduces a dynamic permission determination mechanism based on end-user identity during tool invocation, enabling intelligent agents to perform fine-grained control based on the actual operator's identity and real-time attributes when executing external tool operations. This fundamentally eliminates the disconnect between intelligent agent permissions and user permissions. By constructing a dynamic permission context that includes user identity and real-time attributes and matching it with permission policy rules, the system can determine in real time whether a user possesses the corresponding operational capabilities before tool invocation, effectively preventing low-privilege users from gaining unauthorized access through intelligent agents. The system can automatically adjust permission decisions based on different users' departments, job levels, and geographical locations, achieving fine-grained access control adapted to business scenarios and improving the accuracy and effectiveness of security boundaries. Simultaneously, by generating compensation strategies based on user behavior patterns, the permission policy system can be continuously optimized according to business usage habits, improving the completeness and coverage of permission management. When permissions are denied, the system can also provide clear reasons and alternative tool suggestions, optimizing user experience and enhancing explainability. Overall, this invention makes the intelligent agent tool invocation process more secure, transparent, and dynamically adaptable, significantly improving enterprises' compliance and risk control capabilities in sensitive business scenarios. Attached Figure Description

[0013] The invention will now be further described with reference to the accompanying drawings.

[0014] Figure 1 This is a schematic diagram of a module of an intelligent agent tool access control system based on end-user identity according to the present invention. Detailed Implementation

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

[0016] Please see Figure 1 As shown, the present invention is a smart agent tool access control system based on end-user identity, comprising: Receiving module: Receives tool call requests initiated by end users. The tool call requests include user identification. Processing module: Based on user identity, obtain real-time user attributes from user attribute service. Real-time user attributes include user department, user job level, and user geographical location. In a preferred embodiment of the present invention, the step of obtaining real-time user attributes includes: Send the user's identity identifier to the user attribute service; By querying the user attribute database through the user attribute service, the user's department, job level, and geographical location corresponding to the user's identity identifier can be obtained; The acquired user department, user job level, and user geographical location are combined to form real-time user attributes; Specifically, when the corresponding user department, user rank, or user geographical location does not exist in the user attribute database, the user department and / or user rank and / or user geographical location that do not exist in the user attribute database are obtained from the backup data source and used as substitutes to generate real-time user attributes.

[0017] The user identity identifier is combined with the real-time user attributes to form a dynamic permission context. The dynamic permission context is a structured data object containing user identity fields and real-time user attribute fields. In a preferred embodiment of the present invention, the step of forming a dynamic permission context includes: Extract the user's unique identifier from the user's identity document; The initial data is obtained by combining the user's unique identifier with the user's department, job level, and geographical location from the real-time user attributes. Add timestamp information to the initial data, and encapsulate the timestamped initial data into a structured data object to form a dynamic permission context.

[0018] Matching module: Based on the collection of raw policy data from multiple policy data sources to build a permission policy database, the dynamic permission context is input into the permission policy database for rule matching, and the permission determination result is output. In a preferred embodiment of the present invention, the step of inputting the dynamic permission context into the permission policy library for rule matching includes: Match the user identity field and real-time user attribute field in the dynamic permission context with the condition part of the permission policy rule; When the user identity field and the real-time user attribute field in the dynamic permission context meet the conditions of the permission policy rule, the permission policy rule is selected. Output the action part of the selected permission policy rule as the permission determination result; When multiple permission policy rules are selected, the final applicable permission policy rule is determined and output according to the preset priority rules.

[0019] Understandably, by matching the dynamic permission context with the conditional parts of policy rules, permission determination relies on clearly defined identity and attribute fields, thus ensuring the interpretability and traceability of the judgment results. Matching multiple possible rules and selecting the final applicable rule based on preset priorities ensures logical consistency in permission decisions even in complex scenarios, avoiding judgment biases caused by rule conflicts or overlaps. This mechanism allows the permission evaluation process to better align with the hierarchical structure and fine-grained requirements of actual business policies, making the final tool invocation control behavior more consistent with enterprise security standards and the user's actual permission boundaries, helping to reduce the risk of unauthorized access and improve the accuracy and reliability of permission control.

[0020] In a preferred embodiment, establishing the permission policy database includes: The policy data source includes enterprise access management policy documents and operation log records. The raw policy data includes textual clauses in the enterprise access management policy documents and successful call records in the operation log records. The collected raw strategy data is preprocessed to remove duplicate and invalid data; Initial permission policy rules are generated based on the preprocessed raw policy data. The initial permission policy rules include a condition part and an action part. The condition part defines the combination of user identity and real-time user attributes when the tool is allowed to call. The action part defines the operation that the system will perform when the condition part is met, including allowing the call and denying the call. Store the generated initial permission policy rules into the permission policy database; The stored initial permission policy rules are verified for consistency to ensure that there are no logical conflicts between the rules. The initial permission policy rules that pass the verification are used as permission policy rules. Once the number of permission policy rules reaches the preset value, the permission policy library is established.

[0021] It is important to note that the policy data source consists of enterprise permission management policy documents and operation log records. The policy documents contain permission constraints presented in text format, while the operation log records contain successful call records of each user during actual business operations. To enable the policy data to be used for unified modeling, the collected raw policy data needs to be preprocessed first. One preprocessing method is to use a deduplication approach based on word segmentation and semantic similarity for text-based data. After structurally segmenting the text content, existing text similarity algorithms are used to obtain similarity scores. Clauses with scores exceeding a set range are considered duplicates and deleted. For log-based data, a field consistency-based discrimination method is used. Completely identical call events are considered duplicate data and directly removed. Events with missing fields or abnormal formats are considered invalid data and deleted, thus obtaining preprocessed policy data with standardized content and complete fields.

[0022] When generating initial permission policy rules based on the preprocessed policy data, for textual clauses from policy documents, a rule template extraction method can be used to transform the user identity restrictions, department attribute restrictions, job level restrictions, and regional attribute restrictions in the textual clauses into rule conditions through structured extraction. For successful call records from operation logs, the user identity, user attributes, and call result of each record can be used as samples. An inductive rule generation algorithm can be used to summarize the samples to form initial permission policy rules with user identity and real-time attributes as conditions and call operations as actions. The specific method is not limited.

[0023] The generated initial permission policy rules are directly stored in the permission policy database. To ensure the integrity and stability of the final policy system, consistency verification of the stored initial permission policy rules is required. One method of consistency verification is to compare the condition parts of the rules pairwise, judging whether there are condition conflicts or action conflicts based on logical implication relationships. When rules are found to give different actions under the same or inclusive conditions, conflicting rules are marked and removed from the candidate set. After completing the consistency verification, the retained initial policy rules are considered usable permission policy rules. When the number of obtained rules reaches a preset standard, the establishment of the permission policy library can be considered complete.

[0024] By abstracting existing corporate rules and real business practices into unified logical rules, access control can rely on structured, clear, and unambiguous decision-making criteria. Preprocessing raw policy data eliminates duplicate and abnormal information, ensuring subsequent rule generation is free from noise interference. Textual clauses contain manually defined access boundaries; structuring these boundaries allows for direct expression as computable logical conditions. Successful call records reflect historically accepted behavioral patterns; summarizing these records yields representative empirical rules, ensuring the policy library reflects both normative requirements and covers business practice characteristics. The fundamental role of rule execution consistency verification is to eliminate potentially contradictory rules, ensuring logical consistency when different rules are combined. This results in a stable, deterministic, and reasonable access control policy library, guaranteeing clear and reliable judgments for subsequent access matching.

[0025] In another preferred embodiment of this invention, establishing the permission policy database further includes: The operation log records are parsed to extract the successful call records corresponding to each user identity. Each successful call record includes several tool call events. The tool call events are sorted in chronological order to obtain the user behavior sequence. Each tool call event includes the tool type, call timestamp, and permission determination result. Analyze user behavior sequences to identify recurring continuous tool call patterns, and define each identified continuous tool call pattern as a task template; the continuous tool call pattern consists of multiple tool types in a fixed order. The number of times each task template appears in history is counted. When the number of occurrences exceeds a preset threshold, the task template is marked as a high-frequency task template. For each high-frequency task template, the real-time user attributes at the time of execution are extracted as the typical context of the high-frequency task template. Compare the high-frequency task templates and their typical contexts with the text clauses parsed from the enterprise's access control policy documents; When a high-frequency task template and its typical context cannot find a matching permission rule in the text terms, a compensation policy rule is generated. The condition part of the compensation policy rule is set to the typical context of the high-frequency task template, and the action part is set to allow the call. The compensation strategy rules are also stored in the permission strategy database.

[0026] Understandably, establishing a permission policy database also involves in-depth analysis of operation log records to generate compensation policy rules; The operation log records are grouped by user identity. For each user identity, records with permission determination results indicating permission to call are selected as successful call records. Within each successful call record, fields such as tool type, call timestamp, and permission determination result are read and sorted from earliest to latest by call timestamp to obtain the user's corresponding user behavior sequence.

[0027] Subsequently, the user behavior sequence is scanned sequentially in time, and multiple adjacent tool call events are combined in their original order to obtain continuous tool call segments with a length of no less than two. Each segment only records the tool type field. All segments of the same user and different users are summarized in a unified manner, and a key-value mapping structure is used to count the number of times segments with completely consistent order of each tool type appear. Each segment is regarded as a candidate task template.

[0028] After completing the statistics, the cumulative occurrence count of each candidate task template is read. When the cumulative occurrence count exceeds a preset threshold, the task template is marked as a high-frequency task template. For each high-frequency task template, its occurrence position in the operation log is traced back, and the real-time user attribute information corresponding to these occurrence positions is collected, including fields such as user department, user job level, and user geographical location. All attribute records at the time of occurrence are aggregated using the task template identifier as the key.

[0029] For each attribute field, the frequency of different values ​​is counted, and the value with the highest frequency is taken as the representative value of that field, thereby constructing a typical context that includes fields such as department, job level, and geographical location.

[0030] Next, the high-frequency task templates and their typical contexts are compared with the text clauses parsed from the enterprise's access control system document. During the comparison, based on the pre-structured user identity restrictions and user attribute restrictions in the text clauses, it is determined whether the typical context fully falls within the scope permitted by a certain clause. At the same time, combined with the restrictions on related tools or business operations in the clauses, it is determined whether the combination of tool types involved in the task template is within the set of operations allowed by the clauses.

[0031] When no matching permission rule is found in all text clauses for a high-frequency task template and its typical context, a compensation policy rule is generated for the high-frequency task template. The typical context of the high-frequency task template is used as the condition part of the compensation policy rule, and the allowed call is used as the action part of the compensation policy rule. The generated compensation policy rule is written into the permission policy database in the same format as other policy rules for use in the subsequent permission determination process.

[0032] By statistically analyzing and summarizing continuous tool call behaviors in historical successful call records, stable operational patterns that are repeatedly executed and have been repeatedly permitted in actual business operations can be identified. These patterns objectively reflect the true tolerance boundaries of tool calls in specific scenarios. Extracting these high-frequency task templates from logs and combining them with their corresponding typical contexts allows us to outline a set of permission combinations that have been proven acceptable in practice, based on dimensions such as user department, job level, and geographical location. When no corresponding textual clauses are found in the policy documents, it indicates a gap in the coverage of the original textual permission regulations for this scenario. By generating compensation strategy rules for such scenarios, permission patterns that have been repeatedly recognized in practice can be explicitly solidified into the policy library without violating historical permission judgment results. This ensures that the permission policy both adheres to the policy clauses and incorporates experience information from business operations, thereby improving the policy library's coverage and adaptability to real business scenarios and reducing permission judgment gaps caused by incomplete policy descriptions.

[0033] It's important to note that the introduction of the continuous tool invocation pattern is not intended to allow the system to execute multiple tools simultaneously, but rather to extract real-world business scenarios from historical behavior to accurately generate representative and typical contexts. Single tool invocations are often influenced by occasional behavior, testing operations, or abnormal usage; the user attributes they carry do not consistently reflect business needs and therefore cannot be directly used as the basis for compensation rules. The continuous invocation pattern, however, can present a complete sequence of tools experienced by a user when completing a certain type of business, characterized by continuous steps, stable scenarios, and strong repetitiveness. Statistical analysis of these sequences and identification of high-frequency templates can filter out noisy operations, extracting historically validated permission scenarios from recurring actual business behaviors. Further combining these high-frequency templates with their occurrence attributes yields typical contexts. When these contexts cannot be found in the policy documents, it indicates a coverage gap in the documents, and the high-frequency templates provide reliable factual evidence. Therefore, they can be used as a conditional part of the compensation strategy rules, reasonably expanding the strategy library. In this way, access control not only conforms to policy constraints but also incorporates recurring security operation patterns in real business processes, making the access control policy more comprehensive, reliable, and practically applicable.

[0034] Control module: Executes corresponding tool call control operations based on the permission determination result.

[0035] The steps for performing the corresponding tool call control operations based on the permission determination result include: When the permission determination result indicates that the call is allowed, the tool call execution command is generated and sent to the intelligent agent; When the permission determination result is "call denied", a call denial instruction is generated and sent to the user, and the following steps are executed: Generate denial reason explanations based on dynamic permission context and matched permission policy rules; Add a statement explaining the reason for rejection to the message sent to the user; Recommendations for alternative tools based on user identification and real-time user attributes; Add alternative tool suggestions to the messages sent to end users; Record the execution information of tool call requests to the audit log. The execution information includes user identity, dynamic permission context and permission determination result.

[0036] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the present invention should still fall within the scope of the present invention.

Claims

1. A smart agent tool access control system based on end-user identity, characterized in that, include: Receiving module: Receives tool call requests initiated by end users. The tool call requests include user identification. Processing module: Based on user identity, obtain real-time user attributes from user attribute service. Real-time user attributes include user department, user job level, and user geographical location. The user identity identifier is combined with the real-time user attributes to form a dynamic permission context. The dynamic permission context is a structured data object containing user identity fields and real-time user attribute fields. Matching module: Based on the collection of raw policy data from multiple policy data sources to build a permission policy database, the dynamic permission context is input into the permission policy database for rule matching, and the permission determination result is output. Control module: Executes corresponding tool call control operations based on the permission determination result.

2. The intelligent agent tool access control system based on end-user identity as described in claim 1, characterized in that, The steps to obtain real-time user attributes include: Send the user's identity identifier to the user attribute service; By querying the user attribute database through the user attribute service, the user's department, job level, and geographical location corresponding to the user's identity identifier can be obtained; The acquired user department, user job level, and user geographical location are combined to form real-time user attributes; Specifically, when the corresponding user department, user rank, or user geographical location does not exist in the user attribute database, the user department and / or user rank and / or user geographical location that do not exist in the user attribute database are obtained from the backup data source and used as substitutes to generate real-time user attributes.

3. The intelligent agent tool access control system based on end-user identity as described in claim 2, characterized in that, The steps to create a dynamic permission context include: Extract the user's unique identifier from the user's identity document; The initial data is obtained by combining the user's unique identifier with the user's department, job level, and geographical location from the real-time user attributes. Add timestamp information to the initial data, and encapsulate the timestamped initial data into a structured data object to form a dynamic permission context.

4. A smart agent tool access control system based on end-user identity as described in claim 3, characterized in that, The steps for inputting the dynamic permission context into the permission policy library for rule matching include: Match the user identity field and real-time user attribute field in the dynamic permission context with the condition part of the permission policy rule; When the user identity field and the real-time user attribute field in the dynamic permission context meet the conditions of the permission policy rule, the permission policy rule is selected. Output the action part of the selected permission policy rule as the permission determination result; When multiple permission policy rules are selected, the final applicable permission policy rule is determined and output according to the preset priority rules.

5. A smart agent tool access control system based on end-user identity as described in claim 4, characterized in that, Establishing a permission policy database includes: The policy data source includes enterprise access management policy documents and operation log records. The raw policy data includes textual clauses in the enterprise access management policy documents and successful call records in the operation log records. The collected raw strategy data is preprocessed to remove duplicate and invalid data; Initial permission policy rules are generated based on the preprocessed raw policy data. The initial permission policy rules include a condition part and an action part. The condition part defines the combination of user identity and real-time user attributes when the tool is allowed to call. The action part defines the operation that the system will perform when the condition part is met, including allowing the call and denying the call. Store the generated initial permission policy rules into the permission policy database; The stored initial permission policy rules are verified for consistency to ensure that there are no logical conflicts between the rules. The initial permission policy rules that pass the verification are used as permission policy rules. Once the number of permission policy rules reaches the preset value, the permission policy library is established.

6. A smart agent tool access control system based on end-user identity as described in claim 5, characterized in that, Establishing a permission policy database also includes: The operation log records are parsed to extract the successful call records corresponding to each user identity. Each successful call record includes several tool call events. The tool call events are sorted in chronological order to obtain the user behavior sequence. Each tool call event includes the tool type, call timestamp, and permission determination result. Analyze user behavior sequences to identify recurring continuous tool call patterns, and define each identified continuous tool call pattern as a task template; the continuous tool call pattern consists of multiple tool types in a fixed order. The number of times each task template appears in history is counted. When the number of occurrences exceeds a preset threshold, the task template is marked as a high-frequency task template. For each high-frequency task template, the real-time user attributes at the time of execution are extracted as the typical context of the high-frequency task template. Compare the high-frequency task templates and their typical contexts with the text clauses parsed from the enterprise's access control policy documents; When a high-frequency task template and its typical context cannot find a matching permission rule in the text terms, a compensation policy rule is generated. The condition part of the compensation policy rule is set to the typical context of the high-frequency task template, and the action part is set to allow the call. The compensation strategy rules are also stored in the permission policy database.

7. A smart agent tool access control system based on end-user identity as described in claim 5, characterized in that, The steps for performing the corresponding tool call control operations based on the permission determination result include: When the permission determination result indicates that the call is allowed, the tool call execution command is generated and sent to the intelligent agent; When the permission determination result is "call denied", a call denial instruction is generated and sent to the user, and the following steps are executed: Generate a denial reason explanation based on the dynamic permission context and the matched permission policy rules; Add a statement explaining the reason for rejection to the message sent to the user; Recommendations for alternative tools based on user identification and real-time user attributes; Add alternative tool suggestions to the messages sent to end users; Record the execution information of tool call requests to the audit log. The execution information includes user identity, dynamic permission context and permission determination result.

Images