A multi-agent collaboration-oriented digital asset security service method and system

Abstract

This invention discloses a method and system for providing secure digital asset services for multi-agent collaboration, belonging to the field of artificial intelligence security technology. The method establishes secure collaboration between a requesting agent (who does not possess the digital asset) and a service agent (who does possess the digital asset): the service agent creates a secure container instance in an isolated execution zone and injects the asset into the container's memory via an encrypted dedicated line; the requesting agent submits a task through a restricted interface, obtaining the processing result but not the asset itself; after collaboration is completed, the asset is destroyed along with the container. This invention achieves "usable but invisible, used and destroyed" in multi-agent collaboration, effectively protecting high-value digital assets such as 3D models, algorithm code, and sensitive data. The WorktoRent multi-agent digital asset collaboration platform built based on this invention is suitable for agent collaboration scenarios across trust domains.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence security technology and multi-agent system technology, specifically relating to a digital asset security service method and system for multi-agent collaboration, which is particularly suitable for data interaction, model invocation and code execution scenarios between agents under different trust domains. Background Technology

[0002] With the development of large language models and multi-agent systems, autonomous collaboration among agents has become a key model for solving complex tasks. In practical applications, different agents often belong to different owners and possess different types of digital assets. For example: A certain intelligent agent possesses expensive 3D modeling assets; A certain intelligent agent possesses core algorithm code or proprietary models; A certain intelligent agent possesses sensitive business data within an enterprise.

[0003] In the process of collaboration, an intelligent agent that does not possess a specific digital asset (hereinafter referred to as "requesting agent") often needs to invoke the capabilities of another intelligent agent that possesses the digital asset (hereinafter referred to as "service agent") to complete the task.

[0004] However, existing multi-agent collaboration frameworks suffer from the following security risks, which means that large-scale cooperation between agents with different ownership is currently virtually nonexistent.

[0005] Risk 1: Direct Exposure of Assets. In traditional collaboration models, the service provider's agent often needs to transfer digital assets (such as model files and data files) to the requesting agent or load them in its local environment. This results in the complete exposure of digital assets to the requesting agent, posing a risk of copying, reverse engineering, or unauthorized retention.

[0006] Risk 2: Lack of execution isolation. When the requesting agent submits a task, if it is executed directly in the main environment of the service agent, the service environment may be attacked by maliciously constructed input data, resulting in sensitive data leakage or system damage.

[0007] Risk 3: Uncontrollable collaboration process. Once the service begins, the service provider's agent has difficulty controlling how, how often, and for how long the assets are used, making it impossible to achieve refined management of "authorization on demand and destruction after use".

[0008] Risk 4: Cross-domain trust challenges. When the requesting agent and the service agent are in different trust domains (such as different enterprises or different private network environments), how to establish a reliable secure channel and ensure that assets do not cross trust boundaries is an urgent problem to be solved.

[0009] Therefore, there is an urgent need for a digital asset security service method for multi-agent collaboration, which can realize the "usable but invisible, and destroyed after use" nature of digital assets while ensuring smooth collaboration between agents. Summary of the Invention

[0010] The purpose of this invention is to provide a digital asset security service method and system for multi-agent collaboration. By establishing a secure and isolated execution environment, the requesting agent can obtain the digital asset processing capabilities of the service agent, but cannot obtain the digital asset itself, thereby achieving secure and controllable multi-agent collaboration.

[0011] To achieve the above objectives, this invention employs the following method for providing digital asset security services oriented towards multi-agent collaboration (see appendix). Figure 1 As shown), it includes the following steps.

[0012] 1. Steps for building a collaborative session.

[0013] A requesting agent that does not possess digital assets sends a collaboration request to a service agent that does possess digital assets. These digital assets include, but are not limited to, high-value data forms such as 3D model files, proprietary algorithm code, sensitive business data, and machine learning model weights. Upon receiving the request, the service agent verifies the identity and permissions of the requesting agent. After successful verification, the service agent instantiates a secure container logically isolated from the requesting agent. The secure container can be implemented in various forms, including but not limited to Docker containers, Linux Containers (LXC), independent Virtual Private Cloud (VPC) environments, or physically isolated servers, ensuring basic isolation of the execution environment.

