A Trusted Execution System and Method for AI Agent Behavior Based on On-Chain Policy Consensus

Abstract

The application discloses an AI Agent behavior credible execution system and method based on on-chain strategy consensus. The system inserts a layer of on-chain governance type security kernel between the AI Agent and the operating system, standardizes the operation intention of the Agent through an action intention intermediate representation (Action Intent IR), automatically approves the operation intention of the Agent by a blockchain strategy virtual machine (Policy VM) according to on-chain rule contracts, generates a capability token (Capability Permit) with time constraint, and finally calls the underlying tool or system resource after verifying the legality of the token by a trusted executor (Trusted Executor). The application solves the core problems of the existing AI Agent security model, such as approval fatigue, user inability to conduct substantial review, and full-link non-accountability, realizes the authorization, audit, accountability and non-repudiation of the Agent behavior, and provides credible infrastructure support for the AI Agent to enter the enterprise production environment.

Description

Technical Field

[0001] This invention relates to a trusted execution system and method for AI Agent behavior based on on-chain policy consensus, which is applicable to enterprise-level application scenarios that require authorization management, compliance auditing and accountability for system-level operations of AI Agents. Background Technology

[0002] With the continuous improvement of large language model (LLM) capabilities, AI agents are gradually evolving from conversational assistants into autonomous intelligent agents capable of planning, calling tools, and executing system operations. A typical AI agent execution chain is: user command → LLM → Tool Call → OS / Cloud.

[0003] However, current AI agent security models are extremely rudimentary and face the following three core problems: (i) Approval fatigue. Existing agent-based security solutions rely on users to confirm each system operation one by one. For example, when completing a complex automation task, the agent may trigger dozens of operations in succession, such as rm, mv, chmod, docker exec, pip install, git push, ssh, and systemctl restart, causing users to be frequently interrupted and ultimately tend to click "allow" indiscriminately, effectively rendering security zero. This problem is highly similar to the phenomenon of browser permission pop-ups causing users to click invalidally.

[0004] (ii) Lack of substantive user review capabilities. Even when users participate in the approval process, most users are unable to accurately assess the security risks and scope of impact of technical commands such as "find . -type f -name *.tmp -delete", rendering manual approval a pseudo-security.

[0005] (iii) No accountability across the entire chain. When an AI Agent performs an operation that results in an anomaly, due to the lack of a unified behavior recording mechanism, it is impossible to accurately determine the following attribution of responsibility: erroneous instructions caused by LLM hallucination, bugs in the tool itself, prompt injection attacks, user misoperation, man-in-the-middle tampering, and attacks on the Agent during runtime.

[0006] Existing technical solutions such as MCP (Model Context Protocol) and OpenAI Function Calling only provide a calling protocol layer between LLM and tools, and do not solve the aforementioned security governance issues. They lack trusted recording of behavior, policy-based approval, and non-repudiation mechanisms.

[0007] While there has been some research in the field of blockchain-based identity and access control, there is still no technical solution that combines blockchain policy consensus with intermediate representation of AI agent behavior to form a complete closed-loop trusted execution system. Summary of the Invention

[0008] The purpose of this invention is to provide a trusted execution system and method for AI Agent behavior based on on-chain policy consensus. This system establishes an on-chain governance-type security kernel between the AI ​​Agent and the operating system, solving the three core problems of approval fatigue, lack of substantive review, and lack of accountability across the entire chain in existing solutions. This enables the AI ​​Agent's behavior to have the capabilities of authorization, restriction, auditability, accountability, and non-repudiation, thereby meeting the security and compliance requirements of enterprise production environments.

