A multi-agent system-oriented task-level dynamic least-privilege execution method

Abstract

This invention discloses a task-level dynamic least privilege execution method for multi-agent systems. It performs semantic parsing on natural language tasks issued by the master agent, generating a structured semantic intent tree, and then obtains an initial minimum privilege set through permission mapping and pruning. Through a four-stage refinement derivation involving dependency closure computation, resource scope reduction, time window constraint binding, and conditional permission binding, and combined with conflict detection, it outputs the final privilege set. A dynamic permission token uniquely bound to the task is generated, completing full lifecycle management. An independent permission sandbox is allocated to the executing agent, and a permission isolation arbitrator coordinates concurrent access from multiple agents. Permission access behavior is monitored in real time, triggering tiered circuit breaking and degradation. Based on permission usage feedback, adaptive optimization derivation is performed, forming a security closed loop and a self-evolution mechanism. This invention refines the permission granularity from static coarse-grained configuration at the agent level to dynamic least privilege at the task level, significantly improving the operational security of multi-agent systems.

Description

Technical Field

[0001] This invention relates to the field of multi-agent system security technology, and in particular to a task-level dynamic least privilege execution method for multi-agent systems. Background Technology

[0002] In multi-agent systems, the master agent (Orchestrator) decomposes complex tasks and delegates them to multiple executing agents for concurrent execution. Each executing agent needs to access system resources such as the file system, database, external APIs, and code execution environment during execution. However, existing systems generally lack task-level permission control mechanisms; permission granularity remains at the agent-level static pre-configuration, unable to be dynamically declared and constrained according to task semantics. This leads to multi-agent systems being in a state of over-authorization for extended periods, resulting in the continuous accumulation of security risks. Existing technologies suffer from the following three problems: (i) Lack of task-level permission granularity: Existing permission control is agent-level rather than task-level. Existing multi-agent frameworks (such as AutoGen, LangChain Agents, CrewAI, etc.) typically employ a static, coarse-grained permission pre-configuration strategy when delegating tasks to the executing agent: a fixed set of permissions is pre-set for the executing agent (such as file read / write permissions, access to all tools, etc.), which remains unchanged throughout the agent's lifecycle and is completely decoupled from the semantics of the specific task being executed. This approach results in the executing agent obtaining permissions far exceeding the minimum permissions required to complete a specific task. For example, a task that only needs to read a certain type of configuration file in a specific directory grants the executing agent full file system read / write permissions; a task that only needs to query a table in a database grants the executing agent permissions for all tables. The root cause is that the permission granularity of the existing system remains at the agent level and cannot be refined to the task level: the same execution agent uses the same set of permission configurations when undertaking different tasks, and it is impossible to deduce and declare the minimum permission set required for each specific task, so that the system is in an over-privileged state for a long time, creating serious security risks.

[0003] (ii) The task semantics are disconnected from the permission boundaries, and scheduling instructions do not carry permission constraint information. In the existing multi-agent scheduling framework, the scheduling instructions issued by the master agent to the executing agent only contain task descriptions and execution parameters, without any permission constraint information. The semantic content of the task (operation type, target resource, time constraints, condition constraints, etc.) is completely disconnected from the definition of permission boundaries: the scheduling chain is only responsible for transmitting what to do, not what permissions to use to do it. This disconnect means that after receiving a task, the executing agent cannot automatically deduce the minimum permission boundary from the task semantics and can only rely on the pre-configured static permission set to execute all tasks. At the same time, when a task is subcontracted layer by layer in a multi-level scheduling chain, since the scheduling instructions do not carry permission constraints, the permission range of the lower-level agent is determined by the static configuration of the system rather than the requirements of the upper-level task. This results in the permission not being able to converge to the minimum necessary range with each level of the scheduling chain. The disconnect between task semantics and permission boundaries further amplifies the security risks in multi-level scheduling scenarios.