[0014] 2. Dynamic asset orchestration steps.

[0015] Based on task requirements, this system or service provider's Agent controls the resource center to inject the required digital assets into the protected area (including but not limited to the memory area or encrypted area) of the secure container through an encrypted channel, thus constructing a temporary execution environment for "Assets as a Service".

[0016] In this process, the present invention adopts an innovative "fragmented streaming injection" mechanism to improve transmission security. For example, the resource center divides the digital asset into several unordered data fragments and assigns an independent temporary decryption key to each fragment; the secure container pulls the data fragments as needed, decrypts them using the corresponding temporary keys, and reassembles them into a complete usable asset in memory; after the reassembly is completed, the secure container immediately discards all temporary decryption keys.

[0017] This mechanism ensures that digital assets do not exist in complete plaintext form during transmission, and that the key has a one-time use characteristic, effectively preventing eavesdropping and interception on the transmission link.

[0018] 3. Limited execution steps.

[0019] This system or the requesting agent submits input data and operation instructions to the secure container through a restricted service interface. The secure container then invokes digital assets residing within the protected area to perform processing. To ensure asset security, this step implements multiple protective measures: a one-way access control policy for the protected area, allowing only execution processes within the secure container to read digital assets; and prohibiting any form of memory dumping, debug attachment, snapshot creation, and network outreach operations. The restricted service interface only accepts structured task parameters and strictly rejects any direct addressing requests to the file system or memory space, preventing unauthorized access at the interface level.

[0020] Real-time arbitration by the policy engine: The security container's built-in policy engine monitors or arbitrates the processing in real time, including but not limited to: Output content filtering: Perform semantic analysis or feature matching on the output results to remove metadata, intermediate variables or high-dimensional feature vectors that may be used to reverse-engineer the asset ontology, and prevent the asset from being reconstructed from the output results. Behavioral compliance detection: Monitor the characteristics of input data, identify and block probing attacks or reverse engineering attempts, and immediately trigger session self-destruct steps once abnormal behavior is detected.

[0021] In addition, the system or service provider's agent executes global security policy control during the collaboration process. The security policy includes at least one of the following: session validity period limit, call count limit, allowed operation type limit, and output data size limit, to achieve fine-grained collaboration management.

[0022] 4. Session self-destruction steps.

[0023] When a collaborative task ends or a security termination condition is triggered (such as timeout or violation detection), the secure container immediately terminates the relevant network connection, performs a secure erase operation on the protected content, or directly destroys the container instance to restore the digital assets to an unusable state and completely eliminate the risk of asset residue.

[0024] The present invention also provides a digital asset security service system for multi-agent collaboration, comprising the following modules.

[0025] 1. Requester Agent Module Deployed in untrusted or low-trust domains, it is used to initiate collaborative tasks, does not have access to digital assets, and can only obtain processing results through limited interfaces.

[0026] 2. Service Provider Agent Module Deployed within a trusted control domain, this module acts as an agent for the asset owner, responsible for collaborative authorization decisions, security policy formulation, and lifecycle management of the execution environment. It also includes a fine-grained authorization unit, used to dynamically generate differentiated security policies based on the requesting agent's identity level and task context. These security policies cover a subset of allowed asset functions, allowed data precision levels for output, session validity duration, and single-use computing resource quotas, achieving collaborative authorization under the "principle of least privilege."

[0027] 3. Secure Orchestration Engine This engine is used to respond to instructions from the service provider's agent, dynamically create isolated secure container instances, and coordinate the encrypted transmission and memory injection of digital assets. Internally, it includes an asset sharding injection unit configured to: convert stored encrypted digital assets into sharded ciphertext streams for transmission; push the sharded ciphertext streams to the secure container via a dedicated encrypted tunnel; and ensure that the sharded ciphertext streams are out of order during transmission, only being reassembled into plaintext assets within the secure container's memory, thus guaranteeing absolute security of the transmission link.