[0009] The technical solution of the present invention: A trusted execution system for AI agent behavior based on on-chain policy consensus includes: The user intent layer is used to receive natural language commands from users and pass them to the LLM planning layer. The LLM planning layer is used to reason about user intent and decompose tasks to generate a structured intermediate representation of behavioral intent. The behavioral intent intermediate representation layer is used to describe the agent's operational intent in a standardized format. The agent must not bypass this layer to directly call the underlying tools. The blockchain strategy virtual machine layer is used to make automated policy decisions based on the intermediate representation of behavioral intent according to the policy contracts stored on the chain. When the behavior is compliant, it generates capability tokens, and when the behavior is non-compliant, it rejects and records the violation. Capability token layer, used to store and transfer capability tokens generated through blockchain policy approval; The trusted executor layer, deployed in an isolated sandbox environment, is used to receive capability tokens. It verifies the legality and integrity of the tokens before executing the corresponding system operations and writes the execution logs to an immutable on-chain ledger. The operating system and tools layer provides underlying system calls, cloud service interfaces, and tool APIs for the trusted executor layer. The layers are sequentially invoked through a one-way trust chain. The behavior hash in the intermediate representation of the behavior intent generated by the Agent is strongly bound to the behavior hash in the capability token to prevent content tampering during the execution phase.

[0010] The intermediate representation of the behavioral intent adopts a standardized JSON format, which includes at least the fields of behavior type (action), operation target (target), operation reason (reason), scope (scope), risk level (risk_level), and estimated impact (estimated_impact); the capability token includes at least the fields of token identifier (permit_id), behavior hash (action_hash), validity period (expires), constraints (constraints), and authorization signature (signature).

[0011] The blockchain policy virtual machine layer includes the following set of policy rules: file system access rules, defining a whitelist of paths that the Agent is allowed to operate on and a blacklist of paths that the Agent is prohibited from operating on; network access rules, defining a whitelist of external domain names that the Agent is allowed to access and a blacklist of IP ranges that the Agent is prohibited from accessing; process execution rules, defining the types of processes that the Agent is allowed to start and a list of high-risk commands that the Agent is prohibited from executing; and risk-level autonomous rules, which automatically approve actions with a risk level below a preset threshold and trigger multi-signature consensus or manual review processes for high-risk actions.

[0012] The capability token is generated by the blockchain policy virtual machine layer through on-chain smart contract functions, and its non-forgeability is ensured by asymmetric cryptographic signature. Before execution, the trusted executor layer must verify the signature, behavior hash consistency, and token validity period. If any of the three verifications fails, execution will be refused and an alarm will be recorded.

[0013] The blockchain policy virtual machine layer supports a multi-validator consensus approval mechanism, including: There are at least two independent validator nodes, each of which undertakes different policy responsibilities, including security model verification, organizational policy verification, cost compliance verification, and privacy protection verification. The consensus protocol requires that high-risk behavioral intentions must obtain the joint signatures of a preset number of validator nodes in order to generate a valid capability token; A dynamic weighting mechanism dynamically adjusts the minimum number of validators participating in the consensus based on the risk level field of the behavioral intent. It includes a fully auditable component that records all or a combination of the following hash digests on the chain: user prompt word hash, LLM model identifier hash, behavioral intent intermediate representation hash, capability token hash, tool call hash, and execution result hash, to achieve non-repudiation and end-to-end accountability of agent operations.

[0014] The system is deployed in a consortium blockchain architecture, which consists of enterprise nodes, policy verification nodes, and audit nodes. Enterprise nodes are responsible for submitting behavioral intentions and receiving capability tokens; policy verification nodes are responsible for performing compliance verification and token issuance; and audit nodes are responsible for immutably recording the entire operation ledger. Communication between the various types of nodes is ensured to be complete through TLS two-way authentication and message signing. The operation logs on the consortium blockchain are not exposed to the public network.

[0015] A trusted execution method for AI Agent behavior based on on-chain policy consensus includes the following steps: S1: The LLM planning layer receives user intent, performs reasoning and planning, and encodes the operation to be executed into an intermediate representation of behavioral intent, which only contains the semantic description of the operation. S2: The intermediate representation layer of behavioral intent calculates the behavioral hash of the intermediate representation and submits it along with the operation context to the blockchain policy virtual machine layer; S3: The blockchain strategy virtual machine layer performs compliance verification on the intermediate representation based on the on-chain strategy contract. If the verification passes, a capability token with a binding behavior hash is generated and signed; if the verification fails, it is rejected and the rejection event is recorded on the chain. S4: The trusted executor layer receives the capability token, verifies the token signature, behavior hash consistency and validity period in sequence, and performs the corresponding operation within the constraint conditions after all verifications are passed. S5: The trusted executor layer writes the execution result, execution timestamp, and execution environment summary into the on-chain audit ledger; S6: The system associates and stores the operation records in the audit ledger with the intermediate representation of the original behavioral intent, supporting post-event auditing, execution replay, and responsibility determination.

