Intelligent agent dynamic permission management method and electronic device

Abstract

The present application relates to the field of intelligent agent permission management, and particularly relates to an intelligent agent dynamic permission management method and an electronic device. The method comprises the following steps: receiving a task request; parsing the task request to obtain a task purpose, a required data type and a required tool; calculating a task risk score according to the task purpose, the required data type, the required tool and role data of the intelligent agent; matching task-type permission data to generate a task-type permission data packet according to the task risk score and the role data; and limiting the function of the intelligent agent according to the task-type permission data packet. The present application realizes minimum permission, continuous authorization and traceable management during multi-intelligent agent cooperation and tool chain execution.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent permission control technology, and in particular to a method and electronic device for dynamic permission control of intelligent agents. Background Technology

[0002] AI Agents are intelligent entities built upon large-scale language models. They can autonomously plan tasks, invoke external tools, access enterprise data, and collaborate with other agents based on task objectives. They are widely used in areas such as customer service, data aggregation, report generation, document drafting, program assistance, human resource processes, financial processes, and operational monitoring. As enterprises undergo intelligent transformation, AI Agents have evolved from simple dialogue interactions into complex systems capable of automatically executing external operations under certain conditions. Their application scenarios are constantly expanding, creating an urgent need for access control and security governance.

[0003] Existing enterprise information system access control solutions primarily rely on human user accounts combined with role groups, fixed API keys, or service accounts for access control. This approach predefines static permission sets for different roles or services. When an AI Agent performs a task, it directly applies the fixed permissions of its assigned role or associated service account to determine which data resources the Agent can access and which tool interfaces it can invoke.

[0004] However, this fixed-role-based access control model struggles to effectively address the dynamic risks that AI agents may generate in each task. The same AI agent often requires differentiated data scope, tool permissions, approval conditions, and accountability depending on the task content, security level, and scope of impact. Static permissions either grant overly broad permissions, leading to security vulnerabilities, or rigidly restrictive permissions hinder automated task execution, failing to achieve refined control tailored to the specific risks of each task.

[0005] Another approach is to use existing workflow automation and agent orchestration systems. These systems focus on task assignment, process efficiency optimization, or model performance improvement, and can connect multiple agents to execute a predetermined workflow under certain conditions. They typically bind service accounts or general interface permissions to workflows to ensure smooth execution.

[0006] While this approach can improve the efficiency of automating multi-step tasks, it rarely generates one-time, time-limited, data-scope-limited, tool-limited, and approvable / retrospective exclusive permissions for each task in real time. Furthermore, such systems lack real-time behavior monitoring mechanisms based on factors such as unauthorized attempts, exposure of sensitive data, external system influences, financial or legal compliance risks during execution, making it difficult to degrade the agent's privileges, suspend the task, or automatically transfer it to manual approval in the event of a risk.

[0007] With the development of multi-agent collaborative architectures, a main task can be broken down into multiple subtasks and assigned to different agents for execution. Existing systems typically use shared permissions for workflows, service accounts, or main tasks, lacking a permission derivation mechanism for inheriting, tailoring, and risk recalculating permissions from the main task to subtasks. They also lack independent management of the permission boundaries and lifecycles of each agent, which can easily lead to the unnecessary propagation of main task permissions to multiple agents, resulting in problems such as unauthorized access across subtasks, permission residues, and unclear attribution of responsibility. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide a method for dynamic permission control of intelligent agents, so as to realize dynamic permission control of intelligent agents.

[0009] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: Receive task requests; parse task requests to obtain task objectives, required data types, and required tools; calculate task risk scores based on task objectives, required data types, required tools, and agent role data; match task-type permission data with task risk scores and role data to generate task-type permission data packages; restrict agent functions based on task-type permission data packages.

[0010] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to perform the following steps: Receive task requests; parse task requests to obtain task objectives, required data types, and required tools; calculate task risk scores based on task objectives, required data types, required tools, and agent role data; match task-type permission data with task risk scores and role data to generate task-type permission data packages; restrict agent functions based on task-type permission data packages.

[0011] The beneficial effects of this invention are as follows: This invention receives task requests, parses the task objective, required data type, and required tools, calculates the task risk score based on the agent's role data, and then generates a task-based permission data package, thereby restricting the agent's functions accordingly. Compared with existing static permission management schemes that use fixed roles or service accounts, this invention can generate permission data packages that match the task risk in real time for each task, avoiding the security risks or rigid permissions that restrict automated task execution caused by overly broad static permissions. Furthermore, compared with existing workflow automation systems, this invention dynamically generates one-time, time-limited, data-scope-limited, and tool-limited exclusive permissions based on the task risk score, achieving refined control that matches specific task risks and improving the flexibility and security of permission management. Attached Figure Description

[0012] Figure 1 A flowchart illustrating the steps of a dynamic permission control method for an intelligent agent provided in an embodiment of the present invention; Figure 2 This invention provides a schematic diagram of an enterprise AI Agent dynamic governance system architecture for a method of dynamic access control for intelligent agents, as provided in an embodiment of the present invention. Figure 3 A flowchart of an AI Agent dynamic governance method for a dynamic permission control method for intelligent agents provided in an embodiment of the present invention; Figure 4 This invention provides a flowchart of a task-type permission packet verification process before a tool call in a dynamic permission control method for intelligent agents, as provided in an embodiment of the invention. Figure 5 This is a schematic diagram of the internal functional architecture of an AI Agent for a dynamic permission control method for intelligent agents provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention; Figure 7 This is a schematic diagram illustrating the process of deriving a main task permission data packet from multiple sub-task permission data packets and performing cross-agent data exchange verification in a dynamic permission control method for intelligent agents provided in an embodiment of the present invention. Figure 8 This is a schematic diagram illustrating the process of continuous authorization based on context version, risk score, and tool execution result during the execution of a toolchain for a dynamic permission control method for intelligent agents provided in an embodiment of the present invention. Detailed Implementation Definitions:

[0013] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0014] Existing technologies rarely generate one-time, time-limited, data-scope-limited, tool-limited, and approvable / retrospective exclusive permission scopes for each task in real time. Furthermore, such systems lack real-time behavior monitoring mechanisms during execution based on factors such as unauthorized attempts, exposure of sensitive data, external system influences, financial flow risks, or legal compliance risks. This makes it difficult to degrade the agent's privileges, suspend the task, or automatically transfer it to manual approval in the event of a risk.