[0028] 4. Isolate the execution environment Running in a physically or logically isolated zone, this environment hosts secure container instances and provides memory-only compute space, ensuring that digital assets are physically isolated from persistent storage during execution. This environment is implemented using a Trusted Execution Environment (TEE), a standalone Virtual Private Cloud (VPC), or a physically isolated server, and each secure container instance is logically isolated from the others, preventing them from accessing each other's memory space.

[0029] 5. Microkernel Security Proxy Integrated within a secure container instance, it serves as a last line of defense. The microkernel security proxy is used for: Intercept all system calls and prevent unauthorized file writing, network connections, and process creation. Monitor memory page access patterns and identify abnormal scanning behavior; When a violation is detected, the system can automatically trigger the destruction process without waiting for external instructions, thus achieving immediate loss mitigation.

[0030] In summary, this method can be used for direct collaboration between the requesting agent and the service agent, or to create a collaborative system for multi-agent assistance. Beneficial effects

[0031] Compared with the prior art, the present invention has the following significant advantages.

[0032] 1. Digital assets are "usable but not visible": Through dynamic asset orchestration and memory-resident technology, the requesting agent obtains the ability to process digital assets, but cannot access the asset file itself or its plaintext storage form throughout the process, effectively solving the problem of core asset leakage in cross-trust domain collaboration.

[0033] 2. High security during transmission: The “fragmented streaming injection” mechanism, combined with out-of-order transmission and independent temporary keys, ensures that even if the transmission channel is monitored, attackers cannot recover the complete digital assets, greatly improving the anti-attack capability of the data transmission process.

[0034] 3. Strong controllability of the execution process: A comprehensive defense system is built through one-way access control, restricted service interfaces, and microkernel security proxies. The real-time arbitration mechanism of the policy engine can proactively identify and block probing attacks and reverse engineering attempts, realizing a shift from passive defense to proactive defense.

[0035] 4. Fine-grained authorization and flexibility: The fine-grained authorization unit of the service agent module supports dynamic generation of security policies based on context, enabling differentiated control over different levels of request agent and different types of tasks, balancing collaboration flexibility and security.

[0036] 5. Thorough destruction mechanism: The session self-destruction step ensures that temporarily loaded assets are completely destroyed with the container, leaving no data residue and meeting the compliance requirements for sensitive data processing. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the multi-agent cooperative system architecture provided by the present invention.

[0038] Figure 2 This is a flowchart illustrating the collaborative method provided in a specific embodiment of the present invention. Detailed Implementation

[0039] The following describes specific embodiments (see appendix). Figure 2 The present invention will be further described in detail below (as shown).

[0040] Specific Implementation Example 1: The present invention unit assisted a research institute in eastern Zhejiang in building a digital twin simulation and evaluation platform for smart cities based on multi-agent collaboration.

[0041] In this embodiment, a research institute in eastern Zhejiang (the requesting party) needs to use a high-precision three-dimensional building model of an architectural design institute (hereinafter referred to as Asset Party A) and a flood simulation algorithm model of the applicant of this invention (hereinafter referred to as Asset Party B, Model Technology Company) to conduct an urban flood risk assessment and generate an assessment report.

[0042] I. System Architecture Deployment.

[0043] The system described in this embodiment includes the following.

[0044] 1. Request Agent Module: Deployed in the untrusted domain of the research institute, it initiates simulation task requests as a client.

[0045] 2. Service Agent Module: This module includes two service agents representing the design institute and the model technology company, respectively. They are deployed in their respective trusted control domains and are responsible for managing high-value digital assets (3D model weights, simulation algorithm code).