[0016] In step S3: The blockchain strategy virtual machine layer classifies the risk level of behavior. For behavior intentions with a risk level lower than the preset security threshold, capability tokens are automatically generated without user intervention. For behavior intentions with a risk level higher than the preset security threshold, a multi-validator consensus process is triggered or a simplified approval notification is pushed to the authorized user. The simplified approval notification includes an operation summary, estimated impact scope and compliance status, but does not include the original command line content.

[0017] Before step S2, the intermediate representation layer of behavioral intent performs a pre-evaluation of the estimated impact field of behavioral intent. If the pre-evaluation result exceeds the current authorized range, a range over-limit signal is returned to the LLM planning layer before submitting the strategy for approval. The LLM planning layer then splits or downgrades the operation plan.

[0018] The beneficial effects of this invention are: (1) Fundamentally eliminate approval fatigue: By adopting a risk-level-based hierarchical autonomous approval strategy, low-risk operations are included in the scope of automatic approval. Users only need to confirm high-risk operations in a streamlined manner, changing from item-by-item approval to authorization boundary management, which greatly reduces the approval burden.

[0019] (2) Establish a credible chain of behavioral responsibility: By anchoring the entire chain of user prompts, model identifiers, behavioral intentions, execution tokens, tool calls and execution results, end-to-end non-repudiation is achieved, making the attribution of responsibility for AI Agent operations technically verifiable for the first time.

[0020] (3) Provide an enterprise-acceptable security foundation for AI Agent: Through a limited scope of behavior, auditable operation logs, traceable execution links, and replayable execution audits, AI Agent can meet the core requirements of enterprises in terms of compliance, security, and IT governance.

[0021] (4) Provide a technical basis for AI liability insurance: The audit ledger and strategy level system of this invention provide an objective and verifiable technical basis for insurance institutions to define the security level of AI Agents.

[0022] (5) Decoupling security policies and execution logic: Policy rules are stored on the chain and are completely decoupled from the Agent execution logic, supporting dynamic adjustment of security policies without modifying the Agent code. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the overall architecture of the AI ​​Agent behavior trusted execution system based on on-chain policy consensus as described in this invention.

[0024] Figure 2 This is a schematic diagram of the Action Intent IR data structure and hash calculation process.

[0025] Figure 3 This is a schematic diagram of the strategy rule set and contract approval logic of the blockchain strategy virtual machine layer.

[0026] Figure 4 This is a schematic diagram of the three-step verification process for the capability token data structure and trusted executor.

[0027] Figure 5 This is a schematic diagram of the hash chain structure of the end-to-end audit ledger.

[0028] Figure 6 This is a schematic diagram of an enterprise-level deployment architecture based on a consortium blockchain. Detailed Implementation

[0029] Example 1: The core innovation of this invention lies in changing the execution chain of the AI ​​Agent from: LLM → Tool → OS Transformed into: LLM → Action Intent IR → Blockchain Policy VM → Signed Permit → Trusted Executor → OS The technical solution of this invention includes the following key technical modules: 1. Action Intent IR. This invention introduces a semantic isolation layer between LLM output and actual system execution. Unlike directly generating shell commands or API calls, the output of the LLM planning layer is forcibly encoded into a standardized JSON format, containing at least the fields of action type, target, reason, scope, risk level, and estimated impact. After IR calculation, the system normalizes and serializes the JSON object and calculates its SHA-256 hash to generate an action hash, which is strongly bound to the subsequent capability token to prevent content tampering attacks during the execution phase. Agents must not bypass this layer to directly call underlying tools.

