User authorization method and device of multi-tenant agentic engine, electronic equipment and storage medium

Abstract

The application provides a user authorization method and device of a multi-tenant Agentic engine, electronic equipment and a storage medium, and relates to the technical field of computer software and information security, which comprises the following steps: obtaining tool calling information based on a user request; loading and screening authorization records matched with the tool calling information from a preset authorization storage; outputting a calling decision according to the screening result and the tool calling information; in response to the calling decision, a pop-up window is used to consult the user when the calling decision is to consult the user, and the authorization records are loaded and screened again to output and respond to the calling decision after the authorization records are created according to the user feedback. The application can ensure that all tool calls are subjected to unified, auditable and revocable authorization determination, while supporting parameter-level constraints and multi-tenant isolation, and has strong practicability.

Description

Technical Field

[0001] This application relates to the fields of computer software and information security technology, specifically to a user authorization method for a multi-tenant agentic engine. Background Technology

[0002] With the development of large language models and artificial intelligence agent technology, agents are increasingly being used to represent end users in invoking various business tools to complete specific tasks, such as querying business data, calling business interfaces, and sending notifications. In multi-tenant Software as a Service (SaaS) scenarios, the actions performed by agents on behalf of users involve users' resource access permissions. How to provide fine-grained, auditable, and revocable user authorization for agents' tool invocation behavior has become a pressing technical problem to be solved.

[0003] In existing technologies, OAuth2.0 / OIDC implements user authorization through the "consent screen" mechanism, but its authorization is a one-time authorization at login, with fixed authorization granularity and a single lifecycle, making it difficult to support new intentions that dynamically emerge during the conversation; open-source agent frameworks such as LangChain and AutoGen usually hardcode tool call permissions at the code level or indirectly control them through prompts, lacking an independent tenant-level authorization governance layer, making it difficult to distinguish between "administrator bans" and "user consent"; Model Context Protocol (MCP) provides a unified description for tool access, but it does not standardize the user authorization model itself, and the authorization logic is pushed down to each service to implement itself; ChatGPT GPTs / Plugin permission proxies only provide a one-time confirmation pop-up, and the authorization status does not have publicly accessible query and revocation interfaces, leaving no control plane on the administrator side; enterprise-level agent platforms treat temporary consent during the conversation as an interaction process rather than an independent data object, failing to form an auditable authorization record.

[0004] In summary, existing solutions generally suffer from shortcomings such as limited authorization granularity, coupling of authorization determination and tool scheduling, lack of real-time consultation mechanism within the dialogue, absence of parameter-level constraints, lack of multi-tenant authorization governance, and incomplete authorization auditing. Summary of the Invention

[0005] To address the shortcomings of the aforementioned existing technologies, this application provides a user authorization method, apparatus, electronic device, and storage medium for a multi-tenant agentic engine. This method ensures that all tool calls undergo unified, auditable, and revocable authorization determination, while also supporting parameter-level constraints and multi-tenant isolation, making it highly practical.

[0006] To achieve the above objectives, the present invention employs the following techniques: A user authorization method for a multi-tenant agentic engine includes the following steps: The tool invocation information is obtained based on the user's request. The tool invocation information includes the authentication context, the tool description object, and the tool input parameters. The tool description object includes a name field and a solicitation strategy field. The solicitation strategy field is divided into no solicitation required, solicitation for first use, solicitation for each invocation, or only administrator authorization. The system loads and filters authorization records that match the tool call information from the preset authorization storage; the authorization records are categorized by form into static authorization records preset by the administrator before the request, default authorization records preset by the user before the request, temporary authorization records written by the user in the dialog, and long-term authorization records. Based on the filtering results and tool call information, a call decision is output; the call decision is divided into allow, deny, or require consultation with the user. The system responds to the call decision output. If the call decision is "allow," the tool call is executed; if the call decision is "deny," a "no permission" message is returned; if the call decision requires user consultation, a pop-up window is displayed to consult the user. When a pop-up window prompts the user, an authorization record is created and responded to based on the user's feedback: If the user's feedback is "allow this time", a temporary authorization record is created based on the tool call information and stored in the authorization storage, and the authorization record is reloaded and filtered to output and respond to the call decision; if the prompting policy field is "first-time use prompt" and the user's feedback is "always allow", a long-term authorization record is created based on the tool call information and stored in the authorization storage, and the authorization record is reloaded and filtered to output and respond to the call decision; if the user's feedback is "deny" or "timeout", a "no permission" message is returned.