[0015] Furthermore, existing multi-agent systems typically trust task results, context information, and intermediate data transfer between agents by default, rarely re-verifying the sender's output permissions, the receiver's access permissions, and data sensitivity levels during each cross-agent data exchange. They also lack field filtering, data minimization, and one-time data exchange authorization mechanisms, making it difficult to meet the requirements of least privilege and zero-trust governance.

[0016] Meanwhile, when an agent executes a chain of tool calls, the execution result of the previous tool may introduce new sensitive data, external system influences, or privilege escalation requirements, causing the context and risk status of subsequent tasks to continuously change. If fixed permissions are only generated at the start of a task, or if only the presence of a tool in the allowed list is verified, it is impossible to continuously update risks and permissions based on the tool execution results, and it is also difficult to form verifiable execution evidence that is interconnected with the context version, tool execution results, and chain of responsibility.

[0017] To at least address the aforementioned issues, this invention parses task requests to obtain the task objective, data type, and tools, and calculates the task risk score by combining it with agent role data. Then, it dynamically matches task-type permission data packets corresponding to the risk level. In this way, it can achieve accurate matching of permissions and risks for agents in each task, effectively balancing security and automated execution efficiency.

[0018] The following describes in detail a method for dynamic permission control of intelligent agents according to the present invention, with reference to the appendix. Figure 1 This includes steps 110 to 150: Step 110: Receive a task request; wherein, the task request may be instruction data submitted by the user or enterprise system to the AI ​​Agent governance system, which includes the task purpose, required data types, required tools, and scope of task impact.

[0019] Step 120: Parse the task request to obtain the task objective, required data type, and required tools; wherein, the task objective can be a description of the goal that the task request expects to achieve; the required data type can be the type of enterprise data that needs to be accessed to execute the task; and the required tools can be the enterprise system tools, APIs, databases, or external services that need to be called to execute the task.

[0020] Step 130: Calculate the task risk score based on the task objective, required data types, required tools, and agent role data. Here, the agent (AI Agent) is an autonomous software entity deployed in an enterprise environment that can receive tasks, plan autonomously, invoke tools, access data, and generate execution results. The agent's role data can be the data pre-registered in the Agent registration module, including Agent ID, Agent role, capability description, preset tool scope, preset data scope, responsible party, and preset risk level. The task risk score can be a value calculated based on the task attributes and agent role data, used to quantify the degree of risk that may arise during the task's execution.

[0021] Step 140: Based on the task risk score and role data, match task-type permission data to generate a task-type permission data package; wherein, the task-type permission data package can be an authorization data structure bound to a specific task, including at least one of the following: a list of allowed tools, a list of prohibited tools, a data access scope, a scope of actions, a validity period, a responsible party, an execution mode, and an audit strategy.

[0022] Task-based permission data can be selected as rule or policy data used to generate task-based permission data packages.

[0023] Step 150: Restrict the agent's functions according to the task-type permission data packet; wherein, restricting the agent's functions means that during task execution, the agent can only perform operations within the data range, tool range, action range, and validity period allowed by the task-type permission data packet, and operations exceeding the permission range will be blocked.

[0024] As described above, this invention receives task requests, parses the task objective, required data types, and required tools, calculates a task risk score based on the agent's role data, and then generates a task-based permission data package to restrict the agent's functionality accordingly. Compared to existing static permission management schemes that use fixed roles or service accounts, this invention can generate permission data packages that match the task risk in real time for each task, avoiding security risks caused by overly broad static permissions or rigid permissions that limit the automated execution of tasks. Furthermore, compared to existing workflow automation systems, this invention dynamically generates one-time, time-limited, data-scope-limited, and tool-limited permissions based on task risk scores, achieving refined control that matches specific task risks and improving the flexibility and security of permission management.

[0025] In one embodiment of this application, step 130 involves calculating a task risk score based on the task objective, required data types, required tools, and agent role data, including steps 210 to 240: Step 210: Obtain multiple risk factors corresponding to the task objective, required data types, required tools, and agent role data; among them, risk factors can be selected as independent factors affecting the task risk score, including data sensitivity, tool risk level, degree of influence of external systems, degree of influence of cash flow, legal compliance risk, degree of autonomous decision-making of the agent, and historical anomaly factors.

[0026] Step 220: Assign weights to each risk factor; the weights can be values ​​set by the enterprise for each risk factor based on industry attributes, data protection requirements, internal control policies, legal compliance requirements and business scenarios, and are used to reflect the relative importance of each factor in the risk score calculation.

[0027] Step 230: Obtain the risk value of each risk factor; wherein, the risk value can be selected as the quantitative value of each risk factor in a specific task. For example, the data sensitivity risk value is determined according to the data category involved in the task, and the tool hazard level risk value is determined according to whether the tool has write, delete, send, pay or change permissions.

[0028] Step 240: The risk values ​​of each risk factor are weighted and summed to obtain the task risk score; The task risk score is calculated as follows: RiskScore = w1 × Data Sensitivity Risk Value + w2 × Tool Hazard Level Risk Value + w3 × External System Impact Risk Value + w4 × Cash Flow Impact Risk Value + w5 × Legal Compliance Risk Value + w6 × Autonomous Decision-Making Degree Risk Value + w7 × Historical Anomaly Factor Risk Value.

[0029] As described above, this invention calculates task risk scores based on task objectives, required data types, required tools, and agent role data. By weighted summation of the risk values ​​of each risk factor, it achieves a quantitative assessment of task risk, thus providing a precise basis for the subsequent dynamic generation of task-type permission packets. This solves the problem in the prior art where permission control is mismatched with the actual risk of the task due to a lack of targeted risk assessment.

[0030] In one embodiment of this application, step 140 involves generating a task-type permission data package based on the task risk score and role data, including steps 310 to 320: Step 310: Based on the agent's role data and task risk score, determine the permitted tool list, prohibited tool list, responsible party, execution mode, and audit strategy. The permitted tool list can be selected as a set of tools or APIs that the agent can call in this task; the prohibited tool list can be selected as a set of tools or APIs that the agent is prohibited from calling in this task; the responsible party can be selected as the human responsible party or approver for the agent; the execution mode can be selected as the operation mode of the agent when performing the task, including automatic execution mode, suggestion mode, draft mode, or approval mode; the audit strategy refers to the types of events that need to be recorded and the storage strategy.

