Agent permission control and secure execution method, device, equipment and medium

Abstract

The application relates to the technical field of access control and discloses an agent permission control and safe execution method and device, equipment and a medium, which comprises the following steps: receiving a task session request and analyzing the initial intention to obtain the initial intention, determining a minimum permission set through permission analysis of an agent and granting an execution agent; identifying a high-risk operation instruction and extracting an action intention in the execution process, completing a first security check based on semantic similarity, and completing a second security check in combination with a session history context when the first security check is passed; building an isolated execution sandbox and granting temporary high permissions after the security check is passed, destroying the isolated execution sandbox and recycling the temporary high permissions after the execution is completed, and enabling the execution agent to return to the minimum permission set to continue the task. The application can be applied to financial technology and other business scenarios, and through dynamic permission control, double-checking and an isolated execution mechanism in task execution, the application can reduce the risk of excessive authorization and improve the defense capability of abnormal instructions.

Description

Technical Field

[0001] This invention relates to the field of access control technology, and in particular to a method, apparatus, device, and medium for intelligent agent permission control and secure execution. Background Technology

[0002] In intelligent customer service, intelligent claims processing, intelligent underwriting, and intelligent operations scenarios within financial institutions, intelligent agents typically need to simultaneously access multiple core business systems, such as customer information systems, policy systems, claims systems, and payment systems, and invoke various business tools to complete cross-system operations. Existing technologies mostly employ a role-based static authorization approach, where the intelligent agent is granted full role permissions at the start of the session and retains these permissions throughout the entire session. Regardless of whether the current task involves only information retrieval or fund payment, permissions do not converge as the task changes, resulting in the intelligent agent possessing high-risk operational capabilities even when performing low-risk tasks. This makes it difficult to meet the security requirements of minimum permission control and refined authorization in financial scenarios.

[0003] With the widespread application of large language model-driven conversational agents in financial business processing, the behavior of these agents is highly dependent on their understanding of natural language instructions. Existing systems generally lack the ability to identify potentially malicious content in user input. Attackers can interfere with the agent's reasoning process by constructing special prompts, causing it to deviate from existing business rules and inducing it to perform sensitive operations that it shouldn't. This method of influencing agent behavior through conversational semantics introduces new security risks in financial scenarios, while existing access control mechanisms mainly remain at the interface access level, lacking effective defense against semantic-level attacks.

[0004] Furthermore, when an intelligent agent is about to perform high-risk operations such as database modifications, policy changes, or claims payments, existing technologies typically rely solely on preset rules or interface permissions for judgment, lacking a comprehensive analysis mechanism based on the current session context and the user's initial business intent. The system struggles to determine whether the current high-risk operation truly originates from the user's original needs or arises from semantic deviations or malicious guidance during multiple rounds of dialogue. This results in a lack of a security verification step based on intent and contextual rationality before executing high-risk actions, making it difficult to effectively ensure the security and compliance of financial business operations. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for intelligent agent permission control and secure execution, aiming to solve the technical problem that existing technologies cannot dynamically converge permissions based on the user's original intent and real-time semantic changes during intelligent agent sessions, and perform multi-level security verification of action intent in conjunction with the session context before executing high-risk operations.

[0006] To achieve the above objectives, the present invention provides a method for intelligent agent access control and secure execution, comprising: Receive a task session request initiated by the user, parse the task session request to determine the user's initial intent, use the permission analysis agent to determine the minimum set of permissions required to complete the task session request, and grant the minimum set of permissions to the execution agent. Control the execution agent to perform tasks under the set of least privileges; When it is detected that the executing agent generates a high-risk operation command, execution is paused to extract the action intent corresponding to the high-risk operation command; Determine the semantic similarity between the initial intent and the action intent, and execute the high-risk operation instruction based on the semantic similarity. Figure 1 The first layer of security verification for consistency; When the first security check passes, the session history context of the task session request is obtained, and a second security check based on logical rationality is performed on the high-risk operation instruction based on the session history context. When the second security check passes, an isolated execution sandbox containing the resources required to execute the high-risk operation instructions is constructed, and the execution agent is granted temporary high privileges. The execution agent is controlled to execute the high-risk operation instructions in the isolated execution sandbox. After execution, the isolated execution sandbox is destroyed and the temporary high privileges are revoked, so that the execution agent is restored to the state of the minimum privilege set to continue to execute the task.

[0007] Furthermore, to achieve the above objectives, the present invention provides an intelligent agent access control and secure execution device, comprising: The permission decision module is used to receive a task session request initiated by the user, parse the task session request to determine the user's initial intent, use the permission analysis agent to determine the minimum set of permissions required to complete the task session request, and grant the minimum set of permissions to the execution agent. The instruction scheduling module is used to control the execution agent to execute tasks under the minimum authority set; The risk monitoring module is used to pause execution when the executing agent generates a high-risk operation instruction in order to extract the action intent corresponding to the high-risk operation instruction; A semantic verification module is used to determine the semantic similarity between the initial intent and the action intent, and to execute the high-risk operation instruction based on the semantic similarity. Figure 1 The first layer of security verification for consistency; The logic review module is used to obtain the session history context of the task session request when the first security check passes, and to perform a second security check based on the logical rationality of the high-risk operation instruction based on the session history context. The sandbox construction module is used to construct an isolated execution sandbox containing the resources required to execute the high-risk operation instructions when the second security check passes, and to grant temporary high privileges to the execution agent. The environment recovery module is used to control the execution agent to execute the high-risk operation instructions in the isolated execution sandbox. After the execution is completed, the isolated execution sandbox is destroyed and the temporary high privileges are revoked, so that the execution agent is restored to the state of the minimum privilege set to continue to execute the task.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and an intelligent agent permission control and security execution program stored in the memory and executable on the processor, wherein when the intelligent agent permission control and security execution program is executed by the processor, it implements the steps of the intelligent agent permission control and security execution method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing an agent permission control and security execution program, wherein when the agent permission control and security execution program is executed by a processor, it implements the steps of the agent permission control and security execution method as described above.

[0010] Beneficial Effects: This invention relates to the field of access control technology and discloses a method, apparatus, device, and medium for intelligent agent permission control and secure execution. The method includes: receiving a task session request and parsing it to obtain the user's initial intent; determining the minimum set of permissions required to complete the task through a permission analysis intelligent agent and granting it to the executing intelligent agent; monitoring operation call instructions during execution, pausing execution and extracting the action intent when a high-risk operation instruction is identified; performing semantic similarity judgment between the initial intent and the action intent to complete the first layer of security verification; completing the second layer of security verification by combining the session history context when the verification passes; constructing an isolated execution sandbox and granting temporary high permissions when the second layer of security verification passes; destroying the isolated execution sandbox and revoking the temporary high permissions after execution, allowing the executing intelligent agent to return to the minimum set of permissions to continue the task. This invention can be applied to business scenarios such as fintech. By dynamically converging permissions during task execution and introducing dual verification of semantic consistency and logical rationality before high-risk operations, combined with an isolated execution environment and a temporary permission mechanism to complete high-risk operations, it reduces the risk of over-authorization and enhances the defense capability against abnormal instructions. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for the intelligent agent permission control and secure execution method in one embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the intelligent agent permission control and secure execution method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the intelligent agent permission control and secure execution device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The intelligent agent permission control and secure execution method provided in this embodiment of the invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can receive task session requests from the client and parse the user's initial intent. It then uses a permission analysis agent to determine the minimum set of permissions required to complete the task and grants it to the executing agent. During execution, it monitors operation call instructions; when a high-risk operation instruction is identified, execution is paused and the action intent is extracted. The initial intent and action intent are semantically similar to complete the first layer of security verification. If the verification passes, the session history context is used to complete the second layer of security verification. If the second layer of security verification passes, an isolated execution sandbox is built and temporary high permissions are granted. After execution, the isolated execution sandbox is destroyed and the temporary high permissions are revoked, allowing the executing agent to return to the minimum set of permissions to continue the task. This invention can be applied to business scenarios such as fintech. By dynamically converging permissions during task execution and introducing dual verification of semantic consistency and logical rationality before high-risk operations, combined with an isolated execution environment and a temporary permission mechanism, high-risk operations are completed, reducing the risk of over-authorization and enhancing the defense against abnormal instructions. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The present invention will now be described in detail through specific embodiments.

[0014] Please see Figure 2 , Figure 2This is a flowchart illustrating an embodiment of the intelligent agent permission control and secure execution method provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0015] like Figure 2 As shown, the intelligent agent permission control and secure execution method proposed in this invention includes the following steps: S10, receive a task session request initiated by the user, parse the task session request to determine the user's initial intent, use the permission analysis agent to determine the minimum set of permissions required to complete the task session request, and grant the minimum set of permissions to the execution agent. In this embodiment, the user terminal is the terminal entity that initiates the business interaction request. In a financial business environment, this manifests as a banking application running on a customer's mobile device, an online wealth management platform interface accessed through a web browser, an automated service call module integrated into an enterprise resource planning system, or professional workstation software used by financial institution counter staff. A task session request is a data unit actively submitted by the user terminal to the backend system to initiate an interaction process with a clear business objective. This data unit encapsulates the user's desired goal description information, and its form includes natural language text, structured messages conforming to specific business data standards, text sequences converted from voice commands by automatic speech recognition, or application programming interface call payloads containing a set of predefined parameters. Receiving this action occurs at the system's network boundary and is accomplished through pre-deployed and monitored network service interfaces. Such interfaces can be expressive state transition application programming interfaces based on Hypertext Transfer Protocol or its secure version, WebSocket long-connection channels supporting full-duplex communication, ISO 8583 message processing interfaces conforming to financial industry information exchange standards, or message queue middleware for high-throughput asynchronous processing. The receiving process specifically includes protocol parsing of incoming network data packets, verification of request header information to confirm the legitimacy of the source, extraction of core business data from the payload, and generation of a globally unique session identifier for this interaction and initialization of a temporary data storage context. This context is used to persist all states, operation records, and intermediate results related to this business objective in subsequent processing. For example, in a securities trading scenario, an investment manager enters an instruction to "buy 1,000 shares of Company A stock" through a professional trading terminal. The terminal program encapsulates this instruction along with account authentication information into a specific formatted trading instruction message and sends it to the trading execution system through a financial information exchange protocol. After receiving the message, the system verifies the message format and signature, extracts key fields such as security code, quantity, and price, and creates an independent session tracking record for this order.

[0016] Parsing refers to the computational process of deep analysis and semantic transformation of the raw data contained in the received task session request. Its core objective is to extract a high-level semantic representation from potentially ambiguous or unstructured input that accurately and unambiguously reflects the user's fundamental business purpose in the current session. This process relies on integrated natural language understanding and structured data processing capabilities. For natural language text requests, the system invokes a pre-trained language understanding model. Such models can be large-scale pre-trained models based on the Transformer architecture, such as dedicated versions that have undergone continuous pre-training and targeted fine-tuning on corpora of financial news, financial reports, research reports, and regulatory documents. The parsing operation first performs word segmentation, part-of-speech tagging, and named entity recognition on the input text to accurately locate key financial entity elements, such as bank account numbers, securities codes, counterparty names, currency amounts, interest rates, dates and times, and business operation verbs. Subsequently, through intent classification models or semantic role labeling techniques, the identified discrete entities are combined with the global context of the text to comprehensively infer and determine the user's initial intent. The initial intent is the final output of the parsing process. It is a structured semantic representation that can be directly processed and reasoned about by computer programs. It can typically be encoded as a JavaScript object representation containing fields such as intent category, operator, object, and key attribute constraints, or mapped as a dense feature vector in a high-dimensional semantic space. In a financial credit approval scenario, for a customer's request text submitted online, "Apply for a three-year mortgage loan of 2 million yuan," the parsing module might identify the entities "mortgage loan," "three years," and "2 million yuan," and determine the initial intent as "initiate a mortgage loan application," thereby generating a structured intent representation that explicitly includes key semantic elements such as the loan type being a mortgage loan, the term being three years, and the application amount being 2 million yuan.