[0030] 2. Blockchain Policy Virtual Machine (BPM). The Blockchain Policy Virtual Machine layer runs on top of the consortium blockchain node and executes policy decisions through smart contracts. The set of policy rules stored on the chain includes: (1) File system access rules: defining whitelists of allowed directories and blacklists of prohibited directories in the form of path prefixes; (2) Network access rules: defining whitelists of allowed external services and blacklists of prohibited IP ranges in the form of domain names / CIDRs; (3) Process execution rules: restricting the runtime that the Agent can start in the form of process name whitelists and prohibiting high-risk command combinations in the form of regular expression blacklists; (4) Risk-level autonomous rules: when the risk level is lower than the preset threshold, the contract automatically approves and issues tokens; when the risk level is higher than the threshold, triggering the multi-validator consensus process or pushing a simplified approval notification.

[0031] 3. Capability Permit Mechanism. After approval by the blockchain policy virtual machine, the on-chain contract generates a capability token. Its data structure includes at least the token identifier (permit_id), action hash (action_hash), validity period (expires), constraints (constraints), and authorization signature (signature) fields. The capability token has the following security characteristics: (1) Validity: The expires field limits the validity window of the token to prevent replay attacks; (2) Constraints: The constraints field quantifies the execution scope; (3) Unforgeability: The signature uses an asymmetric encryption algorithm and is generated based on the private key of the consortium blockchain verification node; (4) Binding: The action_hash strongly binds the token to the specific behavioral intent.

[0032] 4. Trusted Executor. The Trusted Executor is the only component with direct access to underlying tools and system resources, running in an isolated sandbox environment. Its execution process is as follows: First, token signature verification – confirming that the token was issued by a legitimate consortium blockchain verification node; Second, behavior hash consistency verification – recalculating the hash of the intermediate representation of the behavior intent to be executed and comparing it with the `action_hash` in the token; Third, timeliness verification – verifying whether the current timestamp is within the token's validity window. If any of the three verification steps fails, the Trusted Executor immediately refuses execution and writes a rejection event record to the on-chain ledger. After all three verification steps pass, the Trusted Executor executes the corresponding operation within the range specified by the `constraints` field. The execution environment uses one or a combination of WASM sandbox, Firecracker microvirtual machine, gVisor, Kata Containers, TEE trusted execution environment, or eBPF runtime.

[0033] 5. End-to-End Audit Ledger. This invention records immutable hash digests for the following stages on-chain: user prompt hash (prompt_hash), LLM model identifier and version hash (model_hash), intermediate representation hash of behavioral intent (action_ir_hash), capability token hash (permit_hash), actual tool call parameter hash (tool_call_hash), and execution result and timestamp hash (execution_hash). These hashes are stored in a chained structure, with each subsequent hash's calculation input including the hash of the previous stage, forming an unbreakable chain of trust. Based on this ledger, the system supports three advanced functions: execution replay, liability determination, and compliance reporting.

[0034] 6. Enterprise-level Consortium Blockchain Deployment Architecture. This invention prioritizes the deployment of a consortium blockchain. The consortium blockchain consists of three types of nodes: enterprise nodes (responsible for submitting behavioral intentions and receiving tokens), policy verification nodes (responsible for policy approval and token issuance), and audit nodes (responsible for immutably recording the entire operation ledger). Communication between nodes uses TLS two-way authentication and message signing to ensure integrity, and operation logs are not exposed to the public internet.

[0035] Example 2: The specific embodiments of each technical module of the present invention will now be described in detail with reference to the accompanying drawings.

[0036] I. Overall System Architecture (see...) Figure 1 ) like Figure 1 As shown, the system of the present invention comprises seven functional layers connected sequentially from top to bottom. Only one-way calls are allowed between adjacent layers. Agents cannot directly access resources of lower layers, thus forming a trust transmission chain.

[0037] The first layer is the User Intent Layer, which is responsible for receiving the task objectives expressed by the user in natural language and passing the original text and context information to the LLM planning layer. At the same time, it calculates and records the prompt hash for use in the audit ledger.

[0038] The second layer is the LLM Planner Layer, which uses a large language model to reason about user intent and decompose it into multi-step tasks, generating an execution plan sequence composed of multiple intermediate representations of behavioral intents. The output of this layer is strictly limited to a semantic description format and does not contain any directly executable system commands.

[0039] The third layer is the Action Intent IR Layer, which is one of the core innovations of this invention. Its specific implementation is described in the "Action Intent IR Layer" section below.