[0031] Step 320: Generate a task-type permission data package based on the list of allowed tools, the list of prohibited tools, the responsible party, the execution mode, and the audit strategy; wherein, the task-type permission data package includes Agent ID, Task ID, list of allowed tools, list of prohibited tools, data scope, action scope, risk score, execution mode, approval conditions, responsible party, validity period, and audit strategy.

[0032] As described above, this invention determines the list of permitted tools, the list of prohibited tools, the responsible party, the execution mode, and the audit strategy based on the role data and task risk score of the intelligent agent. Then, it generates a task-type permission data package based on the list and strategy. This invention enables the task-type permission data package to accurately match the minimum necessary permissions and responsibilities of the AI ​​Agent in a single task, thereby overcoming the technical defects of traditional static permissions that cannot adapt to the dynamic calling of toolchains and autonomous decision-making of AI Agents, and realizing fine-grained control and responsibility binding of task-level permissions.

[0033] In one embodiment of this application, step 140 involves matching task-type permission data with task risk score and role data to generate a task-type permission data package, including steps 410 to 420: Step 410: Determine whether the task risk score corresponding to the task-type permission data packet is higher than the preset first threshold; wherein, the first threshold can be selected as the enterprise's preset risk score threshold, which is used to distinguish between automatic execution mode and other execution modes.

[0034] Step 420, if yes, then match the execution mode including rules that restrict the agent to only generate preset suggestion content and prohibit the agent from performing external write or send operations, in order to generate a task-type permission data packet; wherein, the preset suggestion content can be selected as the agent can only generate suggestion text or draft text for human reference and must not directly perform external system operations.

[0035] As described above, this invention determines whether the task risk score is higher than a first threshold. When the risk is high, it restricts the intelligent agent to only generate suggested content and prohibits it from writing or sending externally, thereby blocking the unauthorized or data leakage behaviors that high-risk intelligent agents may produce before the task is executed.

[0036] In one embodiment of this application, steps 510 to 520 are also included: Step 510: Determine whether the task risk score is higher than the second threshold, where the second threshold is greater than the first threshold; wherein, the second threshold can be selected as a higher risk score threshold preset by the enterprise, used to trigger manual approval.

[0037] Step 520: If the threshold is higher than the second threshold, the task request is sent to the agent's approval terminal. The approval terminal can be a system terminal used by the responsible party or a human approver, used to review and approve or reject the agent's task execution request. Upon receiving the approval instruction, the agent is allowed to perform operations within the approved scope. For example, the system can first obtain a preset tool and data scope based on the Agent role, then narrow or expand the allowed scope based on the task risk score, and add prohibited tools, approval conditions, or validity period restrictions according to corporate policies. If the task risk score is low, the system can allow the AI ​​Agent to execute automatically within the permission packet; if the task risk score is high, the system can only allow reading data or generating drafts; if the task involves cash flow, deletion, sending external emails, modifying customer information, or highly sensitive data, manual approval can be required or execution can be directly prohibited.

[0038] In step 140, based on the task risk score and role data, task-type permission data is matched to generate a task-type permission data package, including step 1401: Step 1401: In response to receiving the approval instruction returned by the approval terminal, match the execution mode including the rule that allows the agent to perform external write or send operations to generate a task-type permission data packet; As described above, this invention determines whether the task risk score exceeds a second threshold. If so, the task request is sent to the agent's approval terminal. Only after receiving an approval instruction is the execution mode, including rules allowing the agent to perform external write or send operations, matched to generate a task-type permission data packet. Therefore, for tasks involving high-risk operations, this invention can strictly control the agent's external write or send behavior through a manual approval mechanism, preventing the agent from performing operations that may affect external systems without authorization, thereby reducing the risk of data leakage or misoperation caused by the agent's autonomous decision-making.

[0039] In one embodiment of this application, step 150, restricting the agent's functionality based on the task-type permission data packet, includes steps 610 to 640: Step 610: Before each time the agent calls an external preset tool, obtain the agent's tool call request; wherein, the tool call request can be a call request sent by the agent to the tool agent module, including the tool identification code, request parameters, data access range, action type and call time.

[0040] Step 620: Check whether the tool identifier in the tool call request is included in the list of allowed tools or the list of prohibited tools in the task-type permission data packet; wherein, the tool identifier can be an identifier used to uniquely identify enterprise system tools or APIs.

[0041] Step 630: If the tool identifier is included in the prohibited tool list, then the tool call is intercepted; wherein, intercepting the tool call means that the tool agent module refuses to execute the tool call request and writes the interception event into the chain of responsibility record.

[0042] Step 640: If the tool identification code is included in the list of allowed tools, the data access range in the tool call request conforms to the data range of the task-type permission data package, the action type in the tool call request conforms to the action range of the task-type permission data package, and the call time in the tool call request is within the validity period of the task-type permission data package, then the tool call is allowed; wherein, the data range can be selected from the range of allowed data sets, data tables, files, or fields specified in the task-type permission data package; the action range can be selected from the type of allowed action specified in the task-type permission data package, including reading, generating drafts, sending, deleting, making payments, or sending emails; the validity period refers to the expiration time of the task-type permission data package.

[0043] Optionally, before the agent invokes the tool, the tool identification code, data range, action type, and invocation time are verified; if the verification fails, the tool invocation is blocked; if the verification passes, the tool invocation is allowed; and execution evidence corresponding to the tool invocation is generated.

[0044] When an agent executes multiple consecutive tool calls, the system retrieves the current task context, tool execution result, newly added data range, and current risk status after each tool call is completed, and recalculates the task risk score.

[0045] The system re-verifies the task-based permission data packet based on the updated risk status and dynamically adjusts the subsequently invoked tools, data access scope, action permissions, and validity periods. This ensures that subsequent tool calls are executed based on the latest permission status, rather than continuously using the task-based permission data packet generated at the start of the task. (See attached document.) Figure 8After the previous tool completes its execution, a new context version is generated, and the new context version drives subsequent permission verification.

[0046] If the tool execution results in the addition of highly sensitive data, abnormal inference results, cross-system data association, continuous failures, permission escalation requirements, or changes in enterprise governance strategies, the system will regenerate or update the task-type permission data package and synchronously update the execution strategies of subsequent toolchains.

[0047] When the recalculated task risk score exceeds a preset threshold, the system will perform at least one of the following actions: terminate remaining tool calls, revoke call permissions for tools not yet executed, switch to suggestion mode or approval mode, reschedule tool call order, revoke permissions, or notify manual approval. When the task is completed or the permission validity period expires, the task-type permission data packet will become invalid.