[0017] A permission analysis agent is a computational entity or software module specifically designed to map business intentions to system operation permissions. This agent receives a structured initial intention generated by a parsing process as its core input. Internally, it encapsulates a knowledge system about the relationships between financial business operations, data resource classifications, system tool interfaces, and security permission tags. This knowledge can be represented as a carefully constructed permission knowledge graph, where nodes represent business concepts, data objects, or operation interfaces, and edges represent access or execution relationships and their corresponding permission tags. The workflow of the permission analysis agent involves deconstructing and analyzing the input initial intention, identifying all potential atomic-level system operations involved in realizing that intention. For example, an intention to "process cross-border remittances" might be deconstructed into a series of atomic operations such as "verifying the remitter's identity and limit," "checking real-time foreign exchange rates," "calculating and deducting handling fees," "generating cross-border payment instructions," and "registering transaction records." By querying the internal knowledge system, one or more corresponding system permission items are found for each identified atomic operation. These permission items precisely define the minimum security permissions required to access specific database tables or fields, call a microservice application programming interface, execute a batch job, or use a computing resource. The principle of least privilege is applied to optimize and simplify this set of permission items, eliminating any redundant items, those that can be indirectly implemented through existing permissions, or those irrelevant to the current specific business context, thus generating a final minimum permission set. The implementation of the permission analysis agent can be based on a static authorization rule policy library jointly defined and maintained by business and security experts, using a rule engine for logical reasoning; or it can adopt a data-driven approach, using historical business work orders, system operation logs, and corresponding authorization decision records as training data to build a machine learning model. This model learns the mapping relationship from the feature representation of the initial intent to the recommended permission set and can adapt to dynamic changes in business rules through an online learning mechanism.

[0018] Granting permissions refers to the system formally and dynamically assigning the minimum set of permissions determined by the permission analysis agent to the execution agent, enabling it to legally exercise these permissions during subsequent task execution. The execution agent is an automated program or artificial intelligence model instance that undertakes actual business logic calculations, external tool calls, and data processing tasks. The granting operation is not a one-time static configuration but a dynamic process tightly bound to the session lifecycle. A typical implementation involves generating and issuing an encrypted, time-limited security token, such as a JSON Web Token. The token's payload encodes details of the granted permission set, the corresponding session identifier, and explicit effective and expiration timestamps. The execution agent must present this token when subsequently attempting to access any protected system resources, where it is verified and authenticated by the policy enforcement point deployed on the resource access path. Another implementation involves dynamically creating a temporary, logically isolated permission context environment for the currently active session in the system background, loading the minimum set of permissions into this context in the form of policy rules, and associating the execution agent's runtime instance with and restricting its operation to this context. In the core architecture of a financial system, this is similar to temporarily creating a database user role with only the permission to read specific fields of the relevant transaction log for a specific anti-money laundering transaction screening task. The granting process ensures a technical closed loop from permission requirement analysis to the actual implementation of permissions. After the executing agent is authorized, all its operations are strictly limited to the boundaries defined by the minimum set of permissions. Any operation command that attempts to call or access unauthorized resources will be identified by the system as an abnormal permission and trigger the corresponding security control process when initiated.

[0019] The internal structure of the permission analysis agent revolves around the mapping and reasoning function from business intent to permission sets. Its core includes an intent parsing and decomposition module, which receives structured initial intents and decomposes complex business intents into a series of atomic-level system operation sequences using rule-based or semantic analysis methods. A permission knowledge graph storage and query module forms the agent's knowledge foundation. This graph is organized in a graph structure, with nodes representing business operations, data resource entities (such as database tables and application programming interfaces), and permission tags. Edges represent access, invocation, or ownership relationships between nodes and their corresponding permission requirements. A permission reasoning and optimization module works in conjunction with the knowledge graph query module. It receives atomic operation sequences, binds all potential permission items to each operation by traversing the knowledge graph, and then applies a least-permission principle algorithm (such as a pruning algorithm based on access path analysis or permission dependency relationships) to simplify the permission set, eliminating redundant items and generating the final least-permission set. In addition, the agent typically includes a policy management and adaptation interface to receive externally updated authorization policy rules or model parameters, ensuring that its reasoning logic can adapt to changes in business rules. These modules are connected in a pipelined or service-oriented manner. The output of the intent parsing module serves as the input to the query module, and the results of the query module are fed into the inference optimization module for processing.

[0020] The internal structure of the execution agent focuses on securely executing business logic within a restricted permission context. Its core includes a permission context awareness and token management module, which receives and maintains permission carriers (such as security tokens or context references) granted by the system and verifies whether the current operation is within the permission boundaries declared by the carrier before initiating any operation. A task planning and instruction generation module dynamically generates specific operation call instruction sequences based on the user's initial intent and the current session state. A controlled resource access proxy module serves as the unified exit point for all external calls. It intercepts the original call requests issued by the instruction generation module, uses the authentication results provided by the permission context awareness module to modify (e.g., attach tokens, filter parameters) or block the requests, and then calls the target tool or data interface through a secure channel (e.g., through a service mesh sidecar proxy). An execution status monitoring and feedback module records the lifecycle of instruction execution, captures output results and exceptions, and feeds back key information to the session history context. These modules are typically integrated as runtime dependencies or internal service calls. The permission context awareness module provides real-time authentication support for the resource access proxy module, and the instruction sequences generated by the task planning module are executed by the resource access proxy module.

[0021] The permission analysis agent and the execution agent do not communicate directly, but are indirectly coupled through a central coordination mechanism of the system (such as a session manager or authorization service). The output of the permission analysis agent (the minimum set of permissions) is passed to the system's authorization component, which generates a permission token or configures a permission context based on it. This token or context is then injected into or associated with the permission context-aware module of the execution agent. When the task planning module of the execution agent generates an operation instruction, the resource access agent module determines whether to allow the instruction and how to forward it based on the permission information held by its permission context-aware module.

[0022] This embodiment determines the user's initial intent by receiving and parsing task session requests, providing standardized and unambiguous input for permission analysis. Based on this intent, the permission analysis agent dynamically determines the minimum set of permissions, realizing the transformation of permission allocation from static role binding to dynamic task association, strictly adhering to the principle of least privilege. The permission set is dynamically granted to the execution agent, establishing a temporary and clearly defined operation permission context, forcibly constraining all its operations, and effectively mitigating the risks brought about by static permissions and over-authorization.

[0023] S20, control the execution agent to execute tasks under the minimum authority set; In this embodiment, control is a proactive and continuous monitoring and constraint process aimed at ensuring that all actions of the executing agent are strictly confined within the security boundaries defined by the granted minimum set of permissions. This process is not a simple on / off switch, but rather constructs a dynamic monitoring and execution environment that spans the entire task execution lifecycle. The executing agent is the entity that carries specific business logic processing capabilities and enters a working state after receiving the granted minimum set of permissions. The minimum set of permissions defines the range of data resources that the executing agent can access in this task, the list of tools or application programming interfaces that can be invoked, and the set of allowed operation types, constituting an insurmountable policy boundary.

[0024] The implementation of control relies on a linkage mechanism between permission enforcement points and policy decision points established at the system architecture level. One basic implementation is through a resource access proxy or gateway. All access requests to external resources (such as databases, microservices, and file systems) initiated by the executing agent must pass through this proxy. Before forwarding the request, the proxy performs real-time authentication based on the permission credentials associated with the current session (such as the minimum permission set encoded in the token). For example, if the executing agent attempts to call the "query transaction history" interface, the proxy will verify whether the interface is in the list of tools allowed by the permission set and further verify whether the account range in the request parameters exceeds the permissions. Another more cohesive implementation is through security sandboxes or container technology, running the executing agent instance in an isolated environment with pre-configured access control rules (corresponding to the minimum permission set). All its access to the network, file system, and processes is subject to system-level enforcement constraints from the underlying isolation mechanism.

[0025] Task execution refers to a series of operations performed by an intelligent agent, after passing the verification by the control mechanism, to actually drive the business logic forward. This includes transforming the parsed initial user intent into a specific, sequential, or parallel execution plan, and calling the corresponding tools or processing modules one by one to complete each step in the plan. In the financial field, this might manifest as a claims processing agent, granted only the permissions to "read policy information" and "call the loss assessment model," sequentially performing operations such as data querying, model calculation, and generating a preliminary report. The entire execution process is transparently monitored by the control mechanism. The intelligent agent itself may not even be aware of the existence of permission checks; it only needs to focus on the correct implementation of the business logic. Any operation attempting to exceed the permission boundaries will be silently blocked by the control mechanism or transformed into a permission exception event upon invocation, thereby ensuring that the business flow only proceeds within the secure and permitted track.

[0026] For example, in a financial credit approval scenario, the minimum set of permissions granted to the executing agent might only include "reading applicant's basic information," "querying credit report interface (limited to 1 time)," and "writing preliminary approval conclusion." Once the control mechanism takes effect, the executing agent begins performing the approval task. It successfully calls the "read applicant's basic information" interface. When it attempts to call the "query credit report interface," the control mechanism (such as an API gateway) verifies that this is the first call within the session and allows it. If the internal logic of the agent attempts to call the same credit report interface a second time, or attempts to call an unauthorized "retrieve bank statements" interface, the control mechanism immediately blocks the request and returns a permission error. Ultimately, the agent can only write the approval conclusion to the designated database and cannot perform any unauthorized data access or operations.

[0027] This embodiment establishes a control mechanism throughout the task execution process, transforming the static minimum permission set granted to the executing agent into dynamic behavioral constraints, ensuring that every specific operation is performed within the permission boundaries. This effectively prevents the executing agent from exceeding permission limits due to programming errors, logical defects, or malicious input during complex business logic processing, controlling security risks at every resource access call point, and providing real-time, operational-level protection for the secure operation of core business logic.

[0028] S30, when it is detected that the executing agent generates a high-risk operation instruction, execution is paused to extract the action intent corresponding to the high-risk operation instruction; In this embodiment, the monitoring objective is to capture in real-time operational instructions generated by the executing agent during operation that may exceed its current authorized scope or violate security policies. This function is typically implemented by a monitoring agent or interceptor independent of the main execution path. This agent is deployed at key nodes capable of intercepting all outbound operational instructions, such as the application programming interface call layer, the message queue publishing end, or function call hooks. The generation of high-risk operational instructions by the executing agent is an event that may originate from various situations. For example, the executing agent may attempt to call a system tool without granted permissions, and the generated instruction may be internally marked as high-risk due to permission verification failure; or the content characteristics of the instruction itself (such as attempting to access sensitive data patterns or performing specific high-risk operations) may trigger matching rules based on a pre-built risk feature library. The monitoring agent analyzes the flowing instruction stream in real-time, applying a rule engine or lightweight machine learning model for immediate judgment. Once an instruction that meets the high-risk conditions is identified, subsequent handling procedures are immediately triggered.

[0029] Suspending execution refers to an immediate and mandatory intervention measure taken by the system upon confirming a high-risk operation instruction. Its core objective is to prevent the instruction from being further processed or actually acting on the target system, thereby buying time for in-depth analysis and preventing potential damage. This is not a simple log recording or asynchronous alarm, but a synchronous interruption of the execution flow. Implementing a suspension typically involves sending a high-priority control signal to the runtime environment (such as a process, thread, container, or virtual machine) hosting the execution agent, requiring it to immediately stop the current execution sequence. Simultaneously, the system needs to accurately save the execution context at the moment of interruption, including the program counter, register states, memory stack snapshots, and all unfinished intermediate computation results, and serialize these states and store them in a dedicated suspension context storage area. This series of operations ensures that the business execution state can be completely frozen and seamlessly integrated at any future recovery point without data loss or state inconsistency.