[0004] (iii) Multi-level scheduling chain permissions cannot converge, and permissions spread rather than tighten as the scheduling chain progresses; In the multi-level scheduling chain scenario, the existing system's permission management has a systemic permission diffusion problem: Since the permissions of each level of Agent are determined by the system-level static configuration rather than by the upper-level task requirements, the permission set cannot converge to the minimum necessary range as the scheduling chain progresses. Specifically, this manifests in three ways: First, horizontal propagation of permissions: multiple concurrent agents at the same level share resources such as file systems and databases. Due to the lack of task-based permission isolation, excessive permissions of one agent can infect the execution environment of other agents through shared resources, leading to frequent cross-agent resource pollution. Second, vertical accumulation of permissions: in a multi-level delegation chain, lower-level agents should theoretically only require a subset of the permissions of higher-level agents. However, due to the lack of a task-level permission constraint transmission mechanism, the permissions of each level of agent are actually configured independently without mutual constraints, and the overall scope of permissions exposed by the system expands with the increase in the number of scheduling chain layers. Third, lack of real-time circuit breaking for abnormal permission behavior: when an agent at a certain level exceeds its permission limits due to a warning of injection attack or execution anomaly, the existing system lacks a task-level real-time monitoring mechanism and can only conduct post-event log review, which cannot stop the damage in time, resulting in a very large window for the spread of security incidents. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the present invention aims to provide a task-level dynamic least privilege execution method for multi-agent systems.

[0006] To achieve the objectives of this invention, the technical solution adopted is as follows: A task-level dynamic least privilege execution method for multi-agent systems includes the following steps: 1) Semantically parse the natural language task description issued by the main intelligent agent, extract the task operation type, target resource range, time constraints and condition constraints, generate a structured semantic intent tree, and obtain the task-level initial minimum permission set through permission mapping and minimum permission pruning. 2) Perform a four-stage refinement derivation on the initial minimum permission set, sequentially completing dependency closure calculation, resource scope reduction, time window constraint binding and conditional permission binding, and completing mutual exclusion permission, permission out-of-bounds and privilege escalation detection through the conflict detection layer, and output the final task-level minimum permission set; 3) Generate a dynamic permission token uniquely bound to the task based on the final minimum permission set, and complete token issuance, sandbox injection, real-time verification during execution, and full lifecycle revocation management; 4) Assign an independent permission sandbox to each executing agent, and coordinate concurrent resource access by multiple agents through a permission isolation arbitrator to achieve task-level permission isolation and cross-agent resource pollution protection; 5) Monitor access behavior in real time, trigger tiered circuit breakers and downgrades for out-of-bounds access, abnormal frequency, privilege escalation, and token tampering, and adaptively optimize permission inference rules based on permission usage feedback to form a security closed loop and self-evolution mechanism.

[0007] Further, in step 1), semantic parsing uses a large language model to perform intent extraction, and the dimensional information in the recognition task is assembled into a semantic intent tree; permission mapping is driven by a policy rule engine, supporting both precise matching and semantic reasoning modes.

[0008] Further, in step 2), dependency closure computation is used to analyze logical dependencies between permissions, including transitive dependencies and eliminating invalid indirect permissions; resource scope reduction refines broad permissions into the smallest granular permissions of specific file paths, database tables, and API endpoints; time window constraints bind permission to TTL validity periods, and one-time tasks are marked with a single-use flag; conditional permission binding encapsulates conditional operations into conditional permissions that are validated at runtime.

[0009] Further, in step 2), the conflict detection layer performs three types of security checks: mutual exclusion permission check, permission over-boundary check, and privilege escalation check. If any check fails, authorization is denied and an alarm is triggered.

[0010] Further, in step 3), the dynamic permission token includes AgentID, a precise list of permissions, resource scope constraints, TTL, a conditional permission mapping table, a maximum number of uses, and a digital signature; the token is injected into the sandbox in encrypted form, and the executing agent cannot directly read or write it, but can only use it through the permission verifier.

[0011] Further, in step 3), the token lifecycle includes: issuance, secure distribution and injection, execution-time interception and verification, task completion / timeout / abnormal circuit breaker / main agent cancellation triggering revocation, after which it immediately becomes invalid and terminates all access sessions, and the entire lifecycle is recorded in an immutable audit log.

[0012] Furthermore, in step 4), the independent permission sandboxes achieve file, network, and inter-process communication isolation through namespaces. Each sandbox only holds the corresponding task token, and the tokens are not visible between sandboxes. The permission isolation arbitrator coordinates concurrent access according to the policies of read-only conflict-free concurrent access, read-write / write-write serialization, and out-of-bounds direct rejection.