[0007] A user authorization device for a multi-tenant Agentic engine includes a tool call information acquisition module, an authorization record processing module, a call decision output module, a call decision response module, and a pop-up query and processing module; The tool call information acquisition module is used to acquire tool call information based on user requests; the tool call information includes authentication context, tool description object and tool input parameters; the tool description object includes name field and solicitation strategy field, the solicitation strategy field is divided into no solicitation required, solicitation for first use, solicitation for each call or only administrator authorization; The authorization record processing module is used to load and filter authorization records that match the tool call information from the preset authorization storage; the authorization records are divided into static authorization records preset by the administrator before the request, default authorization records preset by the user before the request, temporary authorization records written by the user in the dialog, and long-term authorization records. The call decision output module is used to output a call decision based on the filtering results and tool call information; the call decision is divided into allow, deny, or require consultation with the user. The call decision response module is used to respond to the call decision output. When the call decision is allowed, the tool call is executed; when the call decision is denied, a permission-less message is returned; when the call decision requires the user to be consulted, a pop-up window is displayed to consult the user. The pop-up consultation and processing module is used to create authorization records and respond based on user feedback when a pop-up consultation is requested: when the user feedback is "allow this time", a temporary authorization record is created based on the tool call information and stored in the authorization storage, and the authorization record is reloaded and filtered to output and respond to the call decision; when the consultation strategy field is "first-time use consultation" and the user feedback is "always allow", a long-term authorization record is created based on the tool call information and stored in the authorization storage, and the authorization record is reloaded and filtered to output and respond to the call decision; when the user feedback is "deny" or "timeout", "no permission" information is returned.

[0008] An electronic device includes: at least one processor and a memory; wherein the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions stored in the memory, causing the at least one processor to execute the user authorization method of the multi-tenant Agentic engine.

[0009] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, controls the device on which the computer-readable storage medium resides to perform the user authorization method of the multi-tenant Agentic engine.

[0010] The beneficial effects of this invention are as follows: 1. By using four types of authorization records—static authorization records, default authorization records, temporary authorization records, and long-term authorization records—it covers a variety of real-world business scenarios beyond the two extremes of "every time you ask" and "one-time authorization to the end," reducing disruption to users and alleviating the governance burden on administrators while ensuring security. 2. The authorization determination is moved to a unified tool call chain to ensure that all tool calls must go through a unified authorization determination. The authorization determination is decoupled from identity authentication in a layered manner. One set of authorization determination can serve both built-in tools and extended tools at the same time, avoiding duplicate implementation on different business sides. 3. When it is necessary to consult users, a pop-up window is used to solicit their opinions, and the user's selection is structured into an authorization record and stored in the database, realizing an atomic closed loop of "pause, pop-up, confirmation, and continuation"; 4. Further limit the scope of input parameters at the tool level, such as "only allow calling the specified business interface" or "only allow querying the user's own data", to avoid the risk of horizontal privilege escalation; 5. All authorization records are bound to tenant identifiers and partitioned by tenant at both the data storage and session caching levels to prevent administrator policies from being leaked across tenants or user consent from being reused incorrectly. 6. Structured logging is performed when outputting call decisions, soliciting users through pop-up windows, and creating authorization records to meet the needs of compliance auditing and post-event accountability. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating the user authorization method of the multi-tenant Agentic engine in an embodiment of this application.

[0012] Figure 2 This is a schematic diagram of the process for obtaining tool call information according to an embodiment of this application.

[0013] Figure 3 This is a schematic diagram of the authorization record loading and filtering process in an embodiment of this application.

[0014] Figure 4 This is a flowchart illustrating the parameter constraint determination process in an embodiment of this application.

[0015] Figure 5 This is a schematic diagram of the call decision determination process in an embodiment of this application.

[0016] Figure 6 This is a schematic diagram of the user authorization device of the multi-tenant Agentic engine in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the implementation methods of the present invention will be described in detail below with reference to the accompanying drawings. However, the embodiments described in this invention are only some embodiments of the present invention, and not all embodiments.

[0018] "Agentic engine" refers to an intelligent agent runtime system in which AI can autonomously understand user intent, determine which tool to invoke, construct input parameters, and perform operations on behalf of the user after authorization. The user authorization method provided in this application runs in a multi-tenant Agentic engine. This engine consists of three parts: a front-end / software development kit (SDK) subsystem, an Agentic engine runtime subsystem, and external dependencies. The front-end / SDK subsystem includes a unified front-end component that integrates a dialog interface and an authorization pop-up. The Agentic engine runtime subsystem includes a conversation orchestrator and an Agentic inference orchestrator. The system consists of a kernel, task execution adapter, authorization gateway, authorization storage, authorization receipt controller, audit event table, and tool processor set; external dependencies include message service and authorization management interface; the Agentic inference orchestration kernel carries the inference pipeline and its tool call sub-flows for tool invocation; the task execution adapter serves as the unified entry point for tool invocation; the authorization gateway outputs three-state decisions: allow, deny, or require consultation; the authorization storage stores various authorization records; the authorization receipt controller receives user receipts for authorization requests; the audit event table records authorization decisions and authorization changes; and the tool processor set includes built-in tool processors and extended tool processors.