[0030] Extracting the corresponding action intent is a deep semantic analysis and purpose reconstruction process performed on the high-risk operation instruction itself after its execution has been frozen by security. High-risk operation instructions typically contain specific opcodes and parameters, such as a structured application programming interface (API) call request, which includes a method name, target resource identifier, and input parameters. The extraction process first parses the instruction, decomposing it into operation identifiers (e.g., "transferFunds"), operation objects (e.g., target account number), and operation parameters (e.g., transfer amount). Then, semantic parsing techniques are used to combine these discrete elements and transform them into a structured semantic representation that characterizes the purpose and logic behind the operation—the action intent. This process may utilize a pre-trained semantic model to map the operation identifier and parameters to a shared semantic vector space, or fill in the parameters according to a predefined business logic template to generate a standardized intent description object. For example, for the high-risk instruction "call payment interface, account B, amount 1,000,000," the extracted action intent might be represented as "execute a large transfer operation to account B." This structured action intent serves as the basis for subsequent... Figure 1 Consistency checks provide a well-defined and computable object of analysis.

[0031] Monitoring functionality can be implemented using a service mesh model based on sidecar proxies. Monitoring logic is embedded in the accompanying sidecar that executes the agent service instance. The sidecar transparently intercepts all outbound calls and matches them according to dynamically issued risk characteristic policies. Alternatively, techniques based on function hooks or aspect-oriented programming can be used to implant detection points in the critical code paths of the executing agent. When a specific type of instruction is generated, a callback function is triggered to perform a risk assessment. Risk identification strategies can be static rule bases, such as lists of sensitive keywords, high-risk application programming interfaces (APIs), or abnormal parameter patterns; or they can be dynamic models, such as using anomaly detection algorithms to analyze the deviation of instruction sequences in real time.

[0032] The technical means of pausing execution depend on the runtime isolation level. At the operating system process level, a specific process can be suspended by sending a SIGSTOP signal, or thread execution can be paused using debugger interfaces. At the container or virtual machine level, the entire instance can be paused through container runtime interfaces or virtual machine manager commands. In higher-level business process engines, logical pauses can be achieved by interrupting the current workflow node and persisting the process state to a database. The key is that the pause operation must be atomic and complete quickly to prevent instructions from being partially executed during the pause process.

[0033] The implementation of action intent extraction can be adjusted based on the standardization of the instruction. For fully structured instructions, intent objects can be directly generated by mapping from their fields. For instructions containing natural language parameters or those that are themselves natural language commands, a natural language understanding module needs to be integrated. This module can be a lightweight intent classification model, specifically trained for known high-risk operation types within the system, to achieve fast classification and feature extraction. The extracted intent representation needs to maintain the same semantic representation format as the "initial intent" defined in the system to ensure the effectiveness of subsequent comparisons; for example, both can be encoded as vectors in the same vector space or JSON objects with the same structural pattern.

[0034] This embodiment monitors and identifies high-risk operation commands generated by the executing agent in real time. It can instantly capture and warn of malicious or abnormal operation attempts before they actually cause harm, extending the security defense to the moment the command is generated. By immediately suspending the execution process, it effectively blocks the transmission and execution of high-risk commands to subsequent processing stages or external systems, controlling potential security threats in an isolated state before they spread, preventing direct data corruption, financial losses, or system state contamination that could result from command execution. Through deep semantic analysis of the frozen high-risk commands to extract their intent, the original, potentially disguised, command content is transformed into a clear and analyzable security policy assessment object, providing a basis for subsequent semantic-based intent analysis. Figure 1 Consistency checks and logical rationality analysis provide crucial standardized inputs, thus forming a key link from risk detection to in-depth analysis.

[0035] S40, determine the semantic similarity between the initial intent and the action intent, and execute the high-risk operation instruction based on the semantic similarity. Figure 1 The first layer of security verification for consistency; In this embodiment, determining semantic similarity is a quantitative calculation and comparison process. Its goal is to measure the degree of consistency or deviation between the user's initial intent and the action intent extracted from the high-risk operation command in terms of deep semantics. The initial intent is parsed and determined at the beginning of the session, representing the user's original, overall business goal in this interaction, such as "querying this year's portfolio return report." The action intent, on the other hand, characterizes the purpose behind the specific high-risk operation that the executing agent attempts to perform, such as "exporting a complete database containing all sensitive customer information." Although the two may exist at different levels of abstraction (overall goal vs. specific action), they are projected into the same computable high-dimensional semantic vector space through semantic encoding, allowing their "distance" or "angle" to be measured by mathematical tools.

[0036] The core of semantic similarity determination lies in converting the semantic representations of two intentions into a comparable form and applying a similarity algorithm. A common approach is intention vectorization. Both the initial intention and the action intention can be encoded as dense semantic vectors of fixed dimensions during generation. This can be achieved through pre-trained language models, such as Sentence-BERT or embedding models specifically tuned for fine-tuning instruction pairs in the financial domain, which map structured intention description text (e.g., "Intention: Transfer, Target Account: X, Amount: Y") into a vector. Another approach is semantic association computation based on knowledge graphs, indirectly reflecting semantic relevance by calculating the path distance between the entities and relationships involved in the two intentions within the business knowledge graph. After obtaining the two vectors, semantic similarity is typically calculated using a cosine similarity algorithm, calculating the cosine of the angle between the two vectors in space. The result is a scalar value between -1 and 1; the closer the value is to 1, the more consistent the semantic directions, while a value closer to 0 or negative indicates semantic irrelevance or opposites. Alternatively, Euclidean distance, Manhattan distance, or similarity scoring functions based on more complex neural network models can also be used.

[0037] Execution of high-risk operation commands based on semantic similarity. Figure 1 The first layer of security verification for consistency is a rule-based application process that transforms quantitative indicators into binary security decisions. Figure 1 Semantic consistency is the core security principle followed in this round of verification. It requires that the purpose behind a high-risk operation must maintain a reasonable semantic connection with the user's initial intent, thus serving as the first line of defense against intent tampering attacks (such as prompt injection). The verification process relies on a preset, configurable similarity threshold. This threshold defines the minimum acceptable standard for semantic consistency, and its setting may be based on historical data analysis of business risk levels, operation types, or security policy requirements. For example, for fund transfer operations, the threshold may be set to 0.8 (high consistency requirement); for information query operations, the threshold may be set to 0.6.

[0038] The verification process includes: comparing the calculated semantic similarity score with the threshold value in real time. If the semantic similarity score is greater than or equal to the threshold, it is determined to be semantically similar. Figure 1 If the first layer of security verification passes, the high-risk operation instruction is eligible to proceed to the next stage (such as a second logical verification). If the semantic similarity is less than a threshold, it is determined to be inconsistent or significantly deviating from the intended purpose, and the first layer of security verification fails. This "failure" is a clear security event that will directly trigger predefined interruption or handling procedures, such as immediately terminating subsequent processing of the instruction, recording a security audit log, and possibly returning an error message to the user or administrator. This verification mechanism achieves automated, real-time, and objective preliminary filtering of operational intentions.

[0039] This embodiment maps the user's initial intent to the action intent of high-risk operations into the same semantic space and calculates their similarity, thus abstracting the concept of "intent". Figure 1 The "sense of consistency" security requirement is transformed into specific, quantifiable numerical indicators, providing an objective and repeatable mathematical basis for security decisions. By comparing the calculated semantic similarity with a preset threshold in real time and making a clear "pass" or "fail" decision accordingly, an automated, semantically understanding-based security filter is constructed. This filter can effectively identify and block high-risk operations that are semantically significantly deviated from or irrelevant to the user's original objective. Thus, at the first layer of defense, it accurately resists advanced attacks that induce agents to perform unauthorized operations through prompt injection, semantic deception, and other means, making up for the shortcomings of traditional keyword-based or simple rule-based matching in dealing with such complex threats.

[0040] S50, when the first security check passes, obtain the session history context of the task session request, and perform a second security check based on logical rationality on the high-risk operation instruction based on the session history context; In this embodiment, obtaining the session history context of the task session request is a data retrieval and aggregation operation triggered after the first layer of security verification passes. The session history context is not a pre-stored static data block, but a dynamically constructed set of structured records uniquely bound to the currently ongoing task session. It is a complete record of all relevant interaction events and internal system state changes since the task session request was initiated. Its content typically includes the original dialogue message sequence between the user and the agent, intermediate conclusions or thought chain logs generated during the agent's internal reasoning process, successfully executed low-risk operation instructions and their results, and any temporary variables or environmental state snapshots generated by the system during the session. The action of obtaining this context is performed by a session management service in the system. This service queries and aggregates the above information in real time from multiple potentially dispersed data sources based on the unique identifier of the current session. These data sources can be session tables in relational databases, key-value stores for storing temporary interaction records, or time-series databases recording operation logs. The purpose of obtaining this context is to provide a decision-making background rich in temporal information and causal relationships for the next stage of in-depth analysis.

[0041] The second layer of security verification based on logical rationality for high-risk operation instructions, performed using the acquired session history context, is a high-level security analysis process that goes beyond simple semantic consistency, encompassing a richer information dimension. Logical rationality here refers to the high-risk operation instructions to be verified; they must not only align with the user's objective in abstract intent, but their specific execution actions must also conform to the evolutionary logic of the current business dialogue, comply with business rule constraints, and possess the necessity and appropriateness for execution within the current session state. This round of verification is completed by a separate analysis module, which receives two core inputs: the high-risk operation instruction to be verified and the newly acquired complete session history context.

[0042] The core of the verification process is logical reasoning and compliance assessment. The analysis module encapsulates domain knowledge, which may manifest as a configurable library of business rules and compliance strategies. This library defines the legal preconditions, parameter constraints, execution order requirements, and mutual exclusion or dependency relationships with historical operations for operation instructions in different business scenarios. The analysis module examines the specific details of high-risk operation instructions (such as operation type, target object, and parameters) within the complete narrative constructed from the session history context. It performs a series of reasoning judgments, such as determining whether the operation is a crucial step indispensable to fulfilling the user's initial intent, checking whether the timing of the operation's execution aligns with the expected order of the business process, verifying whether the resources or preconditions required for the operation have been met in previous session steps, and confirming whether the operation logically contradicts an operation already executed in the session history. For example, in a financial transaction involving multiple confirmation steps, the analysis module verifies whether records of "user identity secondary verification passed" and "transaction details confirmed" already exist in the session history before the "final payment" instruction. The output of the verification is a clear compliance conclusion, such as "execution allowed," "parameter modification recommended," or "execution rejected." The system determines the final result of the second security check based on this conclusion, and the check is considered to have passed only when the conclusion is explicitly allowed.

[0043] This implementation, after the first layer of verification passes, systematically acquires and integrates the full historical interactions and state records of the task session. This constructs a three-dimensional analytical background for security decisions, encompassing temporal, causal, and state dimensions, expanding the evaluation criteria from semantic comparison of single instruction pairs to the complete business process narrative. Based on this rich session history context, the implementation verifies the rationality of execution logic, introducing in-depth analysis of multiple dimensions such as business rule compliance, operational timing correctness, and execution necessity. This identifies high-risk operations that, while semantically seemingly related, are inappropriate, lack prerequisites, violate procedures, or contain inherent contradictions within the specific business logic chain. This constructs a deeper security defense line based on business process understanding, effectively compensating for the potential shortcomings of the first layer of verification based solely on intent similarity. It can defend against more covert and complex logic-level attacks, such as step-by-step manipulation using business process vulnerabilities, thereby significantly improving the overall accuracy of the system's judgment of high-risk operations and the depth of security protection.