[0046] 3. Security Orchestration Engine: Deployed in the cloud control plane, responsible for global task scheduling and resource allocation.

[0047] 4. Isolated Execution Environment: Composed of a cluster of GPU servers with high-performance A800 graphics cards supporting Trusted Execution Environment (TEE), providing physically isolated computing space.

[0048] II. Specific Implementation Process.

[0049] Step S1: Task reception and dynamic orchestration.

[0050] The requesting agent submits a "Flood Simulation in Block A of the City" task request to the secure orchestration engine. When a complex task is broken down into multiple sub-tasks, this system designs a centralized orchestration engine to determine which agent injects assets and when. The secure orchestration engine parses the task, generates a directed acyclic graph (DAG) workflow, dynamically schedules the creation and destruction order of secure containers, and manages cross-container dependency injection.

[0051] Node 1: Loads the 3D model assets of the design institute.

[0052] Node 2: Load the flood simulation algorithm assets of Model Technology Company.

[0053] Node 3: Perform simulation calculations and output the results.

[0054] Based on the DAG graph, the orchestration engine determines that two cascaded safety container instances need to be created and plans the data flow: the 3D model data will serve as the input environment for the simulation algorithm.

[0055] Step S2: Resource elastic scaling and container preheating.

[0056] For tasks with high real-time requirements, this system also proposes the concept of a "hot pool". A batch of secure containers are pre-instantiated and injected into the base environment, and asset fragments are quickly mounted only at the beginning of the session; after the session ends, the containers are not destroyed, but are cleaned of memory and returned to the hot pool.

[0057] The security orchestration engine detected a sudden surge in concurrency in the current request queue, triggering an elastic scaling strategy. The system detected that the task was a high-frequency "real-time simulation" task and directly extracted two pre-instantiated security containers (pre-installed with CUDA environment and basic OS dependencies) from the preset "hot pool," avoiding cold start latency. Simultaneously, the system automatically expanded the GPU resource quota of the isolated execution environment based on the predictive model.

[0058] Step S3: Chain collaboration and asset injection.

[0059] The system establishes a chain-like collaboration channel: 1. Model Injection: Agent A, the service provider, controls the resource center, segments the 3D model assets, and injects them into the protected memory area of ​​the secure container A through an encrypted tunnel.

[0060] 2. Algorithm Injection: The service provider Agent B injects the flood simulation algorithm (deep learning model) into the secure container B.

[0061] 3. Cascading Mounting: The orchestration engine maps the protected memory area of ​​secure container A to secure container B via a high-speed internal bus, enabling the simulation algorithm to directly read 3D model data without having to write the model data to disk or transfer it externally. This process achieves chained data flow among multiple agents.

[0062] Step S4: Zero-knowledge proof verification.

[0063] Before the computation begins, the requesting agent verifies the authenticity of the algorithm injected by the service agent B. Service agent B generates a zero-knowledge proof (ZKP) within secure container B, proving that the hash value of the loaded model matches the "high-precision flood simulation algorithm" stipulated in the contract. Once the requesting agent's verification is successful, the task continues.

[0064] Step S5: Secure execution and side-channel defense.

[0065] Simulation calculation begins. The requesting agent inputs rainfall parameters.

[0066] Side-channel defense: During computation, the microkernel security agent monitors memory access patterns in real time.

[0067] LLM Report Generation: After the simulation ends, the system automatically calls the Lightweight Large Language Model (LLM) integrated within the container, reads the simulation result data, and generates a "Flood Risk Assessment Report for a Certain Block in a Certain City" in natural language format. This process utilizes the layered loading technology of GPU memory to ensure that the weights of the large model are not leaked.

[0068] Step S6: 3D interaction and rendering stream output.

[0069] The requesting agent requests to view the visualization of the simulation process. Secure container B invokes the GPU to perform ray tracing rendering, generating video stream data. The system does not return the original 3D model file; it only pushes the rendered encrypted video stream and encrypted geometric metadata to the requesting terminal. The requesting agent can adjust the viewing angle in real time, but cannot obtain the geometric mesh data.