[0048] Optionally, after each tool call is completed, the system generates corresponding tool execution evidence, which includes at least the tool identification code, tool version, input digest, output digest, execution time, permission identifier, task risk score, context version, and execution status.

[0049] The tool execution evidence is associated with the corresponding task-type permission data package and chain of responsibility record, which is used for subsequent anomaly analysis, responsibility tracking, permission reconstruction and verification of whether a tool call is executed according to the valid permission status at that time.

[0050] As described above, the present invention compares in real time whether the tool identification code, data access range, action type and call time conform to the task-type permission data packet before each tool call, thereby intercepting unauthorized requests before the AI ​​Agent calls enterprise system tools. This solves the technical problem in the prior art that the AI ​​Agent may unauthorizedly call tools or access sensitive data due to model illusion or autonomous decision-making.

[0051] In one embodiment of this application, steps 710 to 730 are also included: Step 710: Decompose the task request into multiple sub-task requests; wherein, the sub-task requests may be sub-task instructions that can be independently allocated and executed and split from the original task request.

[0052] In this embodiment, after the main task is split, the permissions of each subtask are inherited and trimmed according to the main task permission data package to generate the corresponding subtask permission data package.

[0053] The permission derivation process includes: inheriting the data scope, tool scope, and action scope allowed by the main task; deleting permissions unrelated to the subtask based on the subtask objective; further reducing the accessible data scope and callable tools based on the subtask risk level; adding subtask-specific restrictions based on corporate governance strategies; recalculating the subtask risk score and generating new validity periods, approval conditions, and responsibility attribution information.

[0054] Each subtask permission data packet has an independent task identifier, permission identifier, and lifecycle, and is only valid during the execution of the corresponding subtask. When a subtask is completed, times out, or an exception occurs, the corresponding subtask permission data packet automatically becomes invalid without affecting other subtask permission data packets.

[0055] In some implementations, the subtask permission data packet retains the association identifier of the main task permission data packet, forming a permission derivation tree for subsequent permission tracking, responsibility attribution, and anomaly backtracking. (See Appendix) Figure 7 The main task permission data packet is used by the permission derivation module to generate multiple sub-task permission data packets with independent permission boundaries.

[0056] Step 720: Generate a corresponding subtask permission data packet for each subtask request; wherein, the subtask permission data packet refers to a task-type permission data packet generated for a specific subtask, which includes the list of allowed tools, the list of prohibited tools, the data range, the action range, the validity period, and the approval conditions for that subtask.

[0057] Step 730: Restrict the functions of the corresponding AI agents according to the permission data packets for each subtask; whereby the corresponding AI agent refers to the AI ​​Agent assigned to execute a specific subtask. Restricting the functions of the corresponding AI agents includes: The agent is only permitted to call enterprise tools or APIs listed in the allowed_tools list within its subtask permission package, and is prohibited from calling tools listed in the denied_tools list; or the agent is only permitted to access data tables, datasets, field ranges, and time intervals specified in the data_scope within its subtask permission package, and is prohibited from accessing data outside the scope; or the agent is only permitted to execute action types specified in the action_scope within its subtask permission package (e.g., reading, generating drafts), and is prohibited from executing unauthorized actions (e.g., sending, deleting, making payments); or the agent is only permitted to call tools within the validity period specified in the subtask permission package, and after the timeout, the call request will be blocked by the tool agent module.

[0058] For example, the mapping rules can be as follows: If the Agent role is Customer Service Agent, the task type is Order Inquiry, and the risk score is <30, Then allowed_tools = [order query tool, customer basic information query tool, customer service knowledge base retrieval tool], denied_tools=[Refund tools, payment tools, customer information modification tools, batch export tools], data_scope=[Current Customer, Current Order, Non-sensitive Fields, Order Data for the Last 180 Days], action_scope=[Read, Generate Draft Reply], expires_at = 30 minutes after the task starts approval_required = false.

[0059] In some implementations, when multiple agents need to exchange task results, context information, inference results, or intermediate data, the system does not allow data sharing by default, but instead re-executes permission verification through the cross-agent data verification module.

[0060] The system obtains a data exchange request between a first agent and a second agent; verifies the data output permissions, data access permissions, data scope, task stage, and data sensitivity level of both parties; upon successful verification, it trims, filters, anonymizes, or de-identifies the data to be exchanged and generates a data exchange authorization token; it allows data exchange based on the data exchange authorization token and invalidates it upon completion of the exchange or expiration of its validity period. Specifically, the verification includes: verifying whether the sending agent has data output permissions; verifying whether the receiving agent has corresponding data access permissions; verifying whether the data to be exchanged falls within the data scope jointly authorized by both parties; verifying whether the current task stage allows the data exchange; and verifying whether the data sensitivity level complies with the enterprise governance strategy.

[0061] If any verification condition is not met, the system will refuse the data exchange and record the abnormal event. At the same time, it will perform at least one of the following actions: reduce the relevant agent's permissions, re-plan the task process, suspend the corresponding sub-task, or switch to manual approval mode.

[0062] When the verification is successful, the system performs data trimming, field filtering, anonymization, or desensitization on the data to be exchanged based on the data sensitivity level, so that the receiving agent only obtains the minimum necessary information to complete the current subtask.

[0063] The system can also generate a unique data exchange authorization token for each cross-agent data exchange. The data exchange authorization token is bound to the sending agent, the receiving agent, the data range, the task identifier, and the validity period, and expires immediately after the data exchange is completed, timeout, or the task status changes.

[0064] As described above, this invention decomposes task requests into multiple sub-task requests and generates corresponding sub-task permission data packets for each sub-task request, enabling intelligent agents corresponding to different sub-tasks to perform operations within their respective independent permission boundaries. This avoids the risks of cross-sub-task permission overreach and data leakage, and achieves refined permission control in multi-agent collaborative scenarios.

[0065] In one embodiment of this application, steps 810 to 820 are further included: Step 810: Determine whether the task request is completed, whether the validity period of the task-type permission data packet corresponding to the task request exceeds the preset period, or whether the agent has engaged in abnormal behavior; wherein, the preset period can be selected as the maximum validity period of the task-type permission data packet; abnormal behavior includes the agent attempting to access data beyond the data range, attempting to call unauthorized tools, attempting to execute unauthorized actions, outputting sensitive information, the task execution result deviating from the task purpose, multiple tool call failures, or the transfer of data between agents exceeding the authorized scope.