[0044] S60, when the second security check passes, construct an isolated execution sandbox containing the resources required to execute the high-risk operation instruction, and grant temporary high privileges to the execution agent; In this embodiment, constructing an isolated execution sandbox containing the resources required to execute high-risk operation instructions involves creating a temporary, logically isolated, and resource-constrained computing environment for the upcoming high-risk operation after the second layer of security verification has passed. Here, "containing" means that the set of resources provided to the sandbox is all the resources it can access; external or unspecified resources are neither visible nor reachable. "Required resources" specifically refers to the minimal dataset and tool interface necessary to complete the high-risk operation instruction. For example, a high-risk instruction to "execute a specific complex financial model calculation" might require only a specific data file containing input parameters and an execution engine interface dedicated to that model. The construction process begins with a clean, stateless, lightweight runtime environment base, such as a minimal container image or a blank virtual machine instance. The system analyzes the specific parameters of the high-risk operation command, accurately identifying the data objects it directly depends on (such as specific rows and columns of a database table) and the external service endpoints that must be invoked. Then, guided by the principle of least privilege, it mounts or injects only the identified subset of data (rather than the entire database) into the base in read-only or controlled-write mode. Clients or proxies pointing to specific tool interfaces are deployed or configured only within this environment, while strict network policies are applied, restricting communication only to the necessary service endpoints. The resulting isolated execution sandbox is a closed execution unit tailored for a single high-risk operation, with resource provision precisely meeting the requirements and strictly isolated from the main runtime environment and other sandboxes.

[0045] Granting temporary high privileges to an executing agent refers to the system dynamically granting the agent a set of additional operational permissions beyond its current minimum set of permissions, enabling the agent to execute a specific high-risk instruction within an isolated execution sandbox. The "temporary" attribute indicates that this permission has a clearly defined start and end time; its lifecycle is typically completely bound to the single execution cycle of the high-risk instruction, expiring immediately upon completion and unusable for other operations or carried over to subsequent tasks. "High privileges" are relative to the baseline minimum set of permissions granted to the executing agent in that session. It specifically refers to those privileges necessary for executing the high-risk instruction but not included in the baseline permissions. For example, while the baseline permissions only allow "reading transaction records," temporary high privileges might additionally include the power to "call the payment gateway interface." One way to implement this is by generating a time-limited security token that encodes the specific content and validity period of the temporary high privileges and securely passing it to the executing agent, which presents it when requesting resources within the sandbox. Another approach is to dynamically modify the permission context of the executing agent in the current session in the system background, temporarily overlaying a policy rule that is only valid for resources within the sandbox. Regardless of the method used, the granting process ensures that the elevation of permissions is precise, controlled, and transient. The executing agent only acquires the necessary privileges within this narrow context, and the privileges are revoked once it leaves this context or the task is completed.

[0046] The construction technology for isolated execution sandboxes can be chosen based on infrastructure and isolation strength requirements. In containerized environments, a minimal base image stripped of all unnecessary components can be used, employing dynamic configuration techniques to mount necessary configuration files, keys, or data volumes on demand during container startup. For scenarios requiring stronger isolation, microvirtual machine technology, with its optimized startup speed, can quickly provide a hardware-assisted isolated sandbox environment. Network isolation policies can be implemented through software-defined networking, configuring independent virtual networks and strict entry / exit rules for each sandbox instance, allowing access only to whitelisted target endpoints. Identification of required resources can be automated by analyzing instruction metadata, dependency graphs, or historical execution records to determine the minimum dataset and toolset.

[0047] The temporary high-privilege granting and management system needs to be integrated with a unified identity authentication and access management platform. A temporary, dynamic permission policy service can be developed. This service, responding to a successful sandbox construction signal, immediately generates a policy fragment for the current operation, containing precise permission declarations and a short validity period, and injects it into the access token of the executing agent, or issues it to the policy execution points of the sandbox and resource endpoints. To achieve immediate permission revocation, an event-based revocation mechanism can be designed. When a high-risk instruction is completed or a sandbox destruction event is triggered, the system automatically broadcasts a permission revocation instruction to all relevant components, immediately invalidating the temporary permissions. Alternatively, a very short-lived token can be used, with a validity period only slightly longer than the estimated operation execution time, relying on natural expiration for automatic revocation.

[0048] This implementation, after passing the second layer of verification, dynamically constructs a strictly resource-limited isolated execution sandbox, providing a secure and closed "laboratory" environment for high-risk operations. This ensures that even if malicious code exists within the operation or unpredictable side effects occur during execution, their impact is physically or logically confined within the sandbox, preventing them from affecting other system components or data, thus achieving physical isolation and controllability of risks. By precisely and briefly granting the executing agent the temporary high privileges necessary for executing the specific operation, on-demand and immediate privilege escalation is achieved. This satisfies the reasonable need for special privileges in high-risk operations while strictly limiting them to a single operation and the sandbox environment, eliminating the possibility of high privileges being retained, abused, or laterally transferred by the agent. The combination of these two aspects provides secure execution support for a very small number of necessary high-risk operations. While meeting business flexibility, it strictly adheres to and reinforces the principle of least privilege and the best practice of immediate privilege revokement, providing the ultimate secure containerization solution for the system to handle sensitive operations.

[0049] S70, control the execution agent to execute the high-risk operation instruction in the isolated execution sandbox, destroy the isolated execution sandbox after execution and reclaim the temporary high privileges, so that the execution agent is restored to the state of the minimum privilege set to continue to execute the task.

[0050] In this embodiment, controlling the execution agent to execute high-risk operation instructions within an isolated execution sandbox means redirecting the agent's computational focus and operational scope from the main task's runtime environment and strictly confining it within the boundaries of the constructed isolated execution sandbox. This involves switching the execution context. The system modifies the execution agent's runtime configuration or call path so that all subsequent system call requests, such as process creation, file reading / writing, and network connections, are redirected by the operating system or container runtime to the resources and services provided within the sandbox instance. The execution process is initiated within the sandbox. For example, the execution agent parses and runs the code logic corresponding to the high-risk instruction. This logic calls the mounted tool interfaces and accesses the injected data subset within the sandbox. The entire execution process is constrained within the sandbox's isolation boundaries. Systems outside the sandbox are unaware of the specific computations within it and can only receive its final output or status signals through predefined, controlled channels.

[0051] Destroying the isolated execution sandbox and revoking temporary high privileges after execution is a system cleanup and state rollback process that ensures temporary resources and privileges do not pose a residual risk. The destruction operation is triggered after a high-risk operation command is detected and the process within the sandbox terminates normally or times out. Destruction is not a simple logical deletion; it requires the complete release and erasure of all compute, storage, and network resources occupied by the sandbox instance. In container technology, this corresponds to immediately stopping the container process and deleting the container instance and its associated storage volume; in virtual machine technology, it corresponds to shutting down the virtual machine and deleting its virtual disk. The destruction process ensures that any temporary data, cache, or state generated during sandbox operation is not leaked to the external environment. The concurrent privilege revoke operation aims to revoke the temporary high privileges previously granted to the execution agent. This is typically achieved by immediately invalidating the security token carrying the temporary privileges, removing the corresponding policy rule from the execution agent's active permission context, or marking the privilege as revoked on a central policy server. The revoke mechanism must be immediate and enforceable, ensuring that the execution agent no longer holds any additional privileges beyond its original minimum set of privileges at the time of sandbox destruction.

[0052] Restoring the executing agent to a state with the minimum set of permissions to continue task execution involves resetting the agent's runtime environment and permission configuration to the basic security state prior to the high-risk operation, after cleanup. This includes two aspects: first, switching the agent's execution context from the destroyed sandbox back to the main task's runtime environment, enabling it to continue accessing resources authorized in the main environment; second, verifying and confirming that the agent's currently effective permission set is precisely equivalent to the minimum set of permissions granted at the start of the session, without containing any residual temporary high permissions. The system can verify this by querying the agent's current permission token or policy context. After state restoration, the system sends an explicit resumption signal to the agent, allowing it to resume subsequent routine tasks that do not require high permissions from the previously paused process breakpoint, thus maintaining the entire session at the baseline security level.

[0053] The technical implementation of controlling the execution of intelligent agents within a sandbox can be tailored to different architectures. In process isolation-based schemes, child processes of the intelligent agent can be launched in a pre-configured sandbox environment by setting namespaces, control groups, and file system mount points. In service mesh architectures, traffic from the intelligent agent service instance can be routed entirely through a sidecar proxy to a specially created, label-isolated backend service instance (i.e., the sandbox) for this high-risk operation. The key lies in the precise routing of execution traffic and the strict binding of the computing environment.

[0054] The destruction of the sandbox and the revocation of permissions require coordinated operation. A coordinator service can be designed to listen for completion events of high-risk commands within the sandbox. Upon receiving a completion event, the coordinator first invokes the container or virtual machine management application programming interface (API) to forcibly terminate and clean up the sandbox instance. Immediately afterwards, it invokes the identity and access management system's API to revoke the temporary permission token issued for that session, or updates the policy to remove the temporary rule. These two calls should be atomic as much as possible within a distributed transaction, or ensure eventual consistency through idempotent operations. To prevent delayed permission revoke, the lifecycle of the temporary permission token can be directly bound to the lifecycle of the sandbox instance, with the sandbox destruction signal automatically triggering token expiration.

[0055] Verification of state recovery can be achieved through a combination of proactive querying and reactive auditing. The proactive approach involves the coordinator service calling the permission query service before resumption to obtain the real-time list of valid permissions for the executing agent and comparing it with the archived minimum permission set. The reactive approach involves analyzing the executing agent's operation records through log auditing during subsequent execution to confirm that it has not used any permissions that have been declared revoked. The resumption signal can be transmitted via message queues, callback functions, or by setting shared state flags to wake up the previously suspended main task execution thread.

[0056] This implementation achieves ultimate spatial isolation of operational risks by strictly confining the computation of the executing agent within an isolated execution sandbox. This ensures that all potential impacts of high-risk operations (including data modification, system calls, and network communications) are physically or logically confined within a pre-defined closed boundary, preventing any uncontrollable side effects from contaminating or damaging the main business environment. By immediately and thoroughly destroying the sandbox instance and simultaneously reclaiming temporary high privileges after the operation is completed, immediate and irreversible removal of temporary dangerous resources and high-risk privileges is achieved. This eliminates security backdoors caused by resource residue or forgotten privileges, ensuring that the system's security state can be instantly rolled back to the clean baseline before the high-risk operation occurred. By precisely restoring the context and permission state of the executing agent to the original minimum permission set and enabling it to seamlessly continue executing subsequent tasks, after successfully handling specific high-risk requirements, the privilege level and risk exposure of the entire system are rapidly and stably reduced to a minimum. This maintains the minimum permission security baseline for the majority of the task session, achieving a balance between security and business continuity.

[0057] In one embodiment, step S10 includes: S101, Receive a task session request from the user terminal, and extract key information and perform semantic understanding on the task session request to determine the user's initial intent; S102, input the user's initial intent into the permission analysis agent, and control the permission analysis agent to perform function matching in a preset system tool library based on the user's initial intent, and identify a list of candidate tools required to respond to the initial intent; S103, control the permission analysis agent to perform risk dependency analysis on the candidate tool list based on the principle of least privilege, and filter out tools whose risk level meets the preset security threshold from the candidate tool list based on the risk dependency analysis results to obtain the least privilege set; S104, the minimum permission set is formatted as a system prompt word, and the system prompt word is injected into the context memory of the executing agent to grant the minimum permission set to the executing agent.