[0013] Further, in step 5), the real-time access control monitor consumes audit logs to detect four types of anomalies: out-of-bounds access, request frequency exceeding limits, privilege escalation attempts, and token signature failure; the tiered circuit breaker degradation is divided into four levels: automatic narrowing for minor out-of-bounds access, degradation to read-only for write anomalies, suspension of alerts for privilege escalation, and forced termination for token forgery.

[0014] Furthermore, in step 5), the feedback learning engine compares the requested permissions with the actual permissions used after the task is completed, calculates the permission accuracy score, adaptively narrows the range of redundant permissions, expands the range of insufficient permissions, updates the allow / deny list, and continuously optimizes the accuracy of least permission derivation.

[0015] The beneficial effects of this invention are that, compared with existing technologies, it refines the granularity of permission control from agent-level coarse-grained static configuration to task-level dynamic minimum permissions, achieving a true principle of least privilege. The task semantic parsing and automatic minimum permission set inference framework, along with the four-stage refined derivation engine, jointly realize fully automatic inference from natural language task descriptions to precise task-level minimum permission sets, enabling permission declarations to be strictly bound to specific task semantics for the first time. Compared with static coarse-grained permission pre-configuration schemes, the system significantly reduces the permission redundancy rate (number of redundant permissions / total number of authorized permissions), significantly shrinks the overall attack surface of multi-agent systems, and greatly improves security.

[0016] This invention achieves a qualitative breakthrough in the permission isolation capability for concurrent multi-agent execution. An independent token sandbox and permission isolation arbitrator mechanism ensure complete isolation of permissions for each executing agent, effectively eliminating the risk of cross-agent resource pollution. Race conditions during concurrent write operations are coordinated in an orderly manner through the arbitrator, guaranteeing data consistency. Even if an executing agent is maliciously controlled by a prompt injection attack, the attacker's ability to laterally penetrate the system using that agent's permissions is completely blocked, significantly enhancing the overall security and reliability of multi-agent collaboration scenarios.

[0017] This invention's real-time circuit breaker mechanism for abnormal access permissions reduces security event response time from post-event discovery to the second level. The real-time access control monitor and tiered circuit breaker degradation mechanism reduce the system's detection and response latency for security events such as out-of-bounds access, abnormal frequency, and privilege escalation attempts to the second level (significantly improving response time compared to traditional post-event log review). The tiered degradation strategy ensures system security while maximizing the preservation of task execution value (minor anomalies are downgraded rather than directly terminated), effectively balancing security and availability.

[0018] This invention's dynamic token lifecycle management implements precise spatiotemporal constraints on permissions. Mechanisms such as TTL time-limit binding, single-use constraints, and conditional permission binding ensure that permissions exist only when needed and are effective only within the required scope, completely eliminating the risk of permanent permission leakage. The token's integrity protection based on HMAC-SHA256 digital signatures prevents token forgery and tampering attacks. End-to-end audit logs support precise tracing of any permission access event, meeting enterprise-level compliance audit requirements.

[0019] This invention's permission policy feedback adaptive learning mechanism drives the continuous evolution of system security. Based on the permission accuracy scoring and rule parameter adaptive adjustment mechanism derived from execution history, the accuracy of system permission derivation continuously improves with the accumulation of task execution data. As the number of tasks running in the system increases, the permission redundancy rate continuously decreases compared to the initial state, while the proportion of task failures due to insufficient permissions remains at an extremely low level, achieving a continuously optimized optimal balance between minimum permissions and task success rate. With the large-scale deployment of multi-agent systems in enterprise production environments, the dynamic permission constraint system provided by this invention will become a key infrastructure for ensuring the safe and reliable operation of AI agent systems. Attached Figure Description

[0020] Figure 1 This is a flowchart of the task-level dynamic least privilege execution method for multi-agent systems described in this invention. Detailed Implementation

[0021] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of this application.