[0066] Step 820: If the task is completed, the validity period exceeds the preset period, or the agent exhibits abnormal behavior, the task-type permission data packet corresponding to the task request is invalidated; wherein, invalidating the task-type permission data packet means that the system marks the task-type permission data packet as invalid, and the agent shall no longer be allowed to perform any tool calls or data access based on the data packet.

[0067] As described above, this invention determines whether a task request has been completed, whether the validity period of the task-type permission data packet has exceeded a preset period, or whether the agent has exhibited abnormal behavior. When any of these conditions are met, the permission data packet is invalidated, thus automatically revoking permissions upon task completion, permission expiration, or agent malfunction. Compared to existing technologies where static permissions are valid for extended periods and cannot be revoked promptly upon task completion or in case of anomalies, this invention effectively prevents agents from continuing to access enterprise system tools or data outside the task scope or under abnormal conditions, reducing the risk of data leakage and unauthorized operations due to residual permissions or abnormal behavior.

[0068] In one embodiment of this application, step 910 is also included: Step 910: According to the task request, during the execution of a single task request, when it is detected that the agent's behavior does not conform to the task-type permission data packet corresponding to the task request or the task risk score changes, the task-type permission data packet of the agent is dynamically adjusted to restrict the agent's functions; wherein, the dynamic adjustment includes reducing the range of accessible data, removing callable tools, shortening the validity period, switching to draft mode or switching to manual approval mode.

[0069] As described above, this invention dynamically adjusts the task-based permission packets of the AI ​​Agent according to task requests. During the execution of a single task, if the agent's behavior is detected as not conforming to the permission packet or if the task risk score changes, the agent's functionality can be restricted in real time. Compared to traditional static permission management, this invention, taking into account the characteristics of AI Agents such as autonomous decision-making, chained tool calls, and model illusions, achieves task-level dynamic permission control and real-time interception and verification before calls, effectively reducing the technical risks of unauthorized operations and data leakage when enterprises import AI Agents.

[0070] Thus, the task risk score, context version, task-type permission data package, and tool execution results form a closed-loop governance relationship: each tool execution may generate a new context version and risk state, the new risk state is used to re-verify or generate permission data packages, and the updated permission data packages then restrict subsequent tool calls and cross-agent data exchanges.

[0071] In one embodiment of this application, when a task needs to be completed collaboratively by multiple intelligent agents, the system splits the main task into multiple sub-tasks, and performs inheritance and trimming of permissions based on the main task permission data package, the task objectives, data scope, tool requirements and risk levels of each sub-task, generating sub-task permission data packages with independent task identifiers, permission identifiers and lifecycles, so as to form a traceable permission derivation relationship.

[0072] In one embodiment of this application, when multiple agents need to exchange task results, context information, inference results, or intermediate data, the system re-verifies the data output permissions of the sending agent, the data access permissions of the receiving agent, the data scope jointly authorized by both parties, the task stage, and the data sensitivity level. It can also perform data trimming, field filtering, anonymization, or desensitization processing on the data to be exchanged, and generate a one-time data exchange authorization token bound to the sending agent, the receiving agent, the data scope, the task identifier, and the validity period.

[0073] In one embodiment of this application, when an agent executes multiple consecutive tool calls, the system obtains the tool execution result, current task context, newly added data range, and risk status after each tool call is completed, generates a new context version, recalculates the task risk score, and updates the task-type permission data package; when the updated risk exceeds a preset threshold, the system terminates subsequent tool calls, revokes permissions, switches the execution mode, or transfers to manual approval, and generates tool execution evidence associated with permission identifiers, risk scores, and context versions for each tool call.

[0074] This invention limits the propagation of main task permissions to subtasks through permission derivation relationships, controls data flow between agents through cross-agent data verification and one-time data exchange authorization tokens, and achieves continuous authorization during toolchain execution through closed-loop updates of context version, task risk score, and task-type permission data packets. Therefore, it can reduce the risks of permission proliferation, cross-agent data leakage, permission mismatch after context changes, and untraceable execution processes in multi-agent collaboration and continuous tool invocation scenarios.

[0075] The intelligent agent dynamic permission control method and electronic device described above are applicable to the dynamic governance of enterprise AI agents, and will be described in detail below through specific implementation methods.

[0076] In this embodiment of the invention, the enterprise AI Agent dynamic governance system is deployed in a hybrid cloud environment, connecting the enterprise's internal identity management system, ERP database, financial system, customer service system, email system, and various API tools. The system hardware includes multiple application servers, database servers, and log storage servers, which respectively host the governance module, business data, and chain of responsibility records.

[0077] See attached document Figure 2 The system software architecture consists of the following functional modules: The task parsing module receives task requests and parses the task objective, required data types, required tools, and scope of impact. For example, it executes steps 110 and 120 above.

[0078] The risk assessment module is used to calculate the task risk score based on multi-dimensional risk factors and switch the execution mode accordingly. For example, execute step 130 above.

[0079] The Agent registration module is used to maintain the identity, role, capability description, default tool scope, default data scope, responsible person, and default risk level of the AI ​​Agent.

[0080] The permission package generation module is used to dynamically generate one-time, time-limited, and data / tool / action-specific permission packages based on task risk scores, Agent roles, and corporate governance policies. For example, execute step 140 above.

[0081] The permission derivation module is used to perform permission inheritance, trimming, and risk recalculation based on the main task permission data package and the task objectives, data scope, tool requirements, and risk levels of sub-tasks, generating permission data packages for each sub-task and permission derivation relationship tree.

[0082] The Agent orchestration module is used to select one or more AI Agents to perform tasks and can assign subtasks.

[0083] The cross-agent data verification module is used to verify sending permissions, receiving permissions, jointly authorized data scope, task stage and data sensitivity level before exchanging task results, context information or intermediate data between agents, and to generate a one-time data exchange authorization token.

[0084] The tool proxy module acts as an intermediary layer between the AI ​​Agent and enterprise tools or databases, intercepting requests and verifying authorization packets before each tool invocation. For example, it executes step 150 above.

[0085] The context version management module is used to generate new context versions when tool call results, agent input / output, or task risk status changes, and to trigger the re-verification or update of task risk scores and task-type permission data packages.

[0086] The tool execution evidence module is used to generate tool execution evidence associated with permission identifiers, task risk scores, and context versions for each tool call, and to write the tool execution evidence into the chain of responsibility record.

[0087] The manual approval module is used to transfer tasks or subtasks to designated approvers when necessary.