[0019] In the overall data flow, the frontend sends a request to the session orchestrator carrying the holder's access token; the session orchestrator calls the inference pipeline of the Agentic inference orchestration kernel; the inference pipeline calls back the task execution adapter through the task execution callback port; the task execution adapter first triggers the pre-authorization check and calls the authorization gateway; the authorization gateway accesses the authorization store to load candidate authorization records, writes decision records to the audit event table, and returns permission or request for consultation to the task execution adapter; when request for consultation is returned, the task execution adapter sends an authorization request event through the message service, which is pushed to the frontend pop-up window by the message service; after the frontend user makes a selection, the authorization receipt controller submits the receipt; the authorization receipt controller writes to the authorization store and wakes up the waiting task execution adapter; after obtaining permission, the task execution adapter routes to the specific tool processor for execution according to the tool routing identifier; the authorization management interface, as a bypass channel on the administrator side, can directly write to the authorization store for static authorization governance.

[0020] like Figure 1 As shown, one aspect of this application embodiment provides a user authorization method for a multi-tenant agentic engine, including steps S100 to S500: S100. Obtain tool invocation information based on user requests; wherein, tool invocation information includes authentication context, tool description object, and tool input parameters; authentication context is used to provide user identity information; tool description object is used to describe the tool, that is, what the tool is, how to use it, how to authorize it, and who executes it; tool input parameters are used as specific parameter data to be passed in when invoking the tool, that is, to instruct the system to use what data to execute the tool; tool description object includes name field and solicitation policy field, solicitation policy field is divided into no solicitation, first use solicitation, solicitation for each call, or administrator authorization only; solicitation policy field is used as a fallback authorization basis when the filtering result is that there is no authorization record that meets all preset filtering conditions, it is a refinement of the earlier naming (implicit / once / prompt / admin_only), and is forcibly declared on each tool description object.

[0021] Preferred, such as Figure 2 As shown, in step S100, obtaining tool call information based on user requests is implemented through steps S101 to S104: S101. Receive the user's instruction text and holder access token; wherein, the instruction text refers to the user dialogue received by the pre-set front-end UI, such as "Help me send a reminder email to their legal department about the contract that expired last week"; the holder access token refers to the user credential issued by the identity authentication server when the user logs into the system, which is used for subsequent user identification.

[0022] S102. Parse the authentication context from the holder's access token. In this embodiment, after receiving the user's instruction text and the holder's access token, the front-end UI initiates a dialogue request carrying the holder's access token to the session orchestrator. The session orchestrator verifies the holder's access token, parses the user's identity, and generates the authentication context.

[0023] S103. Inferring tool names and tool input parameters based on instruction text; In this embodiment, the session orchestrator calls the Agentic inference orchestration kernel after generating the authentication context; The Agentic inference orchestration kernel assembles the instruction text into a format that the large language model can understand through its built-in inference pipeline, and extracts all tool names, tool descriptions and input parameter structures that can be selected by the large language model from the tool registry and passes them to the large language model. Finally, the large language model infers the applicable tool names and tool input parameters.

[0024] S104. Query the tool description object in the pre-built tool registry based on the tool name. In this embodiment, after the large language model infers the requested tool name and tool input parameters, the tool call sub-process in the Agentic inference orchestration kernel constructs a task node containing the tool name and tool input parameters. The inference pipeline calls back the task execution adapter through the task execution callback port. The task execution adapter queries the corresponding tool description object from the tool registry based on the tool name in the task node, and after finding the tool description object, it is sent to the authorization gateway along with the authentication context and tool input parameters.

[0025] S200. Load and filter authorization records that match the tool call information from the preset authorization storage; the authorization records are divided into static authorization records preset by the administrator before the request, default authorization records preset by the user before the request, temporary authorization records written by the user in the dialog, and long-term authorization records; the authorization records are the core data of the system that stores "who is allowed to do what".

[0026] In this embodiment, the four types of authorization records are carried by a unified authorization record data object and are distinguished by fields such as form, source, execution action, and lifespan. More specifically, the authorizer of the static authorization record is the tenant AI administrator, and the lifespan is long-term (until it is revoked by the administrator). It is used to allow or prohibit a user group from using a certain tool and is the only type whose execution action can be set to deny the call. The authorizer of the default authorization record is the user, and the lifespan is long-term. It is used for the user to pre-authorize the AI ​​to call a certain tool without being asked. The authorizer of the temporary authorization record is the user, and the lifespan is one-time. It corresponds to the scenario where the user selects "Allow this time" in the pop-up window and is invalid after a single consumption. The authorizer of the long-term authorization record is the user, and the lifespan is long-term. It is stored in the database authorization record table and corresponds to the scenario where the user selects "Always Allow" in the pop-up window. It can be distinguished from the default authorization record at the audit layer.