[0040] The fourth layer is the Blockchain Policy VM Layer, which is another core innovation of this invention. The specific implementation is described in the "Blockchain Policy VM" section below.

[0041] The fifth layer is the Capability Permit Layer, which is responsible for storing and transmitting tokens after the policy is approved. The specific implementation is detailed in the "Capability Permit Mechanism" section below.

[0042] The sixth layer is the Trusted Executor Layer, which is responsible for token verification and isolated execution. The specific implementation is detailed in the "Trusted Executor" section below.

[0043] The seventh layer is the operating system and tools layer (OS / Cloud / Tools Layer), which provides underlying capabilities such as file system, network, and process management. The trusted executor layer interacts with this layer through a restricted API.

[0044] II. Action Intent Intermediate Representation (see...) Figure 2 ) The behavioral intent intermediate representation is a semantic isolation layer introduced in this invention between LLM output and actual system execution. Unlike directly generating shell commands or API calls, the output of the LLM planning layer is forcibly encoded into the following standardized JSON format: { "action": "filesystem.delete", "target": " / workspace / logs / *.log", "reason": "Regularly clean up expired log files", "scope": "workspace", "risk_level": 2, "estimated_impact": { "files": 32, "size_mb": 180} } The action field adopts the semantic naming convention of "resource type.operation verb", covering resource types such as filesystem (filesystem.*), network (network.*), process (process.*), code (code.*), and database (db.*); the risk_level field has a value range of 1 to 5 and is automatically filled in by LLM based on the operation semantics; the estimated_impact field is used to estimate the quantitative impact of the operation, which is used by the strategy contract to assess whether the operation scale exceeds the limit.

[0045] After the IR calculation is completed, the system performs canonical serialization (Canonical JSON) on the JSON object and calculates the SHA-256 hash to generate the action_hash, which is strongly bound to the subsequent capability token to prevent content tampering attacks during the execution phase.

[0046] The above design draws on the ideas of LLVM IR in the compiler field and the approval concept of Terraform Plan, decoupling "what is executed" from "whether execution is allowed" and providing structured input for policy approval.

[0047] III. Blockchain Policy VM (see...) Figure 3 ) The blockchain strategy virtual machine layer runs on top of consortium blockchain nodes and executes strategy decisions through smart contracts. Its core interface is defined as follows: function approve(ActionIR action) returns (Permit memory) { require(checkFileSystemPolicy(action), "File system policy verification failed"); require(checkNetworkPolicy(action), "Network access policy verification failed"); require(checkProcessPolicy(action), "Process execution policy verification failed"); require(action.risk_level<= maxAutoApproveLevel || hasMultiSigConsensus(action), "Multiple signatures are required for consensus"); return generatePermit(action); } The set of on-chain storage policy rules includes four categories: (1) File system access rules: whitelist of allowed directories (e.g., / workspace / *, / tmp / app / *) and blacklist of prohibited directories (e.g., / etc / *, ~ / .ssh / *, / var / lib / *) are defined in the form of path prefixes. (2) Network access rules: whitelist of allowed external services and blacklist of prohibited IP ranges are defined in the form of domain name / CIDR. (3) Process execution rules: whitelist of processes that the Agent can start is restricted by process name, and blacklist of high-risk command combinations (e.g., curl|bash pipe, sudo privilege escalation) is prohibited by regular expression blacklist. (4) Risk level autonomous rules: when risk_level is lower than the maxAutoApproveLevel threshold (default value is 2), the contract automatically approves and issues tokens; when risk_level is higher than the threshold, the multi-validator consensus process is triggered or a simplified approval notification is pushed.

[0048] The policy rules are updated through on-chain governance. Change proposals must be approved by authorized nodes through voting. Update records are tamper-proof, ensuring the auditability of the policy itself.