[0088] The behavior monitoring module is used to continuously monitor the AI ​​Agent's input, output, tool calls, data access, and data transfer between Agents.

[0089] The Chain of Responsibility Record module is used to record an immutable chain of responsibility that includes the preceding and following hash chains.

[0090] The exception handling module is used to block, demote, suspend, reassign, or transfer to manual approval when an exception is detected.

[0091] See attached document Figure 3 In this embodiment, the complete dynamic governance process of a task to “summarize the second quarter invoices and generate a financial summary for the board of directors” is described in detail.

[0092] A. The user submits a task request through the company's internal task system: "Summarize the second quarter invoices and generate a board financial summary." This corresponds to step 110 above.

[0093] The task parsing module receives the task request and performs semantic parsing. The parsing result determines that the task objective is to generate a financial summary report, the required data type is invoice data, the required tools include invoice query tools and report generation tools, and the scope of the task is defined as the internal finance department, not involving external transmission or fund operations. This corresponds to step 120 above.

[0094] B. The task parsing module passes the parsed task attributes to the risk assessment module and the agent orchestration module. The agent orchestration module queries the agent registration module to confirm that the task is being executed by a registered financial processing AI agent. The agent registration module returns the agent's registration data, including the agent ID "finance_agent_01", the agent role "finance agent", the responsible person "A", and the default risk level "medium". Referring to Table 1, the registration data includes the following fields: Table 1

[0095] C. The risk assessment module calculates the task risk score based on task attributes and Agent role data. The system pre-sets a set of configurable weights. For the financial scenario, the weights are set as follows: data sensitivity weight w1 = 0.20, tool risk level weight w2 = 0.20, external system influence weight w3 = 0.10, cash flow influence weight w4 = 0.25, legal compliance risk weight w5 = 0.15, degree of autonomous decision-making weight w6 = 0.05, and historical anomaly factor weight w7 = 0.05. This corresponds to step 130 above.

[0096] The scoring process for each risk factor is as follows: Data Sensitivity Factor: 70 points because the task involves all invoice amounts and supplier information; Tool Risk Level Factor: 40 points because the tool used includes report export functionality but lacks deletion or payment functionality; External System Impact Factor: 20 points because the task only affects internal departments; Cash Flow Impact Factor: 0 points because it does not involve payment, refund, or other operations; Legal Compliance Risk Factor: 30 points because the summary report may be used for board decisions, requiring data accuracy and compliance; Autonomous Decision-Making Degree Factor: 50 points because the financial agent needs to independently summarize data and generate drafts.

[0097] Historical anomaly factors are dynamically evaluated by the system based on the agent's anomaly records over the past 30 days. The evaluation uses the following formula: Historical anomaly factor = min(100, Σ(anomaly severity score × time decay coefficient × recurrence coefficient)).

[0098] The anomaly severity score can be set according to the anomaly type. For example, tool call failure or formatting errors can be set to low severity, attempts to access data outside the data range can be set to medium-high severity, and attempts to call unauthorized tools, output sensitive data, trigger cash flow or external system actions can be set to high severity. The time decay coefficient is used to reduce the impact of earlier anomalies on the risk of the current task; for example, anomalies within the last 7 days have a higher weight, while anomalies within the last 30 days have a lower weight. The recurrence coefficient is used to reflect that when the same anomaly occurs repeatedly for the same agent or the same type of task, the risk score should be increased.

[0099] Historical anomaly factors can also be calculated using a hierarchical table. For example: Table 2

[0100] The severity of the anomaly can be further set according to the anomaly type as follows: Table 3

[0101] The financial agent has only experienced one low-severity anomaly in the past 30 days. The tool call parameter format is incorrect. Its anomaly severity score is 5. The time decay coefficient is 0.7 based on the range of 8 to 30 days. The recurrence coefficient is 1.0. Therefore, the historical anomaly factor calculation result is 5 × 0.7 × 1.0 = 3.5. The system rounds it to 4.

[0102] The final task risk score is calculated using a weighted formula: RiskScore = w1×Data Sensitivity + w2×Instrument Risk Level + w3×External System Impact + w4×Cash Flow Impact + w5×Law Compliance Risk + w6×Degree of Autonomous Decision-Making + w7×Historical Anomaly Factors

[0103] Specifically, the formula is: 70×0.20 + 40×0.20 + 20×0.10 + 0×0.25 + 30×0.15 + 50×0.05 + 4×0.05 = 14 + 8 + 2 + 0 + 4.5 + 2.5 + 0.2 = 31.2. The system categorizes the score 31.2 into the suggested range of 31 to 60.

[0104] Table 4

[0105] Table 5

[0106] D. The permission package generation module generates a one-time task-specific permission package based on the task risk score of 31.2, the Agent role, and the preset enterprise mapping rule. The enterprise mapping rule specifies that when a finance Agent executes a report-type task with a risk score in the range of 31 to 60, the execution mode is "Recommendation Mode", which only allows the use of query and internal report tools, prohibits any payment, deletion or external sending tools, restricts the data scope to the specified period and non-sensitive fields, limits the actions to reading and generating internal drafts, and requires manual approval. This corresponds to step 140 described above.

[0107] According to this rule, the system generates the following task-specific permission package: { "agent_id": "finance_agent_01", "task_id": "TASK-20260624-001", "allowed_tools": ["Invoice Query Tool", "Report Generation Tool", "Internal Financial Knowledge Base Retrieval Tool"], "denied_tools": ["Payment Tool", "Invoice Deletion Tool", "Bank Account Modification Tool", "External Email Sending Tool"], "data_scope": { "time_range": "2026-04-01 to 2026-06-30", "region": "The department to which the Agent belongs", "allowed_fields": ["Invoice amount", "Date", "Supplier category", "Tax amount", "Project number"], "excluded_fields": ["Bank account number", "Full taxpayer identification number", "Personal ID number"] }, "action_scope": ["Read", "Generate internal draft"], "risk_score": 31.2, "execution_mode": "Recommendation Mode", "approval_required": true, "human_owner": "Person A", "expires_at": "2026-06-24T11:00:00Z", "audit_policy": "Record all tool calls and outputs" } This permission package is valid for 30 minutes after the task is created and is bound to the task identifier. It will expire after the task is completed or the timeout period.

[0108] Table 6