[0027] Preferably, the authorization storage includes a MySQL authorization record table and a Redis session cache; static authorization records, default authorization records, and long-term authorization records are located in the MySQL authorization record table to ensure that data is not lost; temporary authorization records are located in the Redis session cache, which utilizes the high-speed read and write capabilities of memory and the automatic TTL cleanup feature to reduce the write pressure on MySQL.

[0028] Preferably, the authentication context includes a tenant identifier to indicate the tenant's identity, a user identifier to indicate the user's identity, and a session identifier to indicate that it belongs to the current session; the authorization record includes an authorized tenant to indicate the authorized tenant's identity, an authorized subject to indicate the object to which the authorization is applied, and a target tool to indicate the target tool to which the authorization is applied; wherein, the authorized subject is divided into an authorized user to indicate the user to whom the authorization is applied or an authorized session to indicate the session to which the authorization is applied; based on this, such as Figure 3 As shown, in step S200, loading and filtering authorization records that match the tool invocation information from the preset authorization storage is implemented through steps S201 to S202: S201. Load candidate authorization records in the preset authorization storage. The candidate authorization records include static authorization records that match the authorized tenant identifier, default authorization records and long-term authorization records that match the authorized user identifier, and temporary authorization records that match the authorized session identifier. Here, matching means that the authorized tenant and the tenant identifier represent the same tenant, the authorized user and the user identifier represent the same user, and the authorized session and the session identifier represent the same session.

[0029] S202. Select authorization records from candidate authorization records that meet all preset filtering conditions. The filtering conditions include: the target tool matches the name field of the tool description object, the authorization subject matches the authentication context, and when the authorization record contains parameter constraints, the target object composed of the name field, tool input parameters and authentication context satisfies the parameter constraints.

[0030] Matching here means that the target tool and the name field of the tool description object point to the same tool, and the authorization subject is included in the authentication context.

[0031] Further preferably, the authorization record also includes a lifecycle field indicating the effective time and expiration time, and a revocation time field recorded upon revocation; the filtering conditions also include "not expired" and "not revoked". "Not expired" means the authorization record is currently within its lifecycle; "not revoked" means the revocation time field of the authorization record is currently empty, i.e., the authorization record has not been revoked.

[0032] Preferably, the parameter constraints include matching logic and at least one matching item; the matching logic is divided into "AND" or "OR", and the matching item includes path, operator, and target value; based on this, such as Figure 4 As shown, when the authorization record contains parameter constraints, determining whether the target object meets the parameter constraints is achieved through steps S211 and S212: S211. For each matching item, retrieve the value from the target object according to its path, and determine whether the retrieved value matches the target value based on the operator: if yes, the target object matches the matching item; if no, the target object does not match the matching item.

[0033] S212. Determine whether the target object satisfies the parameter constraints based on the matching logic: When the matching logic is "AND", the target object is deemed to satisfy the parameter constraints if and only if it matches all matching items; otherwise, the target object is deemed not to satisfy the parameter constraints. When the matching logic is "OR", the target object is deemed not to satisfy the parameter constraints if and only if it does not match all matching items; otherwise, the target object is deemed to satisfy the parameter constraints.

[0034] In this embodiment, parameter constraints can be expressed using controlled path expressions. Preferably, parameter constraints are persisted as encapsulated objects containing version fields, facilitating subsequent cross-version coexistence and lossless evolution. Taking an interface calling tool as an example, a parameter constraint for constraining an interface calling tool may include three matching items: the first matching item's path is the name field, the operator is equal, and the target value is the name of the interface calling tool; the second matching item's path is the business interface name in the tool's input parameters, the operator is belong, and the target value is a set including reading personnel files and listing personnel files; the third matching item's path is the user identifier in the tool's input parameters, the operator is equal to the user identifier. The following variables, where the target value is a context variable, are user identifiers in the authentication context. This means that the input parameter value must be equal to the current user identifier in the authentication context, thus achieving the constraint of "only accessing the user's own data is allowed". The above path expression only supports attribute access, array subscripts, and trailing wildcards. Operators include equal to, not equal to, belong to, not belong to, equal to context variable, and not equal to context variable. Context variables are limited to a controlled whitelist, such as the current principal user identifier, the current principal tenant identifier, the session agent identifier, and the session identifier. The number of matching items and the size of the set class values ​​are subject to a preset upper limit.

[0035] S300. Output a call decision based on the filtering results and tool call information; the call decision is divided into allow, deny, or require consultation with the user.

[0036] Preferably, the authorization record also includes an execution action, which is used to determine whether the authorization record allows or denies tool invocation; the execution action of static authorization records is divided into allow invocation and deny invocation, and the execution action of default authorization records, temporary authorization records and long-term authorization records is allow invocation.

[0037] In this embodiment, taking an interface invocation tool as an example, its tool description object may include: a solicitation policy field indicating first-time use solicitation, meaning that the tool needs to solicit the user's consent when used for the first time; a solicitation timeout threshold (e.g., 60 seconds), indicating that a timeout is considered a rejection; an execution mode (e.g., synchronous execution); a side effect identifier (e.g., write side effect); and runtime dependencies (e.g., the need for an end-user identity, or the need to exchange a proxy token for the target business interface). These fields are pre-declared on each tool description object for use by the authorization gateway when outputting invocation decisions.