[0049] IV. Capability Permit Mechanism (see...) Figure 4 ) After approval by the blockchain strategy virtual machine, the on-chain contract generates a capability token, whose data structure is as follows: { "permit_id": "uuid-v4", "action_hash": "sha256(canonical_action_ir)", "issued_at": 1716550000, "expires": 300, "constraints": { "max_files": 100, "path_prefix": " / workspace", "max_size_mb": 500}, "issuer_node": "validator-node-01", "signature": "ECDSA(permit_payload, issuer_private_key)" } The capability token has the following security features: (1) Timeliness: The expirys field limits the validity window of the token (300 seconds by default) to prevent replay attacks; (2) Constraints: The constraints field quantifies the execution range, and operations that exceed the constraints are rejected even if the token is valid; (3) Unforgeability: The signature uses the ECDSA algorithm, is generated based on the private key of the consortium blockchain verification node, and is verified by the corresponding public key stored on the chain; (4) Binding: action_hash strongly binds the token to the specific behavioral intent to prevent the token from being used for operations other than authorized.

[0050] V. Trusted Executor (see...) Figure 4 ) The trusted executor is the only component with direct access to underlying tools and system resources, and it runs in an isolated sandbox environment. Its execution flow is as follows: The first step is token signature verification: perform ECDSA signature verification on the capability token to confirm that the token was issued by a legitimate consortium blockchain verification node.

[0051] The second step is to verify the consistency of the behavior hash: recalculate the SHA-256 hash of the intermediate representation of the behavior intent to be executed, compare it with the action_hash in the token, and confirm that the execution content is consistent with the authorized content.

[0052] The third step is timeliness verification: verify whether the current timestamp is within the range of the token's issued_at to issued_at+expires.

[0053] If any of the three verification steps fails, the trusted executor immediately refuses to execute and writes a rejection event record to the on-chain ledger, while simultaneously triggering an alarm notification. If all three verification steps pass, the trusted executor executes the corresponding operation within the scope specified in the constraints field. The execution environment uses one or a combination of WASM sandbox, Firecracker microvirtual machine, gVisor, KataContainers, TEE trusted execution environment, or eBPF runtime. After execution, the execution_hash is anchored to the on-chain audit ledger.

[0054] VI. End-to-end audit ledger (see...) Figure 5 ) This invention records immutable hash digests for the following stages on the blockchain: prompt_hash (user's original prompt word), model_hash (LLM model identifier and version), action_ir_hash (intermediate representation of behavioral intent), permit_hash (capability token content), tool_call_hash (actual tool call parameters), and execution_hash (a combined hash of execution result, timestamp, and execution environment digest). These six types of hashes are stored in a chained structure, with each subsequent hash's input containing the hash of the previous stage, forming an unbreakable chain of trust. Based on this ledger, the system supports three advanced functions: execution replay (accurately reproducing historical operations for incident analysis), liability determination (reverse tracing to accurately locate the responsible link), and compliance reporting (automatically generating audit reports that meet regulatory requirements).

[0055] VII. Enterprise-level Consortium Blockchain Deployment Architecture (see...) Figure 6 ) Considering enterprise data security compliance requirements, this invention prioritizes the deployment of a consortium blockchain. The consortium blockchain consists of three types of nodes: enterprise nodes (responsible for submitting behavioral intents and receiving tokens), policy verification nodes (responsible for policy approval and token issuance), and audit nodes (responsible for immutably recording the entire operation ledger). Enterprise nodes receive behavioral intents submitted by the LLM (Local Management Provider), complete identity binding, timestamp encapsulation, and digital signature, and then submit them to the consortium blockchain. Policy verification nodes verify behavioral intents based on security policies, permission models, and compliance rules, and reach consensus through multi-signature or threshold signature mechanisms. If the conditions are met, an execution token is issued; otherwise, a rejection credential is generated. Policy verification nodes simultaneously submit records to audit nodes during token approval, issuance, update, or revocation. Audit nodes, acting as an independent evidence storage layer, perform append-only storage of behavioral intent summaries, approval results, signature information, token hashes, and execution results, forming an immutable audit ledger. Inter-node communication uses TLS 1.3 mutual authentication and message ECDSA signatures, and operation logs are not exposed to the public internet. This architecture supports integration with existing enterprise LDAP / RBAC permission systems, SIEM security information and event management systems, and CI / CD pipelines.