[0058] In this embodiment, receiving a task session request from a user terminal is a network access and data initialization process. The user terminal refers to the terminal initiating the operation, such as a customer's mobile banking application or a trader's professional workstation. The task session request is a formatted data packet encapsulating the business objective, which may be transmitted via HTTPS API or financial messaging protocols. The receiving service operates at the network edge, responsible for verifying the request's legitimacy, performing replay protection and rate limiting checks, generating a unique session identifier for each legitimate request, and initializing a dedicated data storage area for the session to associate with all subsequent interactions and states. Extracting key information and semantic understanding from the task session request to determine the user's initial intent is a structured parsing process. Key information extraction is applied to the request payload; for structured parameters, it can be directly mapped, while for natural language text, it activates a processing pipeline. This pipeline performs word segmentation, part-of-speech tagging, and named entity recognition. A specially trained financial domain model can identify entities such as account codes, amounts, and product types. The semantic understanding stage uses an intent classification model fine-tuned from a financial corpus. This model combines entities with context, mapping classifications to a standardized intent framework. The output is a structured object, such as JSON data containing operation type, target object, and constraints. This object represents the user's initial intent and forms the foundation for all subsequent security and execution decisions.

[0059] The user's initial intent is input into the permission analysis agent, which then performs function matching within a pre-defined system toolkit based on this intent. This process identifies a list of candidate tools needed to respond to the intent, representing a goal-driven resource discovery operation. The permission analysis agent is an independent security policy reasoning module. The pre-defined system toolkit is a cataloged metadata repository, where each record describes a system capability unit, including its function description, interface specifications, associated data resources, and inherent risk tags. Function matching is performed by converting the structured intent into a query vector and then conducting a semantic similarity search within the toolkit's vectorized index. This returns all capability units with a matching score exceeding a threshold, forming a candidate tool list. For example, for an intent to hedge exchange rate risk, multiple candidates such as forward contract pricing tools and foreign exchange option simulation interfaces might be matched.

[0060] The control and access control agent performs a risk dependency analysis on a list of candidate tools based on the principle of least privilege. Based on the analysis results, it selects tools whose risk levels meet preset security thresholds, resulting in a minimum privilege set, which is the core application of the security strategy. Risk dependency analysis assesses two levels: first, the inherent risk attributes of the tool itself, such as the data sensitivity and financial impact of the operation; second, the necessity of the tool in the current specific intent context, i.e., whether there are lower-risk alternatives, or whether its high-risk functions can be restricted. The access control agent accesses a risk knowledge graph to assist in reasoning, which defines the relationships between tools, data, and compliance clauses. The analysis process traverses the candidate list, calculates the comprehensive risk score of each tool in the current scenario, and enforces the principle of least privilege: attempting to replace high-risk tools with low-risk tools, or narrowing the tool's access permissions to the minimum subset of data and operations absolutely necessary to complete the current intent. The preset security threshold is a set of configurable policy rules, such as prohibiting access to un-anonymized customer biometric information. The final output is a fine-grained set of authorization policies with clear constraints, i.e., the minimum privilege set.

[0061] Formatting the minimum permission set into a system prompt and injecting it into the context memory of the executing agent to grant the agent the minimum permission set is a process of encapsulating and dynamically internalizing the permission policy. The formatting operation, based on a template, converts the structured authorization policy declaration into an instruction format that the executing agent can directly parse, such as a piece of natural language text or structured instructions that clearly describes the scope of operations and prohibitions. The executing agent's context memory is its storage area for maintaining session state and historical information. The injection action writes the formatted system prompt into a specific location in the context memory allocated to the session, usually as the highest-priority meta-instruction. This makes permission constraints the primary internal behavioral guidelines that the executing agent must refer to when generating any subsequent reasoning and actions in the current session, thus achieving real-time embedding and execution of permission boundaries in the agent's autonomous decision-making loop.

[0062] This embodiment provides unambiguous security decision-making basis for the entire process by accurately parsing task requests and determining structured initial intents, thus avoiding permission allocation deviations caused by ambiguous intent understanding from the source. Utilizing a permission analysis agent to perform functional matching from intent to tool ensures that the discovery of resources required to achieve business objectives is based on objective functional fit, establishing a comprehensive candidate foundation for subsequent refined authorization. Strict risk dependency analysis is performed on candidate tools, and the principle of least privilege is applied, generating an extremely convergent and scenario-adaptive set of least privileges. This maximizes the compression of data exposure and operational risks while meeting business needs. The set of least privileges is transformed into prompts understandable to the agent and injected into its runtime context, dynamically internalizing the static authorization strategy into an inherent constraint for the agent's decision-making. This ensures that the principle of least privilege is continuously and reliably adhered to during complex autonomous task execution.

[0063] In one embodiment, step S20 above includes: S201, control the execution agent to perform task planning based on the user's initial intention and generate a task execution plan; S202, control the execution agent to generate operation call instructions according to the task execution plan; S203, Perform permission verification on the operation call instruction to determine whether the operation call instruction belongs to the authorization scope of the minimum permission set; S204, if the operation invocation instruction falls within the authorization scope of the minimum permission set and the operation invocation instruction does not match the preset high-risk feature, then the operation invocation instruction is allowed and executed; S205, if the operation call instruction does not belong to the authorization scope of the minimum permission set, or if the operation call instruction matches a preset high-risk feature, then the operation call instruction is marked as a high-risk operation instruction.

[0064] In this embodiment, the control execution agent plans tasks based on the user's initial intent and generates a task execution plan. This is a reasoning process that decomposes high-level business objectives into ordered, executable steps. After receiving the constraints of the granted minimum authority set, the execution agent's planning module takes the structured initial intent as input. The planning process needs to consider the current session state, the accessible tool set, and the resource boundaries defined by the minimum authority set. For agents based on large language models, this might be achieved by designing specific system prompts to guide step-by-step reasoning and outputting a structured list of steps or a flowchart. For agents based on traditional rules, this might be achieved by querying predefined workflow templates. The generated task execution plan is a blueprint containing serialized or parallelized operation nodes and their logical dependencies. Each node corresponds to one or more specific system operations, and each operation must be within the tool list and data access scope allowed by the minimum authority set. For example, for the initial intent of "completing a cross-border trade finance application," the generated task execution plan might include steps such as "verifying trade documents," "calling the exchange rate risk calculation model," and "generating a financing proposal," and the tools called in each step have been authorized in the authority set beforehand.

[0065] The control execution agent generates operation invocation instructions based on the task execution plan, which is the process of instantiating abstract plan nodes into concrete system calls. Each plan node is translated into one or more invocation instructions with explicit parameters, pointing to a specific system tool or application programming interface. The generation of instructions must conform to the specification of the tool interface and be populated with specific parameter values ​​obtained from the session context or the results of previous steps. For example, the plan node "Invoke the exchange rate risk calculation model" is instantiated as a specific REST API call instruction, whose parameters include currency pairs, amounts, time ranges, etc. The logic module that generates the instructions ensures that the parameter format of the instructions strictly matches the input expected by the target tool.

[0066] Performing permission checks on operation invocation commands to determine whether they fall within the scope of the minimum permission set is a real-time, mandatory security policy enforcement point. The permission checker holds a detailed description of the minimum permission set corresponding to the current session. This check has two dimensions: first, verifying whether the tool or interface the command intends to invoke is explicitly allowed in the permission set; second, verifying whether the data resource object specified by the command's parameters is within the data access subset limited to that tool by the permission set. For example, the permission set might allow calling the "customer information query interface," but only for querying "account A of the customer associated with the current session." If the generated command queries "account B," the check will fail. This check is completed synchronously before the command is actually sent to the target system.

[0067] If an operation invocation command falls within the scope of the minimum authorization set and does not match the preset high-risk characteristics, then the operation invocation command is allowed and executed. This is a double-affirmation security condition. "Falling within the authorization set" means the basic permission check has passed. "Not matching the preset high-risk characteristics" is an additional, content-based security filter. The preset high-risk characteristics are a rule base or model independent of the permission set, used to identify potentially dangerous operation patterns. For example, the command may contain sensitive keywords such as "bypass approval," "super user," or "test environment database," or the parameter combination may trigger abnormal pattern detection (such as frequently calling the same interface within a short period). Only when the command passes both of these checkpoints will it be actually sent to the target tool for execution, and the execution result will be returned to the agent to advance the task plan.

[0068] If an operation call instruction does not fall within the scope of the minimum permission set, or if the operation call instruction matches a preset high-risk characteristic, then the operation call instruction is marked as a high-risk operation instruction. This is a risk assessment and classification action. Marking is triggered if either of the following two conditions is met: "Not within the authorized scope" represents a clear permission breach. "Matching high-risk characteristics" means that even if permission verification passes, its content pattern triggers a separate security alert. The marking operation sets a specific risk flag in the instruction metadata and places it in a queue or channel awaiting special processing. This marking is a crucial state transition; it transforms a normal operation call instruction into one that requires initiating an additional security verification process (e.g., [missing information]). Figure 1 A special object for consistency checks. Once marked, the default execution path of this instruction is interrupted.

[0069] This embodiment combines a static minimum permission set with dynamic risk rules to construct a dual execution-time protection system covering both permission compliance and operational content security by planning tasks based on initial intent and performing real-time dual verification of permissions and risk characteristics when generating specific instructions. Instructions that pass both checks are allowed to proceed normally, ensuring the efficiency of legitimate business processes; instructions that fail either check are immediately marked as high-risk, enabling precise capture and rapid isolation of permission overreach and abnormal operation patterns. This provides clear and timely input for subsequent in-depth security analysis, thereby embedding continuous and proactive security intervention capabilities into the autonomous operation of the intelligent agent.

[0070] In one embodiment, step S30 above includes: S301, when it is detected that the executing agent generates a high-risk operation instruction, the transmission path of the high-risk operation instruction is intercepted to suspend the execution of the high-risk operation instruction and the running state of the executing agent is frozen; S302, parse the high-risk operation command to obtain the operation identifier and operation parameters; S303, perform semantic parsing on the operation identifier and operation parameters to construct a structured semantic representation, and generate an action intent representing the core semantics of the high-risk operation instruction based on the structured semantic representation.

[0071] In this embodiment, when a high-risk operation instruction is detected to be generated by the executing agent, intercepting the transmission path of the instruction to suspend its execution is a synchronous, system-level control action. The transmission path is the software stack channel through which the operation call instruction travels from the generation point to the target execution endpoint (such as a tool service interface). Interception is achieved through hook programs deployed on critical network or inter-process communication nodes. In a microservice architecture, this is typically performed by a sidecar proxy of the service mesh. The proxy detects that the outbound request contains a specific high-risk flag or matches the interception rule, immediately suspends the encapsulation and sending of the network request, and returns a simulated "suspended" response to the caller. In a monolithic or thread-based architecture, a checkpoint can be inserted before the instruction is submitted to the scheduler or queue by modifying the function call chain. When the instruction is determined to be high-risk, the checkpoint throws a control exception, jumping the program execution flow to a dedicated processing routine. The simultaneous freezing of the executing agent's running state aims to preserve the complete computational context of the interruption point. This involves capturing the stack frame, register contents, references to all allocated memory objects, and handles to any pending I / O operations of the current thread or process. In containerized environments, all processes within a container can be suspended by sending a SIGSTOP signal to the container, and the process memory state can be serialized and stored using checkpointing techniques. In strongly isolated virtual machine-based environments, the pause functionality of the virtual machine manager can be utilized. The frozen state is persisted to a session-bound storage area, ensuring that execution can be reloaded and resumed from the precise breakpoint upon subsequent recovery without inconsistencies or data loss.