[0038] Based on this, such as Figure 5 As shown, in step S300, the decision to invoke the tool is output based on the filtering results and the tool description object, and is implemented through steps S301 to S304: S301. Determine if a static authorization record exists and its execution action is to deny the call: if yes, output the call decision as deny; if no, determine if a static authorization record exists and its execution action is to allow the call.

[0039] S302. Determine if a static authorization record exists and its execution action is "allow call": If yes, output the call decision as "allow"; if no, determine if the following conditions are met simultaneously: the query strategy field of the current tool description object is not "administrator only" and there is a default authorization record or a long-term authorization record.

[0040] S303. Determine whether the following conditions are met simultaneously: the solicitation policy field of the current tool description object is not "administrator-only authorization", and there is a default authorization record or a long-term authorization record. If yes, output the call decision as "allowed". If no, determine whether the following conditions are met simultaneously: the solicitation policy field of the current tool description object is not "administrator-only authorization", and there is a temporary authorization record that has not yet been consumed.

[0041] S304. Determine whether the following conditions are met simultaneously: the solicitation policy field of the current tool description object is not "administrator-only authorization", a temporary authorization record exists and has not yet been consumed; preferably, the authorization record also includes a consumption time field used only by temporary authorization records; "not yet consumed" here means that the consumption time field of the temporary authorization record currently has no record, i.e., the temporary authorization record has not been consumed: if yes, output the call decision as "allow", and mark the temporary authorization record as consumed. Marking it as consumed here means writing the current time into the consumption time field of the temporary authorization record and automatically cleaning it up when a round of dialogue ends or the entire session is marked as deleted; if no, output the call decision according to the solicitation policy field: when the solicitation policy field is "no solicitation required", output the call decision as "allow"; when the solicitation policy field is "first-time use solicitation", output the call decision as "user needs to be solicited", and allow the user to choose "allow this time" or "always allow"; each time a solicitation is called, output the call decision as "user needs to be solicited", and allow the user to choose "allow this time" only; when the solicitation policy field is "administrator-only authorization", output the call decision as "deny".

[0042] In this embodiment, the task execution adapter first calls the entry function `AuthorizationGateway.authorize(AuthContext,ToolDescriptor,args)` of the authorization gateway, where `AuthContext` represents the authentication context, `ToolDescriptor` represents the tool description object, and `args` represents the tool input parameters. The authorization gateway loads candidate authorization records according to this entry function, and then calls the internal pure decision function `AuthorizationDecision.check(AuthContext,ToolDescriptor,args,Grants,decisionTime)`, where `Grants` represents the candidate authorization record, and `decisionTime` represents the current time, used to determine whether the authorization record is within its lifecycle. The authorization gateway performs the filtering of candidate authorization records according to this internal pure decision function, and outputs the call decision in combination with the tool call information. It performs parameter constraint verification when filtering authorization records, and finally outputs the call decision.

[0043] S400 responds to the call decision. When the call decision is allowed, the tool call is executed, and the tool is routed to the pre-built tool processor for execution according to the tool name in the task node. When the call decision is denied, no permission information is returned. When the call decision is that the user needs to be consulted, a pop-up window is displayed to consult the user.

[0044] When the S500 pop-up window prompts the user, it creates an authorization record based on the user's feedback and responds: if the user feedback is "allow this time", it creates a temporary authorization record based on the tool call information and stores it in the authorization storage, and then reloads and filters the authorization record to output and respond to the call decision; if the prompting policy field is "first-time use prompt" and the user feedback is "always allow", it creates a long-term authorization record based on the tool call information and stores it in the authorization storage, and then reloads and filters the authorization record to output and respond to the call decision; if the user feedback is "deny" or "timeout", it returns "no permission" information.

[0045] In this embodiment, the process of soliciting user requests via pop-up is as follows: After the task execution adapter receives the call decision that "user requests need to be solicited," it sends an authorization request event through the message service, which then pushes the event to the front end to trigger the pop-up display. After the user makes a selection on the pop-up, the front end submits an authorization receipt through the authorization receipt controller. The receipt contains at least a decision field and an optional validity period field. The authorization receipt controller performs corresponding processing based on the decision field in the receipt: when the decision is "allow this time," a temporary authorization record is created based on the tool call information and written to the authorization storage; when the solicitation strategy field is "first time,"... When the query is used and the decision is "always allow", a long-term authorization record is created based on the tool call information and written to the authorization storage. At the same time, a temporary authorization record can be written as a fallback. When the decision is "deny" or the receipt times out (e.g., more than 60 seconds), the authorization receipt controller returns no permission information and ends the call. When the decision is "allow this time" or "always allow", the authorization receipt controller wakes up the waiting task execution adapter after completing the writing. The task execution adapter reloads and filters the authorization records to determine and respond to the call decision output, that is, steps S200 to S400 are executed again.