[0022] like Figure 1 As shown, the task-level dynamic least privilege execution method for multi-agent systems according to the present invention includes the following steps: (a) Task semantic parsing and automatic inference of the least privilege set; By performing deep semantic parsing on the task descriptions issued by the main agent, the minimum set of permissions required to complete the task is automatically inferred at the task granularity, achieving precise alignment between task-level permission declarations and task semantics. This framework consists of three layers: Task Semantic Parser: Receives the natural language task description from the main agent, calls the Large Language Model (LLM) to perform Intent Extraction, identifies the operation type (read / write / execute / call / delete, etc.), target resource scope (specific file path / database table / API endpoint / toolset), time constraints (single operation / time-limited operation / continuous task), conditional constraints (operations executed only when a certain condition is met), and other dimensional information contained in the task, and assembles it into a structured semantic intent tree (IntentTree) to fully express the operational semantic structure of the task.

[0023] The Permission Intent Mapper layer maps each leaf node operation in the semantic intent tree to a corresponding system permission candidate, forming a permission candidate set. The mapping rules are driven by a configurable Policy Rule Engine, supporting both exact matching (direct mapping from operation type to permission type) and semantic reasoning (permission semantic inference using LLM for complex operation intents). Subsequently, a minimum permission pruning step removes redundant items and permissions beyond the task scope from the permission candidate set, forming the initial minimum permission set (Initial MinPermSet).

[0024] The perception execution scheduling layer receives two key inputs from the upstream permission intent mapping layer: first, an initial minimum permission set output after least permission pruning, which clarifies the types of perception adapters and resource access scope allowed for the current task; second, execution instructions from the heartbeat scheduling engine (including scheduling parameters such as task ID, scheduling priority, and concurrency constraints), which trigger perception execution actions on demand based on the semantic intent tree generated by the semantic parsing layer. Based on these inputs, the perception execution scheduling layer verifies whether the calling permissions of each perception adapter are within the initial minimum permission set to prevent unauthorized calls during the perception phase, and drives each adapter to execute perception tasks according to the scheduling strategy (serial / parallel / batch).

[0025] The perception execution scheduling layer structures and packages the collected execution results from each adapter (including metadata such as the actual list of accessed resources, execution status, and execution time) and outputs two types of data to the downstream four-stage least privilege set refinement inference engine: First, the actual perception result data, which serves as the input for the dependency closure calculation and resource scope reduction stages; second, the perception execution context, which includes information such as the actual resource paths touched in this perception, the number of calls, and the execution duration. This information is used by the refinement inference engine to narrow broad permissions to the smallest granularity of resources actually accessed during the resource scope reduction stage, and to dynamically calibrate the permission TTL based on the actual execution duration during the time window constraint stage. Through the structured context passed by this layer, the refinement inference engine can complete more accurate least privilege refinement with the support of real perception behavior data, rather than relying solely on static semantic inference.

[0026] The main agent issues a task description, invokes LLM for semantic parsing to generate a structured semantic intent tree, maps permission candidate sets (the mapping rules are driven by a configurable policy rule engine), and outputs a task-level initial minimum permission set (Initial MinPermSet) after least permission pruning. This achieves automated inference from natural language tasks to precise task-level minimum permission sets, eliminating the need for manual pre-configuration of permission templates for each task type. Permission granularity is reduced from the Agent level to the task level, lowering the operational costs of permission management.

[0027] (ii) Refined derivation of the four-stage least privilege set; The design employs a four-stage minimum permission set refinement process. Based on the initial task-level minimum permission set, multi-dimensional constraints are applied for refinement. A conflict detection layer ensures the safety and consistency of the task-level permission set, ultimately outputting a minimum permission set strictly aligned with the task's semantics. The four-stage refinement process is as follows: Dependency Closure Computation: Analyzes the logical dependencies between various permission items, incorporates necessary transitive dependencies of permissions into the permission set (such as "write file" depending on "parent directory creation permission"), and removes indirect permissions that are introduced only because of transitive relationships but are not actually needed, ensuring that the completeness and minimality of the permission set are satisfied at the same time.

[0028] Scope Narrowing: Based on the target resource scope description obtained from semantic parsing, broad target resource scope permissions are refined into the finest-grained specific path / table name / endpoint permissions. For example, "file system read permission" is refined to "only allow read permission to / data / config / *.yaml", and "database access permission" is refined to "only allow SELECT permission to query the status field of the orders table".