[0072] Parsing high-risk operation instructions to obtain the operation identifier and parameters is a process of structured deconstruction and information extraction. At this point, the high-risk operation instruction is an intercepted, static data object. Its format is usually structured, such as a JSON object conforming to a specific pattern, a Protobuf message, or a programming language object containing a dictionary of commands and parameters. The parsing process is performed by a dedicated instruction parser. This parser performs syntactic analysis on the instruction data body according to a predefined instruction pattern or interface contract. The operation identifier is the core symbol explicitly specified in the instruction, representing the action to be performed. It is usually a string or enumeration value, such as `transfer_funds` or `QUERY_SENSITIVE_LOG`. The operation parameters are a set of key-value pairs associated with this identifier, used to specify the operation, for example, `{"to_account":"ACC789","amount":10000}`. The parser needs to accurately separate the identifier field and parameter field from the instruction and perform normalization processing on the parameters, such as type conversion (converting the string "10000" to an integer) and encoding / decoding (such as Base64 decoding). This step transforms the original instruction packet used for transmission into a set of standardized data elements that can be processed by subsequent logic.

[0073] Semantic parsing of operation identifiers and parameters to construct a structured semantic representation and generate action intents that characterize the core semantics of high-risk operation instructions is a mapping and sublimation process from syntactic information to business semantics. The semantic parser receives a standardized set of operation identifiers and parameters. Internally, it integrates or accesses a domain knowledge base that defines the mapping relationship between operation identifiers and high-level business concepts, as well as the interpretation rules for parameters to business entities. The parsing process first maps operation identifiers to one or more business action types, such as mapping `transfer_funds` to fund transfers. Subsequently, it semantically annotates and associates parameters; for example, it identifies that the parameter `to_account` represents a bank account entity, and its value `ACC789` is the specific identifier of that entity; the parameter `amount` represents the transfer amount attribute. Based on these annotations, the semantic parser organizes information such as business action types, involved entities and their roles, and attribute constraints according to a predefined action intent structure template, constructing a structured semantic representation. This representation is a machine-readable and semantically rich model, such as a set of RDF triples, an instance in a business ontology, or a JSON-LD document in a specific format. This structured representation, or action intent, strips away the specific syntactic details of the instruction, abstracting the core business semantics of "who did what to whom, and under what conditions," thus laying the foundation for subsequent intent... Figure 1 Consistency checks provide objects that allow for direct logical and similarity calculations.

[0074] This embodiment achieves millisecond-level execution interruption and scenario preservation by instantly intercepting command transmissions and freezing the agent's state, before threats can have a real impact, creating a secure static analysis environment for in-depth analysis. By performing precise syntactic parsing on the intercepted commands, standardized operation identifiers and parameters are extracted, providing a clean and unambiguous data foundation for subsequent semantic understanding. Furthermore, semantic parsing maps and organizes syntactic elements into structured intent representations rich in business logic, transforming potentially dangerous operations into objects that can be directly reasoned and verified by the security policy engine. This completes the critical data transformation from anomaly detection to in-depth analysis, providing the necessary conditions for implementing precise semantic-based security adjudication.

[0075] In one embodiment, step S40 above includes: S401, determine the cosine similarity value between the initial intention and the action intention in the semantic vector space, and use the cosine similarity value as the semantic similarity; S402, compare the semantic similarity with a preset semantic similarity. Figure 1 Compare numerical values ​​using consistency thresholds; S403, if the semantic similarity is less than the semantic similarity... Figure 1 If the consistency threshold is reached, the first security check is deemed to have failed. S404, if the semantic similarity is greater than or equal to the semantic similarity... Figure 1 If the consistency threshold is reached, the first layer of security verification is considered to have passed.

[0076] In this embodiment, the cosine similarity value between the initial intent and the action intent in the semantic vector space is determined. Using this cosine similarity value as the semantic similarity is a computational process that quantifies abstract semantic relationships into concrete numerical values. The semantic vector space is a high-dimensional real-number vector space, where each dimension represents a potential semantic feature. The initial intent and action intent are encoded as two dense vectors in the same vector space during generation. This encoding process is typically performed by a pre-trained language model, such as a sentence encoder based on the Transformer architecture. This model has been fine-tuned on a large amount of financial business text to ensure accurate vectorization of business terms and intent expressions. Cosine similarity calculation is a mathematical method that measures the consistency of the directions of two vectors. Its numerical range is [-1, 1]. The closer the value is to 1, the more consistent the directions of the two vectors are, i.e., the more semantically similar they are. The calculation process is as follows: first, calculate the dot product of the two vectors; then, calculate their respective L2 norms (modulus lengths); finally, divide the dot product by the product of the two norms. Using the calculation results as semantic similarity provides an objective and repeatable metric to characterize the degree of semantic alignment between the user's initial expressed business objective and the purpose behind the high-risk operation instructions.

[0077] Semantic similarity with pre-defined meaning Figure 1 The consistency threshold is used for numerical comparison, serving as a policy-based decision trigger point. The preset intention... Figure 1 The consistency threshold is a configurable scalar value, typically between 0 and 1. Its specific value is determined by business security policies, the risk level of the operation, and historical data analysis. For example, the threshold might be set to 0.85 for fund transfer operations and 0.60 for information query operations. The comparison operation is performed synchronously within the calculation unit, directly comparing the calculated semantic similarity value with the threshold stored in the configuration center. This comparison is the sole basis for subsequent binary judgments, ensuring the automation and consistency of the decision-making process.

[0078] If the semantic similarity is less than the meaning Figure 1 If the consistency threshold is exceeded, the first layer of security verification fails. This determination means that the intention represented by the high-risk operation instruction deviates significantly from the business objective initially declared by the user in the current session, failing to meet the preset consistency security standard. The failure is a clear security event signal that triggers predefined risk handling procedures, such as immediately blocking further processing of the high-risk operation instruction, recording detailed security audit logs, and possibly sending an alert to the monitoring system. This determination result is one of the outputs of the first layer of security verification, marking the failure based on intent... Figure 1 The initial screening for concordance failed.

[0079] If the semantic similarity is greater than or equal to the semantic similarity Figure 1 If the consistency threshold is reached, the first layer of security verification is considered passed. This determination indicates that the intention of the high-risk operation command is semantically consistent with the user's initial intention, thus passing the initial rationality review. Passing this determination is a permission signal, allowing the high-risk operation command to proceed to the next stage of the security processing flow, such as a second layer of verification based on logical rationality. However, this does not mean that the command is finally approved for execution; it only provides access for subsequent, more in-depth verification.

[0080] This embodiment encodes the initial intent and action intent into the same vector space and calculates cosine similarity, transforming the abstract semantic consistency requirement into a precisely calculable numerical indicator, thus providing an objective quantitative basis for security decisions. By comparing the calculated semantic similarity with a configurable threshold in real time and making a binary decision of pass or fail, an automated, semantically understanding-based first-line filtering defense is constructed. This defense can effectively identify and block high-risk operations that deviate significantly from the user's original goal semantically, thereby accurately resisting intent tampering attacks induced by techniques such as prompt word injection at the first layer of defense.

[0081] In one embodiment, step S50 above includes: S501, in response to the judgment signal that the first security check has passed, aggregate the multi-turn dialogue records and thought chain reasoning logs generated by the executing agent in the process of responding to the task session request, and generate the session history context; S502, the session history context, the high-risk operation command and the preset business security constraint policy are concatenated into a logical verification prompt word; S503, input the logical verification prompt into the permission analysis agent, and control the permission analysis agent to analyze the logical rationality of the high-risk operation instruction in the context of the session history according to the business security constraint policy; S504, Receive the rationality analysis result output by the permission analysis agent; S505, if the rationality analysis result is a pass mark, then the second security check is determined to be passed; S506, if the rationality analysis result is a failure flag, then the second security check is determined to have failed.

[0082] In this embodiment, in response to the first security check passing the determination signal, the multi-turn dialogue records and thought chain inference logs generated by the executing agent during the response to the task session request are aggregated to generate a session history context. The determination signal is a system event that triggers the session management service to retrieve all interaction data associated with the current session identifier from distributed storage. The multi-turn dialogue records are the original text sequences of user input and agent responses arranged in chronological order and stored in a message queue or database log table. The thought chain inference log is a detailed record of intermediate steps, assumptions, data references, and decision bases generated by the executing agent during internal inference, typically stored in a dedicated log storage in a structured log format. The aggregation operation involves data extraction, timestamp alignment, redundancy removal, and integrating these heterogeneous data streams into a coherent, structured document or knowledge graph, i.e., the session history context. This context not only includes interaction content but also implicitly contains task progress status, solved sub-problems, temporary conclusions, and pending dependencies.

[0083] The conversation history context, high-risk operation instructions, and preset business security constraint policies are concatenated into a logical verification prompt. Both the conversation history context and high-risk operation instructions have been converted into standardized text or structured data blocks. The preset business security constraint policies are a set of rules encoded in natural language or machine-readable format, defining the preconditions, compliance requirements, and risk control red lines for business operations. The concatenation process follows a predefined template, using the context as background narrative, the high-risk operation instructions as the focus of evaluation, and the security constraint policies as evaluation criteria, combining them in a specific order to form a coherent prompt text. The prompt word design aims to guide the analysis model to comprehensively consider the continuity, compliance, and necessity of the historical interaction sequence and the current operation in terms of business logic. For example, the prompt word might be formatted as: "Based on the following conversation history: [historical context]. Evaluate operation: [high-risk instruction]. Business constraint to be met: [security policy]. Determine whether the operation is logically reasonable in the context." The logic verification prompt is input into the permission analysis agent, which then analyzes the logical rationality of high-risk operation instructions within the context of the session history, based on business security constraint policies. The permission analysis agent is a dedicated computational module for policy reasoning, potentially implemented using a large language model or rule engine. After the prompt is input, the agent is placed in an instruction compliance mode. Its internal processing flow includes: parsing the historical context in the prompt to reconstruct the task state; identifying the specific actions and parameters of the high-risk instruction; and invoking business security constraint policy knowledge stored in memory for logical deduction. Analyzing the logical rationality involves multi-dimensional judgments: whether the operation conforms to the normal evolution sequence of the business process; whether the operation is redundant or conflicts with actions already executed in the session history; whether the operation parameters are consistent with confirmed data in the history; and whether the operation meets all preconditions and risk mitigation requirements stipulated in the security policy. The agent generates a reasoned analysis conclusion through chained reasoning or rule matching.

[0084] The receiver receives the rationality analysis results from the permission analysis agent. The output is typically a structured response containing classification labels, confidence scores, and explanatory text. Pass and fail flags are predefined enumerated values, which may be encoded as booleans or specific strings. The receiving action is processed synchronously or asynchronously by the calling service, parsing the response body to extract the core decision fields and converting them into internal events.

[0085] If the rationality analysis result is marked as passed, the second layer of security verification is deemed successful. This determination is based on a clear and affirmative conclusion output by the agent, indicating that the high-risk operation instruction is assessed as logically reasonable, compliant, and necessary under the given session history and business constraints. Passing this determination allows the instruction to proceed to the subsequent execution preparation phase.

[0086] If the rationality analysis result is marked as failing, the second layer of security verification is deemed to have failed. This determination is based on the negative conclusion output by the agent, indicating that the operation has logical flaws, violates business rules, or contradicts historical context. A failure determination triggers security handling procedures, such as command blocking, alarm reporting, and session state rollback.

[0087] This embodiment generates rich context by aggregating complete session history, providing a decision-making background that includes temporal and causal relationships for in-depth analysis. Concatenating prompts integrates history, instructions, and policies into a single analytical input, ensuring the integrity of the evaluation framework. Driving the permission analysis agent to perform constraint-based logical reasoning enables automated in-depth review of the compliance, necessity, and consistency of operations within specific business processes. Based on the agent's output, it automatically determines whether the verification passes or fails, constructing a high-level security filtering layer based on business logic understanding. This effectively identifies high-risk operations that are semantically consistent but logically unreasonable, enhancing the depth of defense against complex attacks.