[0070] Step S7: Output the results and embed the watermark.

[0071] This system also incorporates a method for embedding and tracking digital watermarks in the output results of digital assets. During the output filtering stage of the strategy engine, information such as the requester ID and timestamps are implicitly encoded and embedded into the output results. In the event of asset leakage, the source of the leakage can be traced by extracting the watermark.

[0072] In this case, the policy engine triggers the watermark embedding unit when outputting the "Evaluation Report" and simulation video. The system embeds the requesting agent's ID "UrbanPlan_001", timestamp, and task hash value into the least significant bit (LSB) of the video frame and the metadata of the PDF report using steganography.

[0073] Step S8: Metering and Billing and Container Destruction.

[0074] This system embeds a metering module within a secure container to record the number of times digital assets are accessed, computation time, and data throughput. Leveraging the remote proof capabilities of a TEE (Trusted Execution Environment), it generates an immutable usage bill and automatically triggers smart contracts for settlement. This resolves the "billing disputes" issue in cross-trust domain collaboration, achieving "pay-as-you-go, data immutability."

[0075] After the task is completed, the microkernel security agent calculates the resource consumption of this collaboration.

[0076] The system generates an encrypted invoice. Finally, the system triggers a session self-destruct process: secure containers A and B disconnect from the network, perform random number overwrite erasure on the memory area, and release the containers to ensure the complete destruction of digital assets.

[0077] As can be seen from the above embodiments, the present invention not only achieves basic asset security isolation, but also supports complex cross-Agent workflows through a chain collaboration mechanism; and ensures real-time performance under high concurrency through a warm-up and scaling mechanism.

[0078] Subsequently, our organization further improved the system and launched the multi-agent collaboration platform, WorkToRent Multi-Agent Cross-Trust Domain Digital Asset Collaboration Platform (website: http: / / agent.worktorent.com), today. This system connects the digital asset supply-side node cluster with the application request-side agent node cluster.

[0079] Supply-side node cluster: Composed of the provider's developer terminals. The supply-side nodes store confidential digital content originals. The supply-side nodes register their service capabilities with the platform through a locally deployed management agent (WorkToRent IDE plugin).

[0080] Application-side node cluster: Composed of user terminals. Application-side nodes receive instructions from human users through locally deployed application agents (such as web browsers or app clients) and parse these instructions into computational requirements. During use, the application-side agents initiate execution requests to the control platform through the WorkToRent client.

[0081] Control Platform: A central scheduler deployed on cloud infrastructure. Currently, its functions include: receiving application requests; matching registered provider resources based on the requests; and dynamically and independently creating temporary, isolated Linux container instances for each pair of "application agent-provider agent" interactions within the container cluster.

[0082] Translation execution environment: This refers to the dynamically created Linux container instance described above. This instance does not contain any core assets from the provisioning side, but only the default runtime environment and WorkToRent SDK.

[0083] This solution provides a comprehensive lifecycle security and efficiency guarantee system for multi-agent collaboration.

Claims

1. A method for providing digital asset security services for multi-agent collaboration, characterized in that, include: Collaboration session construction steps: The requesting agent who does not possess digital assets sends a collaboration request to the service agent who possesses digital assets (including but not limited to 3D model files, proprietary algorithm code, sensitive business data, machine learning model weights) (or sends the request through the system). After verification and authorization, a secure container (including but not limited to Docker, Linux Container, independent virtual private cloud, or physically isolated server) that is logically isolated from the requesting agent is instantiated. Dynamic asset orchestration steps: The system or service agent injects the required digital assets (including but not limited to data streams) into the protected area (including but not limited to memory area and encrypted area) of the secure container through an encrypted channel according to task requirements, thus constructing a temporary execution environment for "asset as a service". Capability-restricted execution steps: The system or the requesting agent communicates with the secure container through the restricted service interface (including but not limited to submitting input data and operation instructions). The secure container calls the digital asset to perform processing and uses the built-in policy engine to monitor or arbitrate the processing in real time, allowing only the output of results that meet the preset capability boundaries, and preventing the leakage of the digital asset itself or its derived sensitive data. Session self-destruction steps: When a collaborative task ends or a security termination condition is triggered, the system restores the digital assets to an unavailable state, including but not limited to terminating the connection of the secure container, performing erasure on the protected content, or destroying the container instance.