[0056] VIII. Methods and Procedures Based on the above system, the present invention also provides a trusted execution method for AI Agent behavior based on on-chain policy consensus, comprising the following steps: S1: The LLM planning layer receives user intent, performs reasoning and planning, and encodes the operation to be executed into an intermediate representation of behavioral intent. The intermediate representation does not contain directly executable system commands, but only contains an operational semantic description.

[0057] S2: The behavioral intent intermediate representation layer calculates the behavioral hash of the intermediate representation and submits it along with the operation context to the blockchain policy virtual machine layer. Before this, the behavioral intent intermediate representation layer can pre-evaluate the estimated impact field of the behavioral intent. If the pre-evaluation result exceeds the current authorization range, it returns a range over-limit signal to the LLM planning layer before submitting the policy for approval, and the LLM planning layer splits or downgrades the operation plan.

[0058] S3: The blockchain strategy virtual machine layer performs compliance verification on the intermediate representation based on the on-chain strategy contract. For actions with a risk level below a preset security threshold, capability tokens are automatically generated without user intervention; for actions with a risk level above the preset security threshold, a multi-validator consensus process is triggered or a simplified approval notification is pushed to the authorized user. If the verification passes, a capability token bound to the behavior hash is generated and signed; if the verification fails, the action is rejected and the rejection event is recorded on the blockchain.

[0059] S4: The trusted executor layer receives the capability token, verifies the token signature, behavior hash consistency, and validity period in sequence, and executes the corresponding operation within the constraints after all verifications are passed.

[0060] S5: The trusted executor layer writes the execution result, execution timestamp, and execution environment summary into the on-chain audit ledger.

[0061] S6: The system associates and stores the operation records in the audit ledger with the intermediate representation of the original behavioral intent, supporting post-event auditing, execution replay, and responsibility determination.

Claims

1. A trusted execution system for AI Agent behavior based on on-chain policy consensus, characterized in that... include: The user intent layer is used to receive natural language commands from users and pass them to the LLM planning layer. The LLM planning layer is used to reason about user intent and decompose tasks to generate a structured intermediate representation of behavioral intent. The behavioral intent intermediate representation layer is used to describe the agent's operational intent in a standardized format. The agent must not bypass this layer to directly call the underlying tools. The blockchain strategy virtual machine layer is used to make automated policy decisions based on the intermediate representation of behavioral intent according to the policy contracts stored on the chain. When the behavior is compliant, it generates capability tokens, and when the behavior is non-compliant, it rejects and records the violation. Capability token layer, used to store and transfer capability tokens generated through blockchain policy approval; The trusted executor layer, deployed in an isolated sandbox environment, is used to receive capability tokens. It verifies the legality and integrity of the tokens before executing the corresponding system operations and writes the execution logs to an immutable on-chain ledger. The operating system and tools layer provides underlying system calls, cloud service interfaces, and tool APIs for the trusted executor layer. The layers are sequentially invoked through a one-way trust chain. The behavior hash in the intermediate representation of the behavior intent generated by the Agent is strongly bound to the behavior hash in the capability token to prevent content tampering during the execution phase.

2. The AI ​​Agent behavior trusted execution system based on on-chain policy consensus according to claim 1, characterized in that: The intermediate representation of the behavioral intent adopts a standardized JSON format, which includes at least the fields of behavior type (action), operation target (target), operation reason (reason), scope (scope), risk level (risk_level), and estimated impact (estimated_impact); the capability token includes at least the fields of token identifier (permit_id), behavior hash (action_hash), validity period (expires), constraints (constraints), and authorization signature (signature).

3. The AI ​​Agent behavior trusted execution system based on on-chain policy consensus as described in claim 1, characterized in that... The blockchain policy virtual machine layer includes the following policy rule set: file system access rules, which define a whitelist of paths that the Agent is allowed to access and a blacklist of paths that the Agent is prohibited from accessing; network access rules, which define a whitelist of external domain names that the Agent is allowed to access and a blacklist of IP ranges that the Agent is prohibited from accessing. Process execution rules define the types of processes that the Agent is allowed to start and a list of high-risk commands that are prohibited from being executed; The risk-based autonomous rules automatically approve behaviors with a risk level below a preset threshold, while triggering multi-signature consensus or manual review processes for high-risk behaviors.