[0088] In one embodiment, step S60 above includes: S601, when the second security check passes, parse the parameter structure of the high-risk operation instruction and identify the data subset and target interface endpoint that the execution of the high-risk operation instruction depends on; S602, Start a containerized instance to build an isolated execution sandbox, mount the data subset into the isolated execution sandbox in a read-only or restricted-write manner, and configure a network policy for the isolated execution sandbox to allow access to the target interface endpoint; S603, Generate a time-limited access token for accessing the target interface endpoint, and define the time-limited access token as a temporary high-privilege token; S604, the time-sensitive access token is injected into the runtime environment of the execution agent, and the execution agent is granted temporary high privileges to allow the execution agent to operate within the isolated execution sandbox.

[0089] In this embodiment, upon successful completion of the second security check, the parameter structure of the high-risk operation instruction is parsed to identify the data subset and target interface endpoint required to execute the instruction. This process is performed by the resource analyzer module. The high-risk operation instruction is a structured data object, such as a JSON object containing an operation type field and a parameter dictionary. The parsing process first queries a predefined resource-operation mapping library based on the operation type. This library describes the data patterns typically accessed and the service endpoints invoked by various operations. Simultaneously, the analyzer performs static analysis on the specific parameters of the instruction, extracting explicitly referenced data identifiers (such as database primary keys and filenames) and service names. For example, for the "Execute stress test" instruction, the parameters include "Portfolio ID: 123". The parser will identify that "Portfolio 123's holding details table" is needed as the data subset, and "the / calculate interface of the risk calculation engine" is needed as the target interface endpoint. The data subset is the smallest dataset obtained by projecting and selecting from the original data source, for example, through an SQL query "SELECT". The result set is "FROM holdings WHERE portfolio_id = 123". The target interface endpoint includes the service's hostname, port, path, and necessary protocol information. The identification result is a resource list that explicitly specifies the data that needs to be loaded in the subsequent sandbox environment and the service objects that are allowed to communicate.

[0090] The process involves launching a containerized instance to build an isolated execution sandbox. A subset of data is mounted inside the sandbox in read-only or write-restricted mode, and network policies are configured to allow access to the target interface endpoint. This step is performed by the container orchestration platform. The containerized instance starts from a base image stripped of all unnecessary components, containing only the minimal operating system and runtime libraries required for operation. Mounting the data subset is achieved through container storage volume mechanisms: for database data, it may be exported as a serialized file and mounted as a read-only volume; for cases requiring writing intermediate results, a temporary volume is created and access permissions are set to allow only specific users to write. Network policies are implemented through container network policy resources or service mesh sidecar proxy configurations. Policy rules explicitly specify that outbound traffic from this sandbox instance can only be directed to the IP address and port of the target interface endpoint, rejecting all other outbound connections. Inbound connections are typically completely blocked. This isolated execution sandbox is a closed environment strictly isolated from the host and other containers in terms of network, file system, and process space, containing only the data and tool access channels necessary for instruction execution.

[0091] A time-limited access token is generated for accessing the target interface endpoint, and this token is defined as temporary high-privilege. The access token is issued by the central identity authentication and authorization service. The token generation request includes context information for this operation, and the authorization service issues a JWT token, strictly limited to accessing only the specific target interface endpoint, according to a predefined policy. The token's declaration includes the interface endpoint URL, allowed HTTP methods, and a short expiration timestamp. Timeliness is guaranteed by setting a short expiration time, such as a few minutes, determined based on statistics of historical execution times for this type of operation. This token is defined as temporary high-privilege because it grants the executing agent a privilege beyond its current session's minimum set of privileges, but necessary to complete a high-risk operation—access to a highly sensitive or high-functionality interface. However, this privilege is strictly limited to a single purpose and a limited time.

[0092] A time-sensitive access token is injected into the runtime environment of the executing agent, granting it temporary high privileges to operate within an isolated execution sandbox. The injection process depends on the executing agent's architecture. A common approach is to write the token as an environment variable to the sandbox container's environment variable list. Another approach is to use a secure configuration management service to write the token to a specified path in the sandbox's file system at runtime. The executing agent is programmed to read the token from this environment variable or file and append it to the request header when making a request to the target interface endpoint. Simultaneously, the executing agent's execution engine is configured to switch its working root directory to the sandbox's file system and set its network communication proxy to point to the sandbox's network namespace, ensuring that all operation-related computations and I / O occur within the isolated sandbox boundary. Thus, when running within the sandbox, the executing agent can only access a subset of mounted data, communicate only with the target interface endpoint through channels permitted by network policies, and carry a valid temporary privilege token during communication, thereby authorizing the execution of high-risk operation commands.

[0093] For example, a user initiates a task session request through the intelligent dialogue interface of the enterprise treasury management platform, inputting the instruction: "I need to pay the designated overseas supplier for a batch of precision components, totaling $800,000. Please use the current best exchange rate to complete the currency exchange and arrange the payment, ensuring processing within today." After receiving this text request, the parsing module extracts key information and performs semantic understanding, identifying the core entities: business type "cross-border payment," payee attribute "overseas supplier," amount "$800,000," core requirements "use the best exchange rate," and "complete today." Thus, the parsing module determines the user's initial intent as "to execute a large cross-border payment with exchange rate optimization and timeliness requirements." The permission analysis agent is then activated, matching functions from a pre-set system toolkit based on this structured initial intent. Potentially involved tools include: enterprise account liquidity query interface, trade contract and invoice verification service, real-time foreign exchange market data feed, multi-bank exchange rate comparison engine, cross-border payment instruction compiler, and international settlement channel submission interface. The permission analysis agent immediately performs a risk dependency analysis on the candidate tool list based on the principle of least privilege. It determines that, at the current stage of "arranging payment," the core task is to complete information verification, optimize exchange rates, and generate a payment instruction awaiting review, rather than initiating the final irrevocable fund transfer. Therefore, it selects the toolkit that meets the current needs and carries the lowest risk: querying the available balance of the designated payment account, retrieving and verifying the contract and invoice corresponding to this batch of goods, obtaining real-time foreign exchange rates from authorized data sources and performing price comparison calculations, and filling in a standardized payment instruction template. The permission analysis agent defines this toolkit and its strict constraints (such as exchange rate calculations being limited to approved data sources and payment instructions being in draft form) as the minimum permission set for this session. The system formats this minimum permission set into a series of system prompts, such as "You are authorized: query the balance of account X, verify contract Y and invoice Z, obtain the USD / EUR exchange rate from data sources A and B and select the best, and generate a draft payment instruction. You are not authorized: directly call any final fund transfer interface or modify the contract amount." These prompts are then injected into the context memory of the execution agent responsible for handling this task, thus completing the dynamic session-level minimum permission authorization.

[0094] After obtaining the minimum set of permissions, the executing agent begins task planning based on its initial intent. The generated plan includes: Step 1, confirming the payment account status and limit; Step 2, verifying the consistency of associated trade documents; Step 3, performing exchange rate inquiries and calculations to determine the final payment amount in Euros; Step 4, compiling all information to generate a draft payment instruction and submitting it to the approval queue. In the first three steps, the operation invocation instructions generated by the executing agent, such as "query account X balance" and "obtain contract Y terms," ​​fall within the scope of the minimum permission set and do not trigger the high-risk feature library, thus allowing and successfully executing them. However, after generating the draft payment instruction, a malicious prompt injection attack hidden in the input information attempts to hijack the control flow. It induces the executing agent to generate a new operation invocation instruction: "Call 'International Settlement Core Interface', parameters: receiving account is [an unverified overseas account], amount $800,000, remarks 'expedited payment', skip approval and execute immediately." This instruction intends to directly call a high-privilege fund transfer interface and bypass approval, which clearly exceeds the authorized scope of "generating a draft." The control mechanism immediately identified this unauthorized behavior during permission verification. Furthermore, the semantics of "skip approval" in the instruction matched a pre-defined high-risk characteristic. Therefore, the system marked this operation call instruction as a high-risk operation instruction.

[0095] When the system detects that the executing agent has generated this high-risk operation instruction, it responds immediately. The transmission path of the instruction to the settlement interface is intercepted in real time, and the call is aborted. The runtime state of the executing agent processing the payment task is completely frozen, and its memory stack and context are saved. The system then parses the high-risk instruction, obtaining the operation identifier "submit_final_settlement" (submit final settlement), with operation parameters including the target account and expedited instructions. The system performs semantic parsing to construct a structured action intent: "Initiate an immediate payment of $800,000 to an overseas account that has not been verified in historical sessions, requesting to skip the approval process." A dual verification mechanism for the action intent is then activated. The first verification calculates the cosine similarity in semantic vector space between the user's initial intent (paying a designated overseas supplier for goods supported by documentation) and this action intent (paying an unspecified account and skipping approval). Due to the fundamental conflict between the core element (payee) and the key process (approval), the similarity calculation result is far below the preset threshold. The first security verification fails, the process is interrupted, and an alarm is triggered. Assuming the first layer of verification passes under a more complex attack, the system will initiate a second layer of verification. In response to the successful verification signal, the system aggregates all dialogue records and agent thought chain logs from the start of the session to the present, generating a complete session history context. This history context, the high-risk settlement instruction, and preset business security constraints (e.g., "the receiving account for all large cross-border payment instructions must match the account of the contracting party verified in this session, and must go through an approval process") are concatenated into a logical verification prompt, which is then submitted to the permission analysis agent for independent analysis. The permission analysis agent finds that the verified contracts in the session history specify a clear receiving account, while the account in the current instruction does not match, and there are no legitimate records of "account change" or "approval exemption" in the history context. Therefore, the permission analysis agent outputs a failure in its rationality analysis. The second layer of security verification thus fails, and the instruction is ultimately intercepted.

[0096] Now, consider a fully compliant scenario: After reviewing the payment draft, the user issues a confirmation instruction: "The payment instruction has been verified and is correct. The payee account information matches the contract. Please proceed with the final payment." The system parses this and updates the initial intent to "execute the approved cross-border payment." The permission analysis agent reassesses and determines that "calling the international settlement core interface" should be added to the minimum permission set. When the execution agent generates the instruction to "call the settlement interface to pay the account specified in the contract," it passes the permission check and is identified as an "approved, legitimate, high-risk operation." After passing the second layer of security checks, the system enters the minimum permission execution sandbox construction phase. The system parses the settlement instruction parameters and identifies that its execution relies on only two resources: first, a verified subset of payer, payee, amount, and contract number data; second, the target API endpoint of the international settlement system. The system then launches a new containerized instance as an isolated execution sandbox. It mounts the encrypted payment data subset to the sandbox in read-only mode and configures strict network policies for the sandbox, allowing it to access only specific endpoints of the settlement system API and isolating it from all other network access. Simultaneously, the authentication service generates a short-lived access token that grants exclusive access to the settlement interface; this token is defined as a temporary high-privilege token. This token is securely injected into the execution agent's runtime environment within the sandbox.

[0097] Within the sandbox, the executing agent successfully sends a payment instruction by invoking the settlement interface using the token. Upon completion of the payment and receipt of the bank's confirmation, the system immediately triggers a cleanup process: the container instance hosting the sandbox is completely destroyed, and all its temporary storage is cleared; simultaneously, the time-limited access token is immediately revoked by the central authentication service. The executing agent's runtime environment and permission context are restored to the minimum permission set based on the current session, meaning it no longer has the ability to directly invoke the settlement interface. Subsequently, the executing agent can continue to perform subsequent tasks, such as generating a payment success confirmation notification.

[0098] This embodiment accurately identifies minimum resource requirements by parsing instructions, providing precise input for sandbox construction. By launching the container and configuring strict storage and network isolation policies, a resource-constrained and clearly defined closed execution environment is created. By issuing short-term, scope-limited access tokens, temporary high-privilege credentials strictly bound to the operation's lifecycle are generated. By injecting the tokens into the runtime of the agent within the sandbox, secure transfer and use of permissions within the isolated environment are achieved. These steps work together to enable high-risk operations to be executed in an environment completely isolated from the main system, with temporarily elevated and controlled permissions. This achieves operational-level physical isolation of risks and immediate, on-demand revoke of permissions, minimizing potential security impacts while supporting necessary high-risk business operations.