[0109] E. The Agent orchestration module assigns the financial agent to the task. When the financial agent begins executing the task, its internal task planning unit breaks it down into two sub-steps: querying invoices and generating reports. When the financial agent first attempts to call the "Invoice Query Tool," the tool agent module intercepts the call request. The tool agent module obtains the aforementioned permission package through the task identifier, compares the tool name, the data tables and fields involved in the request parameters one by one to see if they are within the allowed_tools list and the allowed fields in data_scope, and verifies that the call time has not exceeded expires_at. This corresponds to step 150 above.

[0110] See attached document Figure 4 Upon comparison, the call conforms to the permission package, and the tool agent module allows it. The call result (second quarter invoice details) is returned to the finance agent. The tool agent module also writes this call event into the chain of responsibility record.

[0111] After obtaining the invoice data, the finance agent continues to call the "report generation tool" to generate a report draft. The tool agent module verifies again that the tool is within allowed_tools, and its actions are limited to "generating internal drafts." The call request is compliant, and is allowed and recorded.

[0112] After the invoice query tool completes execution, the system writes the returned invoice field range, query result summary, and execution status into the tool execution evidence, and updates the task context from Context V1 to Context V2. The system then recalculates the risk score based on Context V2 and verifies whether the original task-based permission package is still applicable.

[0113] Once the report generation tool completes, the system regenerates the corresponding tool execution evidence and updates the task context to Context V3. If the tool result contains bank account numbers, personal ID numbers, or other highly sensitive fields excluded by the original permission package, the system increases the task risk score, narrows the scope of subsequent data, and prevents the financial agent from continuing to call the external sending tool; if the risk exceeds the approval threshold, the subsequent steps will be switched to manual approval mode.

[0114] F. The Finance Agent, based on internal reasoning, attempted to further invoke the "External Email Sending Tool," intending to send the draft directly to the Board of Directors. The tool agent module intercepted this call request and compared it with the permission package. The comparison revealed that the "External Email Sending Tool" was in the denied_tools list, and there was no "send" action in the action_scope. The tool agent module determined that the call did not conform to the permission package, immediately blocked the request, and sent this unauthorized attempt event to the exception handling module and the behavior monitoring module.

[0115] The exception handling module, based on a preset strategy, performs the following actions: It upgrades the task's execution mode from "suggestion mode" to "approval mode" and notifies the manual approval module. The manual approval module then pushes the draft to be approved and the task context to the workbench of the responsible person, "A". The behavior monitoring module marks this exception event as "attempt to call an unauthorized tool" and writes it into the chain of responsibility record.

[0116] G. Throughout the task execution, the chain of responsibility recording module continuously generates a chain of responsibility record for each event. Events include task creation, permission package generation, invoice query tool invocation, report generation tool invocation, unauthorized attempts to send external emails, exception handling, and approval notifications. (See attached document.) Figure 5 .

[0117] Each chain of responsibility record is generated according to a fixed field order and a standardized JSON format, including a task identifier, subtask identifier, Agent ID, risk score, permission package hash value, input digest, output digest, tool call record, approval record, exception event, and processing result. The system uses the SHA-256 algorithm to calculate the hash value of each record's standardized content and writes the hash value of the previous chain of responsibility record as the `previous_hash` field into the current record. For example, the `previous_hash` of the first record (task creation) is the system's initial hash value; the `previous_hash` of the second record (permission package generation) is the hash value of the first record; subsequent tool call records are also chained sequentially. This forms a verifiable and complete chain of responsibility where any single point of tampering will result in a mismatch between the hash values ​​before and after the previous record.

[0118] The final hash value of the entire task responsibility chain is stored in the append log system for post-event auditing.

[0119] The method provided in this application embodiment addresses a situation where, although the financial agent generates an incorrect inference about executing an external sending operation during report generation, the tool agent module verifies and blocks the permission package in real time before execution, and automatically transfers the task to manual approval. This mechanism of dynamically generating one-time task-type permission packages and intercepting and verifying them before each tool call effectively avoids unauthorized operations, ensuring that high-risk actions can only be executed after authorized human approval. Furthermore, the hash chain-based responsibility record fully documents the entire task execution process, providing an immutable chain of evidence for post-event auditing and accountability, reducing the risk of data leakage and erroneous decision-making.

[0120] In another embodiment, the customer service agent receives a refund request from a user. The task parsing module identifies operations involving personal data and fund flows, and the risk assessment module calculates a risk score of 72, classifying it as an approval-only operation. The permission package generation module generates a permission package that prohibits the customer service agent from directly calling the refund tool, allowing only order inquiries, draft response generation, and submission for approval. The tool proxy module allows query operations during the customer service agent's execution, blocking any direct refund calls. Finally, the refund is manually completed after approval by a supervisor. The responsibility chain recording module fully records the event chain of query, draft generation, approval, and refund execution. Through the method provided in this embodiment, the system dynamically limits the scope of operations for the customer service agent based on the risk score, ensuring that high-risk operations involving fund flows and personal information must be manually confirmed, reducing the risk of misoperation and privacy leaks.

[0121] In another embodiment, the system receives a task to "analyze the reasons for the sales decline in South China and generate an improvement report." The Agent orchestration module decomposes this task into three sub-tasks, assigning them to a data extraction agent, an analysis agent, and a report writing agent, respectively. The permission package generation module generates an independent permission package for each sub-task: the data agent can only read non-sensitive fields from the original sales table; the analysis agent can only access the de-identified data view; and the report agent can only use the internal report generation tool, and is prohibited from directly accessing the database or sending data externally. The three agents execute sequentially, and the tool agent module verifies their permission packages at each step. Finally, the chain of responsibility recording module associates the permission packages, tool calls, and approval records of the three sub-tasks through the identifier of the superior task, and uses the chain of responsibility containing the hash value of the previous record to form a unified audit chain across agent tasks. Through the method provided in this embodiment, the system achieves granular governance following the principle of least privilege in complex collaborative tasks. Each agent can only access the minimum data and tools necessary to complete its own sub-task; any unauthorized attempts are blocked and recorded in real time, and the output complete chain of responsibility provides technical assurance for the traceability of multi-agent collaboration.

[0122] In this embodiment, the system first generates a main task permission data package, and then generates data extraction sub-task permission packages, analysis sub-task permission packages, and report writing sub-task permission packages through the permission derivation module. Each sub-task permission package records an independent Permission ID and the same Parent Permission ID to form a permission derivation tree; wherein, no sub-task permission exceeds the authorization scope of the main task permission data package.