4. The AI ​​Agent behavior trusted execution system based on on-chain policy consensus according to claim 1, characterized in that: The capability token is generated by the blockchain policy virtual machine layer through on-chain smart contract functions, and the token is ensured to be unforgeable through asymmetric cryptographic signature. Before execution, the trusted executor layer must verify the signature, behavior hash consistency, and token validity period. If any of the three verifications fails, execution will be refused and an alarm will be recorded.

5. The AI ​​Agent behavior trusted execution system based on on-chain policy consensus according to claim 1, characterized in that... The blockchain policy virtual machine layer supports a multi-validator consensus approval mechanism, including: There are at least two independent validator nodes, each of which undertakes different policy responsibilities, including security model verification, organizational policy verification, cost compliance verification, and privacy protection verification. The consensus protocol requires that high-risk behavioral intentions must obtain the joint signatures of a preset number of validator nodes in order to generate a valid capability token; The dynamic weighting mechanism dynamically adjusts the minimum number of validators participating in the consensus based on the risk level field of the behavioral intent.

6. The AI ​​Agent behavior trusted execution system based on on-chain policy consensus according to claim 1, characterized in that: It also includes a fully auditable component that records all or a combination of the following hash digests on the chain: user prompt word hash, LLM model identifier hash, behavioral intent intermediate representation hash, capability token hash, tool call hash, and execution result hash, to achieve non-repudiation and end-to-end accountability of agent operations.

7. The AI ​​Agent Behavior Trusted Execution System Based on On-Chain Policy Consensus as described in claim 1, characterized in that: The system is deployed in a consortium blockchain architecture, which consists of enterprise nodes, policy verification nodes, and audit nodes; the enterprise nodes are responsible for submitting behavioral intentions and receiving capability tokens. The policy verification node is responsible for performing compliance checks and issuing tokens; The audit node is responsible for the immutable recording of the entire operation ledger; Communication between nodes of all types is guaranteed to be intact through TLS two-way authentication and message signing, and the operation logs on the consortium blockchain are not exposed to the public network.

8. A trusted execution method for AI Agent behavior based on on-chain policy consensus, characterized in that... Includes the following steps: S1: The LLM planning layer receives user intent, performs reasoning and planning, and encodes the operation to be executed into an intermediate representation of behavioral intent, which only contains the semantic description of the operation. S2: The intermediate representation layer of behavioral intent calculates the behavioral hash of the intermediate representation and submits it along with the operation context to the blockchain policy virtual machine layer; S3: The blockchain strategy virtual machine layer performs compliance verification on the intermediate representation based on the on-chain strategy contract. If the verification passes, a capability token with a binding behavior hash is generated and signed. If the verification fails, the application is rejected and the rejection event is recorded on the blockchain for evidence. S4: The trusted executor layer receives the capability token, verifies the token signature, behavior hash consistency and validity period in sequence, and performs the corresponding operation within the constraint conditions after all verifications are passed. S5: The trusted executor layer writes the execution result, execution timestamp, and execution environment summary into the on-chain audit ledger; S6: The system associates and stores the operation records in the audit ledger with the intermediate representation of the original behavioral intent, supporting post-event auditing, execution replay, and responsibility determination.

9. The AI ​​Agent behavior trustworthy execution method based on on-chain policy consensus according to claim 8, characterized in that... In step S3: The blockchain strategy virtual machine layer classifies the risk level of behavior. For behavior intentions with a risk level lower than the preset security threshold, capability tokens are automatically generated without user intervention. For behavior intentions with a risk level higher than the preset security threshold, a multi-validator consensus process is triggered or a simplified approval notification is pushed to the authorized user. The simplified approval notification includes an operation summary, estimated impact scope and compliance status, but does not include the original command line content.

10. The AI ​​Agent behavior trustworthy execution method based on on-chain policy consensus according to claim 8, characterized in that: Before step S2, the intermediate representation layer of behavioral intent performs a pre-evaluation of the estimated impact field of behavioral intent. If the pre-evaluation result exceeds the current authorized range, a range over-limit signal is returned to the LLM planning layer before submitting the strategy for approval. The LLM planning layer then splits or downgrades the operation plan.

Images