[0029] Temporal Constraint: Binds a time-to-live (TTL) constraint to each permission item in the permission set. Sets the validity period of the permission based on the estimated execution time of the task, and the permission expires automatically after the timeout. For one-time operation tasks, an additional "single use" constraint is bound, and the permission token is automatically revoked after one use.

[0030] Conditional Binding: For conditional constraint operations identified in the semantic intent tree (such as "write only if the file exists" or "call the API only if the status is pending"), the corresponding permissions are encapsulated as conditional permissions. During execution, the permission validator evaluates whether the condition is met in real time before releasing the permission. If the condition is not met, the permission is automatically unavailable.

[0031] The conflict detection layer performs three types of security checks on the refined permission set: mutual exclusion permission detection (checking whether there are logically contradictory permission combinations), permission out-of-bounds detection (checking whether it exceeds the highest authorized range of the current system), and privilege escalation detection (checking whether there is a path to achieve privilege escalation through permission combinations). If any check fails, the permission request is rejected and an alarm is triggered.

[0032] (iii) Lifecycle management of dynamic permission tokens bound to tasks; The design incorporates a dynamic permission token (DynPermToken) lifecycle management mechanism bound to tasks. This mechanism uses a cryptographically secure token as the sole credential for the executing agent (Sub-Agent) to access resources during the execution of a specific task. Each token is uniquely associated with a task and automatically expires upon task termination, covering the entire token lifecycle from generation to revocation. The token lifecycle consists of four phases: Token Issuance: A structured, dynamic permission token is generated based on the refined minimum permission set. The token contains the following fields: AgentID (unique sub-agent identifier), PermissionSet (precise permission list), ScopeConstraints (resource scope constraints), TTL (timestamp of validity period), ConditionMap (conditional permission mapping table), UsageLimit (maximum number of uses, -1 indicates unlimited uses), and Signature (HMAC-SHA256-based digital signature, tamper-proof). The token is injected in encrypted form into the security context of the execution agent's sandbox. The execution agent cannot directly read or modify the token content; it can only use it indirectly through the permission verifier.

[0033] Token distribution and Sandbox Injection: After the token is generated, it is securely delivered by the token distributor to the execution sandbox (isolated runtime environment) of the corresponding execution agent. The token is then stored in the sandbox by means of environment variable injection or security key management service (such as HashiCorp Vault) for the permission verifier to read. The external environment cannot access the token content.

[0034] Runtime Validation: Before each resource access request is initiated by the agent, the sandbox permission gate intercepts the request and verifies: ① Whether the requested resource is within the token's ScopeConstraints range; ② Whether the token's TTL is valid; ③ Whether the usage count has not exceeded the UsageLimit; ④ Whether the runtime conditions of the conditional permission are met. If all pass, access is allowed; if any fail, access is denied and recorded in the audit log.

[0035] Token Revocation: Revocation is triggered by the following conditions: task completion (automatic revocation), token TTL expiration (automatic revocation), detection of abnormal behavior triggering a circuit breaker (forced revocation), or the main agent issuing a cancellation command (forced revocation). After revocation, the token immediately becomes invalid, the executing agent's access permissions to all resources are synchronously cleared, and any remaining connection sessions are forcibly terminated. All operations throughout the token's lifecycle are written to an immutable audit log, supporting post-event traceability.

[0036] (iv) Permission isolation sandbox for concurrent execution by multiple agents; The design employs a multi-agent concurrent permission isolation sandbox mechanism based on task-level tokens. Each task corresponds to an independent permission sandbox, ensuring complete isolation of task-level permissions between executing agents and fundamentally eliminating the risks of cross-agent resource pollution and lateral permission leakage. This mechanism comprises three key components: Per-Agent Token Sandbox: Each executing agent has its own independent running sandbox, and each sandbox holds one and only its own corresponding dynamic permission token (DynPermToken). The sandbox implements resource access isolation at the operating system level: file system access is restricted through read-only / limited path mounting; network access is restricted to the API endpoints declared in the token through sandbox-level firewall rules (iptables / nftables namespaces); inter-process communication is isolated through namespace isolation (Linux Namespace: PID / IPC / NET) to prevent cross-sandbox access. No token information is shared between sandboxes; Token-A is invisible to sandbox B, completely preventing lateral token leakage.