[0046] Preferably, when outputting a call decision, the output call decision information is recorded in a preset audit event table; when a pop-up window solicits user feedback, the user feedback information is recorded in a preset audit event table; when creating an authorization record, the authorization record information is recorded in a preset audit event table.

[0047] In this embodiment, all authorization records and authorization keys in the session cache are forcibly partitioned by tenant identifier, and the storage layer encapsulates the injection of tenant identifier, which cannot be bypassed by business code; the failure broadcast channel carries the tenant identifier, and each replica cleans up the local cache at the tenant granularity; in addition, the administrator can pre-set static authorization records through the authorization management interface and publish static authorization record templates, which are copied as independent copies as needed when secondary tenants are created, realizing "governance once, tenant copy as needed".

[0048] In this embodiment, the administrator can pre-configure a static authorization record through the authorization management interface. For example, the fields of this static authorization record may include: tenant identifier, used to bind to a specific tenant; format, valued as a static authorization record; authorizer type, valued as an administrator; authorizer user identifier, the specific user identifier of the record grantor; authorization subject, used to limit the static authorization record to only apply to a specified user group; scope, including target tool, execution action (allowed invocation), and parameter constraints; source, indicating that the source of the static authorization record is an administrator policy.

[0049] The following example illustrates the complete operation of this application's embodiment using a specific application scenario. A second-level tenant (tenant ID tnt_001) has an end-user (user ID usr_alice) who, in the initial conversation, requests the Agent to "send a reminder email to the other party's legal department regarding the contract that expired last week." The Agent, through reasoning, decides to invoke the built-in API call tool, targeting the email sending interface hr.mail.send. At this point, there is no default authorization record for this user in the system, and the solicitation strategy field in the tool description object of the API call tool is set to first-time use solicitation.

[0050] The runtime chain is as follows: 1. The Agentic inference orchestration kernel constructs task nodes through a tool call sub-process. The tool routing identifier, i.e., the tool name, points to the built-in interface call tool. The tool input parameters include the target business interface name hr.mail.send, the tenant identifier tnt_001, etc.

[0051] 2. The inference pipeline calls back to the task execution adapter through the task execution callback port.

[0052] 3. The task execution adapter first calls the authorization gateway to perform an authorization check: load candidate authorization records, one of which is a static authorization record preset by the administrator whose authorization subject is a specified user group, which does not match the current user, so it returns to the next priority; the user has no default authorization record, no long-term authorization record, and no temporary authorization record; fall back to the "first use inquiry" field of the inquiry policy, and return the user that needs to be inquired.

[0053] 4. The task execution adapter generates an authorization request identifier and sends an authorization request event to the user terminal through the front-end event channel. The prompt message is, for example, "The agent wants to call the email sending interface on your behalf to send a reminder email to the other party's legal affairs. Do you allow it?"

[0054] 5. The front-end pop-up window displays three options: "Allow this time / Always allow / Deny". The user clicks "Always allow" and selects a validity period of 30 days.

[0055] 6. The front end submits an authorization receipt through the authorization receipt controller. The authorization receipt controller writes a long-term authorization record (the source is marked as session upgrade, the authorization subject is the user, the target tool is the built-in interface call tool, and the parameter constraints are automatically derived from the input parameters of this tool and are protected by "the input parameter user name must be equal to the current user identifier"), and writes a temporary authorization record as a fallback.

[0056] 7. The authorization receipt controller wakes up the waiting task execution adapter. The task execution adapter calls the authorization gateway again to replay the authorization check. This time, a long-term authorization record is hit, and permission is returned.

[0057] 8. The task execution adapter routes to the processor of the interface calling tool according to the tool routing identifier. The processor internally obtains the proxy token for the target business interface, calls the email sending interface to send the email, and returns success.

[0058] 9. The audit event table should sequentially record events such as "Decision to call requires consultation", "User consent has been approved", "Authorization record has been created", and "Decision to call is allowed", and desensitize the tool input parameters in the form of summary values.

[0059] Subsequently, when the user requests the Agent to send an email again, the authorization gateway will directly return permission if it hits the long-term authorization record, without popping up a new window; if the long-term authorization record expires after 30 days, it will return to the initial use query and be queried again; the user can also actively revoke the authorization record in the user authorization center, and the revocation information will take effect in a timely manner for all copies through the expiration broadcast channel.

[0060] like Figure 6 As shown, another aspect of the embodiments of this application provides a user authorization device for a multi-tenant Agentic engine, including a tool call information acquisition module, an authorization record processing module, a call decision output module, a call decision response module, and a pop-up query and processing module.