2. The method according to claim 1, characterized in that, The dynamic asset orchestration step employs a "sharded streaming injection" mechanism, including one of the following: The resource center divides digital assets into several unordered data fragments and assigns an independent temporary decryption key to each fragment; The secure container pulls and decrypts data fragments on demand, reassembles them into complete, usable assets in memory, and immediately discards all temporary decryption keys after reassembly to ensure that the assets do not exist in complete plaintext form during transmission.

3. The method according to claim 1, characterized in that, The protected memory region is configured with a "one-way access control policy", including one of the following: Only processes running inside the secure container are allowed to read digital assets; Any form of memory dump, debug attachment, snapshot creation, or network outgoing operation is prohibited; The restricted service interface only accepts structured task parameters and rejects any direct addressing requests to the file system or memory space.

4. The method according to claim 1, characterized in that, The policy engine performs real-time arbitration and includes one of the following steps: Output content filtering: Perform semantic analysis or feature matching on the output results to remove metadata, intermediate variables or high-dimensional feature vectors that may be used to infer the asset ontology; Behavioral compliance detection: Monitor the characteristics of input data, identify and block probing attacks or reverse engineering attempts, and immediately trigger session self-destruct steps once abnormal behavior is detected.

5. The method according to claim 1, characterized in that, The service agent executes security policy controls during the collaboration process. The security policy includes at least one of the following: session validity period limit, call count limit, allowed operation type limit, and output data size limit.

6. The system according to any of the preceding claims, characterized in that, include: The requesting agent module is deployed in an untrusted or low-trust domain to initiate collaborative tasks and does not have access to digital assets. The service provider Agent module is deployed in the trusted control domain. As an agent of the asset owner, it is responsible for collaborative authorization decisions, security policy formulation, and execution environment lifecycle management. The security orchestration engine is used to respond to the instructions of the service agent, dynamically create isolated secure container instances, and coordinate the encrypted transmission and memory injection of digital assets. An isolated execution environment, running in a physically or logically isolated area, is used to host secure container instances, providing memory-only compute space to ensure that digital assets are physically isolated from persistent storage during execution.

7. The system according to any of the preceding claims, characterized in that, The secure orchestration engine includes an asset sharding injection unit, which is configured as follows: Convert stored encrypted digital assets into fragmented ciphertext streams for transmission; The fragmented ciphertext stream is pushed to a secure container through a dedicated encrypted tunnel; The fragmented ciphertext streams are out of order during transmission and are only reassembled into plaintext assets in the memory of a secure container.

8. The system according to any of the preceding claims, characterized in that, The secure container instance integrates a microkernel security agent, which is used for: Intercept all system calls and prevent unauthorized file writing, network connections, and process creation. Monitor memory page access patterns and identify abnormal scanning behavior; When a violation is detected, the destruction process can be triggered automatically without external instructions.

9. The system according to any of the preceding claims, characterized in that, The service provider Agent module also includes a fine-grained authorization unit, which is used for: Based on the identity level of the requesting agent and the task context, dynamically generate differentiated security policies; The security policy includes a subset of asset functions that can be invoked, the level of precision of the data that can be output, the session validity period, and the single computing resource quota.

10. The system according to any of the preceding claims, characterized in that, The isolated execution zone is implemented using a Trusted Execution Environment (TEE), a standalone Virtual Private Cloud (VPC), or a physically isolated server. The secure container instances are logically isolated from each other and cannot access each other's memory space.

Images