[0037] Permission Isolation Arbiter: When multiple sub-agents have concurrent access requests to the same resource, the arbiter coordinates based on the permission type and resource scope in each agent's token. For read-only-read concurrency (no conflict), it grants access directly. For read-write or write-write concurrency (with conflict risk), it processes requests serially according to token priority queues and returns a waiting status to the lower-priority agent. For out-of-bounds access requests (requests for resources exceeding the token range), the arbiter directly rejects the request and reports a security event, without initiating the coordination process. Arbitration decisions are recorded in the audit log throughout the entire process.

[0038] Unified Audit Log: Every resource access request (whether granted or denied) by all executing agents is written to a structured audit log, including: Agent identifier, access timestamp, requested resource path, operation type, token verification result, and final grant / deny decision. The audit log supports real-time streaming (for consumption by permission anomaly detectors) and persistent storage (for post-event security audit queries), forming a fully traceable permission access record.

[0039] (v) Real-time circuit breaking and adaptive policy optimization for abnormal permissions; The design incorporates a real-time circuit breaker response mechanism for task-level permission exceptions and a permission policy feedback learning and optimization mechanism based on task execution history. Together, these two mechanisms constitute a security closed loop and self-evolution capability for a task-level dynamic least privilege system.

[0040] The Permission Access Monitor continuously consumes real-time event streams from audit logs and runs four types of anomaly detection rules: ① Out-of-bounds access detection: requests for resources exceeding the token's ScopeConstraints; ② Frequency anomaly detection: request frequency exceeding a set threshold of N times / second within a unit of time (configurable); ③ Privilege escalation attempt detection: requests for resources with a privilege level higher than the current token's authorized level; ④ Token integrity detection: token signature verification fails (possibly due to tampering). The circuit breaker process is immediately initiated if any anomaly is triggered.

[0041] Tiered Circuit Breaker + Degradation: Four levels of degradation strategies are implemented based on the type and severity of the anomaly: For minor out-of-bounds access, the permission scope is automatically narrowed (limiting the request to the largest common subset allowed by the token, ensuring partial task execution continues); for write operation anomalies, automatic degradation to read-only mode (rejecting write operations, allowing read operations to continue, preserving task execution value as much as possible); for privilege escalation attempts, the task is immediately suspended and an alert is sent to the main Agent / administrator, awaiting manual review and decision; for token forgery / tampering, the executing agent is forcibly terminated, the token is immediately revoked, all access sessions are cleared, and an advanced security alert is triggered.

[0042] The Policy Learning Engine collects and analyzes the actual permission usage data of the agent after each task execution cycle: the difference (Δ) between the requested permission set and the actually used permission set, redundant permissions (requested but never used permissions), and denied operations (attempts to perform operations outside the requested permission set). Based on historical difference analysis, the system quantitatively calculates the Permission Accuracy Score and adaptively adjusts the permission inference rule parameters for similar tasks: automatically narrowing the output range of corresponding rules for permissions that consistently exhibit redundancy; appropriately expanding the output range of corresponding rules for permissions that consistently show "insufficient request range"; and updating the Allow / Deny Lists as the priority coverage configuration for the rule engine. As task execution data accumulates, the system's permission inference accuracy improves, the proportion of redundant permissions continuously decreases, and it gradually approaches the ideal state of minimum permissions.

[0043] The applicant of this invention has provided a detailed description of the embodiments of the invention in conjunction with the accompanying drawings. However, those skilled in the art should understand that the above embodiments are merely preferred embodiments of the invention. The detailed description is only intended to help readers better understand the spirit of the invention and is not intended to limit the scope of protection of the invention. On the contrary, any improvements or modifications made based on the inventive spirit of the invention should fall within the scope of protection of the invention.

Claims