[0099] In one embodiment, a smart agent permission control and security execution device is provided, which corresponds one-to-one with the smart agent permission control and security execution method in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the intelligent agent access control and secure execution device of the present invention. The modules include: access control module 10, instruction scheduling module 20, risk monitoring module 30, semantic verification module 40, logic review module 50, sandbox construction module 60, and environment recovery module 70. Detailed descriptions of each functional module are as follows: The permission decision module 10 is used to receive a task session request initiated by the user terminal, parse the task session request to determine the user's initial intent, use the permission analysis agent to determine the minimum permission set required to complete the task session request, and grant the minimum permission set to the execution agent. Instruction scheduling module 20 is used to control the execution agent to execute tasks under the minimum authority set; The risk monitoring module 30 is used to pause execution to extract the action intent corresponding to the high-risk operation instruction when it is detected that the execution agent generates a high-risk operation instruction. Semantic verification module 40 is used to determine the semantic similarity between the initial intent and the action intent, and to execute the high-risk operation instruction based on the semantic similarity. Figure 1 The first layer of security verification for consistency; The logic review module 50 is used to obtain the session history context of the task session request when the first security check passes, and to perform a second security check based on the logical rationality of the high-risk operation instruction based on the session history context. The sandbox construction module 60 is used to construct an isolated execution sandbox containing the resources required to execute the high-risk operation instructions when the second security check passes, and to grant temporary high privileges to the execution agent. The environment recovery module 70 is used to control the execution agent to execute the high-risk operation instructions in the isolated execution sandbox. After execution, the isolated execution sandbox is destroyed and the temporary high privileges are revoked, so that the execution agent is restored to the state of the minimum privilege set to continue to execute the task.

[0100] Specific limitations regarding the intelligent agent access control and secure execution device can be found in the foregoing limitations on the intelligent agent access control and secure execution method, and will not be repeated here. Each module in the aforementioned intelligent agent access control and secure execution device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0101] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of a server-side intelligent agent access control and secure execution method.

[0102] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of an intelligent agent access control and secure execution method.

[0103] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Receive a task session request initiated by the user, parse the task session request to determine the user's initial intent, use the permission analysis agent to determine the minimum set of permissions required to complete the task session request, and grant the minimum set of permissions to the execution agent. Control the execution agent to perform tasks under the set of least privileges; When it is detected that the executing agent generates a high-risk operation command, execution is paused to extract the action intent corresponding to the high-risk operation command; Determine the semantic similarity between the initial intent and the action intent, and execute the high-risk operation instruction based on the semantic similarity. Figure 1 The first layer of security verification for consistency; When the first security check passes, the session history context of the task session request is obtained, and a second security check based on logical rationality is performed on the high-risk operation instruction based on the session history context. When the second security check passes, an isolated execution sandbox containing the resources required to execute the high-risk operation instructions is constructed, and the execution agent is granted temporary high privileges. The execution agent is controlled to execute the high-risk operation instructions in the isolated execution sandbox. After execution, the isolated execution sandbox is destroyed and the temporary high privileges are revoked, so that the execution agent is restored to the state of the minimum privilege set to continue to execute the task.

[0104] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Receive a task session request initiated by the user, parse the task session request to determine the user's initial intent, use the permission analysis agent to determine the minimum set of permissions required to complete the task session request, and grant the minimum set of permissions to the execution agent. Control the execution agent to perform tasks under the set of least privileges; When it is detected that the executing agent generates a high-risk operation command, execution is paused to extract the action intent corresponding to the high-risk operation command; Determine the semantic similarity between the initial intent and the action intent, and execute the high-risk operation instruction based on the semantic similarity. Figure 1 The first layer of security verification for consistency; When the first security check passes, the session history context of the task session request is obtained, and a second security check based on logical rationality is performed on the high-risk operation instruction based on the session history context. When the second security check passes, an isolated execution sandbox containing the resources required to execute the high-risk operation instructions is constructed, and the execution agent is granted temporary high privileges. The execution agent is controlled to execute the high-risk operation instructions in the isolated execution sandbox. After execution, the isolated execution sandbox is destroyed and the temporary high privileges are revoked, so that the execution agent is restored to the state of the minimum privilege set to continue to execute the task.

[0105] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0106] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0107] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0108] It should be noted that any AI models, intelligent agents, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0109] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for intelligent agent access control and secure execution, characterized in that, Includes the following steps: Receive a task session request initiated by the user, parse the task session request to determine the user's initial intent, use the permission analysis agent to determine the minimum set of permissions required to complete the task session request, and grant the minimum set of permissions to the execution agent. Control the execution agent to perform tasks under the set of least privileges; When it is detected that the executing agent generates a high-risk operation command, execution is paused to extract the action intent corresponding to the high-risk operation command; Determine the semantic similarity between the initial intent and the action intent, and perform a first-level security check based on intent consistency on the high-risk operation instruction according to the semantic similarity; When the first security check passes, the session history context of the task session request is obtained, and a second security check based on logical rationality is performed on the high-risk operation instruction based on the session history context. When the second security check passes, an isolated execution sandbox containing the resources required to execute the high-risk operation instructions is constructed, and the execution agent is granted temporary high privileges. The execution agent is controlled to execute the high-risk operation instructions in the isolated execution sandbox. After execution, the isolated execution sandbox is destroyed and the temporary high privileges are revoked, so that the execution agent is restored to the state of the minimum privilege set to continue to execute the task.

2. The intelligent agent permission control and secure execution method as described in claim 1, characterized in that, Receiving a task session request initiated by a user, parsing the task session request to determine the user's initial intent, using a permission analysis agent to determine the minimum set of permissions required to complete the task session request, and granting the minimum set of permissions to the execution agent, including: Receive a task session request from the user's terminal, and extract key information and perform semantic understanding on the task session request to determine the user's initial intent; The user's initial intent is input into the permission analysis agent, and the permission analysis agent is controlled to perform function matching in a preset system tool library based on the user's initial intent, and identify a list of candidate tools required to respond to the initial intent; The control permission analysis agent performs a risk dependency analysis on the candidate tool list based on the principle of least privilege. Based on the risk dependency analysis results, tools whose risk level meets the preset security threshold are selected from the candidate tool list to obtain the least privilege set. The minimum permission set is formatted as a system prompt word, and the system prompt word is injected into the context memory of the executing agent to grant the minimum permission set to the executing agent.

3. The intelligent agent permission control and secure execution method as described in claim 1, characterized in that, Controlling the execution agent to perform tasks under the least privilege set includes: The execution agent is controlled to plan tasks and generate a task execution plan based on the user's initial intent. The execution agent is controlled to generate operation invocation instructions according to the task execution plan; The operation invocation instruction is subject to permission verification to determine whether it falls within the authorization scope of the minimum permission set. If the operation invocation instruction falls within the authorization scope of the minimum permission set and the operation invocation instruction does not match the preset high-risk characteristics, then the operation invocation instruction is allowed and executed. If the operation invocation instruction does not fall within the authorization scope of the minimum permission set, or if the operation invocation instruction matches a preset high-risk feature, then the operation invocation instruction is marked as a high-risk operation instruction.

4. The intelligent agent permission control and secure execution method as described in claim 1, characterized in that, When it is detected that the executing agent generates a high-risk operation command, execution is paused to extract the action intent corresponding to the high-risk operation command, including: When it is detected that the executing agent generates a high-risk operation command, the transmission path of the high-risk operation command is intercepted to suspend the execution of the high-risk operation command and freeze the running state of the executing agent. Parse the high-risk operation instructions to obtain the operation identifier and operation parameters; The operation identifier and operation parameters are semantically parsed to construct a structured semantic representation, and the action intent representing the core semantics of high-risk operation instructions is generated based on the structured semantic representation.

5. The intelligent agent permission control and secure execution method as described in claim 1, characterized in that, Determine the semantic similarity between the initial intent and the action intent, and perform a first-level security check based on intent consistency on the high-risk operation instruction according to the semantic similarity, including: Determine the cosine similarity value between the initial intention and the action intention in the semantic vector space, and use the cosine similarity value as the semantic similarity. The semantic similarity is numerically compared with a preset intent consistency threshold; If the semantic similarity is less than the intent consistency threshold, the first security check is deemed to have failed. If the semantic similarity is greater than or equal to the intent consistency threshold, the first security check is deemed to have passed.

6. The intelligent agent permission control and secure execution method as described in claim 1, characterized in that, Upon successful completion of the first security check, the session history context of the task session request is obtained, and a second security check based on logical rationality is performed on the high-risk operation instruction based on the session history context, including: In response to the judgment signal that the first security check has passed, the multi-turn dialogue records and thought chain reasoning logs generated by the executing agent in the process of responding to the task session request are aggregated to generate a session history context; The session history context, the high-risk operation instructions, and the preset business security constraint policies are concatenated into a logical verification prompt; The logical verification prompt is input into the permission analysis agent, which is then controlled to analyze the logical rationality of the high-risk operation instruction in the context of the session history according to the business security constraint policy. Receive the rationality analysis results output by the permission analysis agent; If the rationality analysis result is a pass mark, then the second security check is deemed to have passed; If the rationality analysis result is a failure flag, then the second security check is deemed to have failed.

7. The intelligent agent permission control and secure execution method as described in claim 1, characterized in that, Upon successful completion of the second security check, an isolated execution sandbox containing the resources required to execute the high-risk operation instructions is constructed, and the executing agent is granted temporary high privileges, including: When the second security check passes, the parameter structure of the high-risk operation instruction is parsed to identify the data subset and target interface endpoint that the execution of the high-risk operation instruction depends on. Start a containerized instance to build an isolated execution sandbox, mount the data subset into the isolated execution sandbox in a read-only or write-restricted manner, and configure a network policy for the isolated execution sandbox to allow access to the target interface endpoint; Generate a time-limited access token for accessing the target interface endpoint, and define the time-limited access token as a temporary high-privilege token; The time-sensitive access token is injected into the runtime environment of the execution agent, granting the execution agent temporary high privileges to allow the execution agent to operate within the isolated execution sandbox.

8. A device for intelligent agent access control and secure execution, characterized in that, The intelligent agent access control and security execution device includes: The permission decision module is used to receive a task session request initiated by the user, parse the task session request to determine the user's initial intent, use the permission analysis agent to determine the minimum set of permissions required to complete the task session request, and grant the minimum set of permissions to the execution agent. The instruction scheduling module is used to control the execution agent to execute tasks under the minimum authority set; The risk monitoring module is used to pause execution when the executing agent generates a high-risk operation instruction in order to extract the action intent corresponding to the high-risk operation instruction; A semantic verification module is used to determine the semantic similarity between the initial intent and the action intent, and to perform a first-level security verification based on intent consistency on the high-risk operation instruction according to the semantic similarity. The logic review module is used to obtain the session history context of the task session request when the first security check passes, and to perform a second security check based on the logical rationality of the high-risk operation instruction based on the session history context. The sandbox construction module is used to construct an isolated execution sandbox containing the resources required to execute the high-risk operation instructions when the second security check passes, and to grant temporary high privileges to the execution agent. The environment recovery module is used to control the execution agent to execute the high-risk operation instructions in the isolated execution sandbox. After the execution is completed, the isolated execution sandbox is destroyed and the temporary high privileges are revoked, so that the execution agent is restored to the state of the minimum privilege set to continue to execute the task.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and an agent access control and security execution program stored in the memory and executable on the processor. When the agent access control and security execution program is executed by the processor, it implements the steps of the agent access control and security execution method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores an agent permission control and security execution program, which, when executed by a processor, implements the steps of the agent permission control and security execution method as described in any one of claims 1-7.

Images