[0123] When the data extraction agent transmits sales data to the analysis agent, the cross-agent data verification module verifies the permissions of both parties and performs field filtering and de-identification on the raw sales data, retaining only the fields required for analysis, such as region, product category, sales amount, period, and channel. Subsequently, a data exchange authorization token is generated, binding the two agents, the data range, and the validity period. This data exchange authorization token becomes invalid immediately after the data transmission is complete.

[0124] When the analysis agent transmits analysis results to the report writing agent, the system re-executes cross-agent data verification and only transmits the aggregated conclusions and statistical summaries, without transmitting the original customer or transaction records. Each data exchange authorization token, context version, tool execution evidence, and subtask permission package are all associated with the unified chain of responsibility through the main task identifier and Parent Permission ID.

[0125] Please refer to Figure 6 The present invention also provides an electronic device 210, including a memory 211, a processor 212, and a computer program stored in the memory 211 and executable on the processor 212. When the processor 212 executes the computer program, it implements the various steps of the intelligent agent dynamic permission control method described above.

[0126] The beneficial effects of the terminal of the present invention are the same as those of the method described above, and will not be repeated here.

[0127] In summary, this invention achieves dynamic least privilege control over the AI ​​Agent's task execution process through task parsing, risk assessment, and a task-based permission packet generation mechanism. Specifically, this invention calculates a task risk score based on the task objective, required data types, required tools, and the AI ​​Agent's role data. Based on this score, it generates a task-based permission data package containing a list of allowed tools, a list of prohibited tools, the responsible party, the execution mode, and audit strategies. This ensures that the AI ​​Agent can only obtain limited permissions commensurate with the task risk in different tasks. Simultaneously, by verifying permissions before each external tool call by the AI ​​Agent and dynamically adjusting permission packets or triggering manual approval based on the task risk score, this invention effectively solves technical problems such as unauthorized operations, data leaks, and erroneous executions that may arise from the AI ​​Agent's autonomous decision-making, chained tool calls, and model illusions. Furthermore, by generating a responsibility chain record containing task risk scores, permission packets, tool call records, and anomaly handling results, this invention establishes an auditable and traceable task execution integrity verification mechanism. This significantly improves the security, controllability, and compliance of AI Agent governance in an enterprise environment without affecting the normal task execution efficiency of the AI ​​Agent.

[0128] Furthermore, this invention interconnects the main task permission data package, permission derivation relationship tree, data exchange authorization token, context version, and tool execution evidence, enabling the system to control how permissions are derived to subtasks, how data flows between agents, and how permissions dynamically change with risk status during continuous tool calls. This forms an execution-period governance mechanism covering task creation, subtask assignment, agent collaboration, tool calls, risk updates, permission revocation, and audit tracking.

[0129] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for dynamic permission control of intelligent agents, characterized in that, The method includes: Receive task requests; Parse the task request to obtain the task objective, required data type, and required tools; Calculate the task risk score based on the task objective, the required data types, the required tools, and the role data of the intelligent agent. Based on the task risk score and the role data, task-type permission data is matched to generate a task-type permission data package; The functions of the agent are restricted according to the task-based permission data packet.

2. The method according to claim 1, characterized in that, Based on the task objective, the required data types, the required tools, and the role data of the intelligent agent, calculate the task risk score, including: Obtain multiple risk factors corresponding to the task objective, the required data types, the required tools, and the role data of the intelligent agent; Assign weights to each of the aforementioned risk factors; Obtain the risk value of each of the aforementioned risk factors; The risk values ​​of each risk factor are weighted and summed based on their respective weights to obtain the task risk score.

3. The method according to claim 1, characterized in that, The step of generating a task-based permission data package based on the task risk score and the role data includes: Based on the role data of the intelligent agent and the task risk score, determine the list of allowed tools, the list of prohibited tools, the responsible party, the execution mode, and the audit strategy; A task-based permission data package is generated based on the permitted tool list, the prohibited tool list, the responsible party, the execution mode, and the audit strategy.

4. The method according to claim 1, characterized in that, The step of matching task-type permission data with task risk score and role data to generate task-type permission data package includes: Determine whether the task risk score corresponding to the task-type permission data packet is higher than a preset first threshold; If so, the execution mode of the rule that restricts the agent to only generate preset suggested content and prohibits the agent from performing external write or send operations is matched to generate a task-type permission data packet.

5. The method according to claim 4, characterized in that, Also includes: Determine whether the task risk score is higher than a second threshold, wherein the second threshold is greater than the first threshold; If the value exceeds the second threshold, the task request will be sent to the agent's approval terminal. Based on the task risk score and the role data, task-type permission data is matched to generate a task-type permission data package, including: In response to receiving the approval instruction returned by the approval terminal, the execution mode of the rule that allows the agent to perform external write or send operations is matched to generate a task-type permission data packet.

6. The method according to claim 2, characterized in that, The restriction of the agent's functionality based on the task-type permission data packet includes: Before each time the agent invokes an external preset tool, the agent's tool invocation request is obtained; Check whether the tool identification code in the tool call request is included in the allowed tool list or prohibited tool list in the task-type permission data packet; If the tool identifier is included in the list of prohibited tools, then the tool call is blocked; If the tool identification code is included in the list of allowed tools, the data access range in the tool call request conforms to the data range of the task-type permission data packet, the action type in the tool call request conforms to the action range in the task-type permission data packet, and the call time in the tool call request is within the validity period in the task-type permission data packet, then the tool call is allowed.

7. The method according to claim 1, characterized in that, Also includes: The task request is broken down into multiple sub-task requests; For each of the subtask requests, a corresponding subtask permission data packet is generated; The functions of the corresponding intelligent agents are restricted according to the permission data packets of each subtask.

8. The method according to claim 1, characterized in that, Also includes: Determine whether the task request has been completed, whether the validity period of the task-type permission data packet corresponding to the task request has exceeded the preset period, or whether the intelligent agent has exhibited abnormal behavior. If the task is completed, the validity period exceeds the preset period, or the agent exhibits abnormal behavior, the task-type permission data packet corresponding to the task request will become invalid.

9. The method according to claim 1, characterized in that, Also includes: According to the task request, during the execution of a single task request, when it is detected that the agent's behavior does not conform to the task-type permission data packet corresponding to the task request or the task risk score changes, the task-type permission data packet of the agent is dynamically adjusted to restrict the function of the agent.

10. An electronic device, characterized in that, The system includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor, when executing the computer program, implements the intelligent agent dynamic permission control method as described in any one of claims 1 to 9.

Images