1. A task-level dynamic least privilege execution method for multi-agent systems, characterized in that, Includes the following steps: 1) Semantically parse the natural language task description issued by the main intelligent agent, extract the task operation type, target resource range, time constraints and condition constraints, generate a structured semantic intent tree, and obtain the task-level initial minimum permission set through permission mapping and minimum permission pruning. 2) Perform a four-stage refinement derivation on the initial minimum permission set, sequentially completing dependency closure calculation, resource scope reduction, time window constraint binding and conditional permission binding, and completing mutual exclusion permission, permission out-of-bounds and privilege escalation detection through the conflict detection layer, and output the final task-level minimum permission set; 3) Generate a dynamic permission token uniquely bound to the task based on the final minimum permission set, and complete token issuance, sandbox injection, real-time verification during execution, and full lifecycle revocation management; 4) Assign an independent permission sandbox to each executing agent, and coordinate concurrent resource access by multiple agents through a permission isolation arbitrator to achieve task-level permission isolation and cross-agent resource pollution protection; 5) Monitor access behavior in real time, trigger tiered circuit breakers and downgrades for out-of-bounds access, abnormal frequency, privilege escalation, and token tampering, and adaptively optimize permission inference rules based on permission usage feedback to form a security closed loop and self-evolution mechanism.

2. The task-level dynamic least privilege execution method for multi-agent systems according to claim 1, characterized in that, Step 1) Semantic parsing uses a large language model to extract intent, assembling the dimensional information in the recognition task into a semantic intent tree; The permission mapping is driven by a policy rule engine and supports both exact matching and semantic reasoning modes.

3. The task-level dynamic least privilege execution method for multi-agent systems according to claim 1, characterized in that, Step 2) Dependency closure computation is used to analyze logical dependencies between permissions, including transitive dependencies and eliminating invalid indirect permissions; resource scope reduction refines broad permissions into the smallest granular permissions of specific file paths, database tables, and API endpoints; time window constraints bind permission to TTL validity, and one-time tasks are marked with a single-use flag; conditional permission binding encapsulates conditional operations into conditional permissions that are validated at runtime.

4. The task-level dynamic least privilege execution method for multi-agent systems according to claim 1, characterized in that, Step 2) The conflict detection layer performs three types of security checks: mutual exclusion permission check, permission over-boundary check, and privilege escalation check. If any check fails, authorization is denied and an alarm is triggered.

5. The task-level dynamic least privilege execution method for multi-agent systems according to claim 1, characterized in that, Step 3) The dynamic permission token contains AgentID, a precise list of permissions, resource scope constraints, TTL, a conditional permission mapping table, a maximum number of uses, and a digital signature; the token is injected into the sandbox in encrypted form and cannot be directly read or written by the executing agent, but can only be used through the permission verifier.

6. The task-level dynamic least privilege execution method for multi-agent systems according to claim 1, characterized in that, Step 3) The token lifecycle includes: issuance, secure distribution and injection, execution-time interception and verification, task completion / timeout / abnormal circuit breaker / main agent cancellation triggering revocation. After revocation, the token becomes invalid immediately and terminates all access sessions. The entire lifecycle is recorded in the tamper-proof audit log.

7. The task-level dynamic least privilege execution method for multi-agent systems according to claim 1, characterized in that, Step 4) Independent permission sandboxes achieve file, network, and inter-process communication isolation through namespaces. Each sandbox only holds a corresponding task token, and tokens are not visible between sandboxes. The access control arbitrator coordinates concurrent access based on policies such as allowing read-only access without conflict, serializing read / write / write access, and directly rejecting access when it exceeds the limit.

8. The task-level dynamic least privilege execution method for multi-agent systems according to claim 1, characterized in that, Step 5) Consume audit logs in the real-time access control monitor to detect four types of anomalies: out-of-bounds access, request frequency exceeding limits, privilege escalation attempts, and token signature failure; the tiered circuit breaker degradation is divided into four levels: automatic narrowing for minor out-of-bounds access, degradation to read-only for write anomalies, suspension of alerts for privilege escalation, and forced termination for token forgery.

9. The task-level dynamic least privilege execution method for multi-agent systems according to claim 1, characterized in that, Step 5) After the task is completed, the feedback learning engine compares the requested permissions with the actual permissions used, calculates the permission accuracy score, adaptively narrows the range of redundant permissions, expands the range of insufficient permissions, updates the allow / deny list, and continuously optimizes the accuracy of least permission derivation.

Images