[0061] The tool call information acquisition module is used to obtain tool call information based on user requests; the tool call information includes authentication context, tool description object and tool input parameters; the tool description object includes name field and solicitation strategy field, the solicitation strategy field is divided into no solicitation required, solicitation for first use, solicitation for each call or only administrator authorization.

[0062] The authorization record processing module is used to load and filter authorization records that match the tool call information from the preset authorization storage; the authorization records are divided into static authorization records preset by the administrator before the request, default authorization records preset by the user before the request, temporary authorization records written by the user in the dialog, and long-term authorization records.

[0063] The call decision output module is used to output a call decision based on the filtering results and tool call information; the call decision is divided into allow, deny, or require consultation with the user.

[0064] The call decision response module is used to respond to the call decision output. When the call decision is allowed, the tool call is executed; when the call decision is denied, no permission information is returned; when the call decision is that the user needs to be consulted, a pop-up window is displayed to consult the user.

[0065] The pop-up consultation and processing module is used to create authorization records and respond based on user feedback when a pop-up consultation is requested: when the user feedback is "allow this time", a temporary authorization record is created based on the tool call information and stored in the authorization storage, and the authorization record is reloaded and filtered to output and respond to the call decision; when the consultation strategy field is "first-time use consultation" and the user feedback is "always allow", a long-term authorization record is created based on the tool call information and stored in the authorization storage, and the authorization record is reloaded and filtered to output and respond to the call decision; when the user feedback is "deny" or "timeout", "no permission" information is returned.

[0066] In another aspect of this application, an electronic device is provided, comprising: at least one processor and a memory; wherein the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions stored in the memory, causing the at least one processor to execute the user authorization method of the multi-tenant Agentic engine.

[0067] In another aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein the computer program, when executed by a processor, controls the device where the computer-readable storage medium is located to execute the user authorization method of the multi-tenant Agentic engine.

[0068] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A user authorization method for a multi-tenant agentic engine, characterized in that, Including the following steps: The tool invocation information is obtained based on the user's request. The tool invocation information includes the authentication context, the tool description object, and the tool input parameters. The tool description object includes a name field and a solicitation strategy field. The solicitation strategy field is divided into no solicitation required, solicitation for first use, solicitation for each invocation, or only administrator authorization. The system loads and filters authorization records that match the tool call information from the preset authorization storage; the authorization records are categorized by form into static authorization records preset by the administrator before the request, default authorization records preset by the user before the request, temporary authorization records written by the user in the dialog, and long-term authorization records. Output the invocation decision based on the screening results and tool invocation information; The call decision is divided into allow, deny, or require consultation with the user; The response output indicates the invocation decision. If the invocation decision is allowed, the tool invocation is executed; if the invocation decision is denied, an "unauthorized" message is returned. When the decision requires consulting the user, a pop-up window will be displayed to consult the user. When a pop-up window prompts the user, an authorization record is created and responded to based on the user's feedback: If the user's feedback is "allow this time", a temporary authorization record is created based on the tool call information and stored in the authorization storage, and the authorization record is reloaded and filtered to output and respond to the call decision; if the prompting policy field is "first-time use prompt" and the user's feedback is "always allow", a long-term authorization record is created based on the tool call information and stored in the authorization storage, and the authorization record is reloaded and filtered to output and respond to the call decision; if the user's feedback is "deny" or "timeout", a "no permission" message is returned.

2. The user authorization method for a multi-tenant agentic engine according to claim 1, characterized in that, Obtaining tool invocation information based on user requests includes the following steps: Receive user's instruction text and the holder's access token; Parse the authentication context from the holder's access token; Based on the instruction text, infer the tool name and tool input parameters; The tool description object is queried in a pre-built tool registry based on the tool name.

3. The user authorization method for a multi-tenant agentic engine according to claim 1, characterized in that, The authorization storage includes a MySQL authorization record table and a Redis session cache. Static authorization records, default authorization records, and long-term authorization records are located in the MySQL authorization record table, while temporary authorization records are located in the Redis session cache.

4. The user authorization method for a multi-tenant agentic engine according to claim 1, characterized in that, The authentication context includes tenant identifier, user identifier, and session identifier; the authorization record includes authorized tenant, authorized subject, and target tool; the authorized subject is divided into authorized user or authorized session; Load and filter authorization records that match tool call information from the pre-configured authorization store, including the following steps: Load candidate authorization records into the pre-configured authorization storage, including static authorization records that match the authorized tenant with the tenant identifier, default authorization records and long-term authorization records that match the authorized user with the user identifier, and temporary authorization records that match the authorized session with the session identifier; The candidate authorization records are filtered to meet all preset filtering conditions. The filtering conditions include: the target tool matches the name field of the tool description object, the authorization subject matches the authentication context, and when the authorization record contains parameter constraints, the target object composed of the name field, tool input parameters and authentication context satisfies the parameter constraints.

5. The user authorization method for a multi-tenant agentic engine according to claim 4, characterized in that, Parameter constraints include matching logic and at least one matching item; the matching logic is divided into "AND" and "OR", and the matching item includes path, operator and target value; When the authorization record contains parameter constraints, determine whether the target object satisfies the parameter constraints, including the following steps: For each match, retrieve the value from the target object based on its path, and determine whether the retrieved value matches the target value based on the operator: If so, the target object matches that match; If not, the target object does not match the match item; Determine whether the target object meets the parameter constraints based on the matching logic: When the matching logic is "AND", the target object is considered to satisfy the parameter constraint if and only if the target object matches all matching items; otherwise, the target object is considered to not satisfy the parameter constraint. When the matching logic is "OR", the target object is determined to not satisfy the parameter constraints if and only if the target object does not match any of the matching items; otherwise, the target object is determined to satisfy the parameter constraints.

6. The user authorization method for a multi-tenant agentic engine according to claim 1, characterized in that, The authorization record also includes the execution action. The execution action of static authorization record is divided into allow call and deny call. The execution action of default authorization record, temporary authorization record and long-term authorization record is allow call. Based on the screening results and tool call information, the following call decision is output, including the following steps: Determine if a static authorization record exists and its action is to deny the call: If so, output the call decision as "reject"; If not, then determine whether there is a static authorization record and whether its execution action is to allow the call; Determine if a static authorization record exists and its action is to allow the call: If so, output the call decision as allowed; If not, determine whether the following conditions are met simultaneously: the query strategy field of the current tool description object is not "administrator only", or there is a default authorization record or a long-term authorization record. Determine if the following conditions are met simultaneously: the query strategy field of the current tool description object is not set to "administrator only", or a default authorization record or a long-term authorization record exists: If so, the output call decision is allowed; If not, determine whether the following conditions are met simultaneously: the solicitation strategy field of the current tool description object is not "administrator authorization only", there is a temporary authorization record and it has not been consumed; Determine if the following conditions are met simultaneously: the solicitation strategy field of the current tool description object is not "administrator-only authorization", a temporary authorization record exists and has not yet been consumed: If so, the output call decision is allowed and the temporary authorization record is marked as consumed; If not, the call decision will be output according to the solicitation policy field: when no solicitation is required, the call decision will be allowed; when solicitation is used for the first time, the call decision will be required to solicit the user and allow the user to choose to allow this time or always allow; each time solicitation is invoked, the call decision will be required to solicit the user and allow the user to choose to allow this time only; when only the administrator authorizes, the call decision will be denied.

7. The user authorization method for a multi-tenant agentic engine according to claim 1, characterized in that, Also includes: When outputting a call decision, the output call decision information is recorded in a pre-defined audit event table; When a pop-up window solicits user feedback, the user's feedback information is recorded in a pre-defined audit event table; When an authorization record is created, the authorization record information is recorded in a pre-defined audit event table.

8. A user authorization device for a multi-tenant agentic engine, characterized in that, It includes a tool call information acquisition module, an authorization record processing module, a call decision output module, a call decision response module, and a pop-up inquiry and processing module; The tool call information acquisition module is used to acquire tool call information based on user requests; the tool call information includes authentication context, tool description object, and tool input parameters; The tool description object includes a name field and a solicitation strategy field. The solicitation strategy field is divided into no solicitation required, solicitation on first use, solicitation on every call, or administrator authorization only. The authorization record processing module is used to load and filter authorization records that match the tool call information from the preset authorization storage; the authorization records are divided into static authorization records preset by the administrator before the request, default authorization records preset by the user before the request, temporary authorization records written by the user in the dialog, and long-term authorization records. The decision output module is used to output a call decision based on the filtering results and tool call information. The call decision is divided into allow, deny, or require consultation with the user; The call decision response module is used to respond to the call decision output. When the call decision is allowed, the tool call is executed; when the call decision is denied, a permission-unauthorized message is returned. When the decision requires consulting the user, a pop-up window will be displayed to consult the user. The pop-up consultation and processing module is used to create authorization records and respond based on user feedback when a pop-up consultation is requested: when the user feedback is "allow this time", a temporary authorization record is created based on the tool call information and stored in the authorization storage, and the authorization record is reloaded and filtered to output and respond to the call decision; when the consultation strategy field is "first-time use consultation" and the user feedback is "always allow", a long-term authorization record is created based on the tool call information and stored in the authorization storage, and the authorization record is reloaded and filtered to output and respond to the call decision; when the user feedback is "deny" or "timeout", "no permission" information is returned.

9. An electronic device, comprising: At least one processor and a memory; wherein the memory stores computer-executable instructions; characterized in that, when the at least one processor executes the computer-executable instructions stored in the memory, the at least one processor performs the user authorization method of the multi-tenant Agentic engine as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor, it controls the device containing the computer-readable storage medium to perform the user authorization method of the multi-tenant agentic engine as described in any one of claims 1 to 7.

Images