A human real intention verification protocol and agent right dynamic boundary control method and system for automated execution subjects

Abstract

The application discloses a human real intention verification protocol and proxy right dynamic boundary control method and system for an automated execution subject. The first feature sequence of the action semantics, the action object, the expected consequence and the context of a high-risk action request is acquired. When the risk trigger condition is hit, the second feature sequence of the human authorized intention, the man-machine state, the embodied interaction state and the executable consequence is acquired. The two sequences are aligned in time, link stage, context and authorized link, and the causal consistency with the human real intention is calculated. According to this, the ruling token or the proxy right ruling result is generated, and the proxy right, the execution or the sovereignty control boundary is dynamically adjusted. Three-level risk triggers and non-intrusive data acquisition are supported, and low-disturbance and interpretable human real intention verification and proxy right dynamic governance can be realized without reconstructing the system.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence security, computer access control, human-computer interaction security, automated process governance, tool invocation governance, embodied intelligence security, Internet of Things control security, vehicle network security, and privacy computing technology. In particular, it relates to a method and system for dynamically adjusting the boundaries of agency, execution, or sovereign control when an automated execution subject initiates tool invocation, application programming interface invocation, external system operation, fund transaction, data outflow, physical device control, robot action, or vehicle control, by performing runtime causal verification between the action request and the true human intent, and outputting an adjudication token, agency adjudication result, or audit summary object accordingly. Background Technology

[0002] With the development of large language models, AI agents, RPA, workflow engines, automated scripts, embodied intelligence, vehicle agents, IoT agents, and autonomous driving technologies, software systems and smart devices have gradually evolved from simply generating information or passively responding to automated execution entities capable of planning tasks, calling tools, and executing actions. AI agents are one typical implementation form, capable of automatically processing emails, managing schedules, calling enterprise systems, performing database queries, submitting code, initiating payments, controlling IoT devices, and even interacting with embodied robots or autonomous driving systems after user authorization. RPA, enterprise workflows, cloud-based maintenance scripts, embodied robots, vehicle control systems, and device control agents also face the same risks associated with agent-driven actions.

[0003] Traditional access control typically employs role-based access control, attribute-based access control, access tokens, permission whitelists, manual approval, tool call logs, or post-event auditing processes. While these solutions can determine whether a subject possesses a specific permission, they struggle to ascertain whether a particular proxy action still aligns with the original, current, informed, perceptible, and responsible intent of a human user, particularly in the following situations: 1. Automated execution entities may autonomously plan based on probabilistic reasoning, rule arrangement, or historical tasks, and may take actions that substantially violate the user's will within the scope of legal authority.

[0004] 2. Multi-agent collaboration, RPA orchestration, chained tool calls, or nested workflows can lead to user intent being simplified, distorted, lost, or amplified during transmission.

[0005] 3. In some scenarios, human-in-the-loop confirmation can easily degenerate into a formalized click, which cannot prove that the user understands the consequences of the action, nor can it prove that the action execution chain remains consistent with the authorization intent.

[0006] 4. Hint injection, indirect hint injection, memory poisoning, rule injection, upstream task pollution, or external dependency pollution may induce the automated execution entity to call tools without authorization.

[0007] 5. The human authorization subject and the automated execution subject, as well as the real execution terminal, are often not on the same device, the same network, or the same physical environment. Traditional same-end confirmation is difficult to cover cloud agents, remote robots, vehicle agents, and multi-end approval scenarios.

[0008] 6. Human authorization may occur a long time before the action is executed, such as automatic renewal, scheduled tasks, delayed execution after approval, or long-term pre-authorization. Traditional solutions that detect whether the user is present at the moment the action occurs have difficulty distinguishing between physical silence caused by the user being asleep, offline, or unable to interact and physical silence caused by remote control, automated scripts, or non-autonomous operation.

[0009] 7. Post-event audits cannot prevent irreversible consequences before an action is performed, such as fund transfers, data outsourcing, production system configuration modifications, physical equipment actions, or vehicle control actions.

[0010] Several security solutions have emerged in the existing technology, targeting agents, automated tool invocations, transaction authorization, trusted execution, or communication authentication. These solutions can determine the semantic alignment between agent behavior and textual task objectives by auditing the agent's inference chain, tool invocation records, and user task goals. They can also perform tiered detection of agent tool invocations using lightweight risk models or large language models to identify unauthorized invocations or abnormal tool usage. Furthermore, they can verify whether authorization records, transaction parameters, data transmission, communication services, or business requests conform to preset rules through consistency checks of intent credentials, transaction credentials, payment credentials, consumption intent tokens, trusted execution environments, rule validation, data field authorization, and communication intent auxiliary information or service information.

[0011] The aforementioned existing solutions can provide access control, semantic alignment, credential tamper-proofing, transaction parameter matching, or rule consistency verification in their respective scenarios. However, these solutions typically focus on judgments at the level of digital semantics, identity permissions, transaction parameters, or communication protocols, lacking mechanisms for cross-layer causal association between the digital context of the automated execution subject's actions and the human-machine state, device presence state, or physical or embodied interaction state during human runtime. Furthermore, they lack cross-terminal causal consistency judgments between action semantics, authorization anchors, execution state, and action consequences in scenarios involving delayed execution after pre-authorization, asynchronous authorization anchoring when the user is in a silent or non-interactive state, and multi-terminal collaborative scenarios where the human interaction terminal and the Agent, robot, vehicle agent, or cloud execution environment are not on the same device or in the same physical environment. In addition, the outputs of existing solutions are mostly single alarms, interceptions, authorization approvals, transaction processing, or audit reports, making it difficult to continuously and dynamically govern the scope of subsequent actions, autonomous execution level, tool tokens, or sovereign control boundaries of the automated execution subject.

[0012] Therefore, there is a need for a technical solution that, without significantly refactoring existing Agent, RPA, workflow, device control, or vehicle control architectures, can verify the true human intent of high-risk actions of automated executors, dynamically limit permissions, exercise sovereignty control, and leave audit trails, through SDKs, tool gateways, action verification layers, system services, edge control nodes, robot sovereignty switches, or vehicle control nodes. Summary of the Invention

[0013] (a) Technical problems to be solved The technical problem this invention aims to solve is: when an automated execution entity initiates a high-risk action request, it determines, through a human true intent verification protocol, whether the request still falls within the agency boundary, execution boundary, or sovereign control boundary jointly defined by human authorized intent, runtime human-machine state, device presence state, physical or embodied interaction state, business or environmental context, and acceptable action consequences. It also characterizes whether the request corresponds to a real, current, informed, perceptible, and responsible human intent with a calculable causal consistency result. Furthermore, when issues such as permission drift, target mismatch, prompt injection, rule pollution, pre-authorization anchor failure, cross-terminal causal inconsistency, or consequence exceeding limits occur, it dynamically shrinks, downgrades, freezes, revokes agency authority, or tightens sovereign control boundaries for the automated execution entity.

[0014] (II) Technical Solution To address the aforementioned problems, this invention proposes a protocol for verifying the true human intent of automated execution subjects and a method for dynamic boundary control of proxy authority. See also... Figure 2 The method includes the following steps.

[0015] 1. At the action request entry point or execution pre-control point in the high-risk action execution chain of the automated execution entity, receive, observe, suspend, or intercept high-risk action requests, form an action declaration object representing the high-risk action request, and obtain a first feature sequence. The first feature sequence is used to characterize the action semantics, target object, expected consequences, and execution context of the high-risk action request, and may include target tool, target interface, action type, action parameter summary, resource scope, call chain context, parent or child execution entity identifier, task source, external input credibility, action risk level, rollbackability, and expected impact of the action.

[0016] 2. In response to the first feature sequence hitting a preset risk trigger condition, an intent verification request object is generated, and a second feature sequence associated with the high-risk action request is obtained. The second feature sequence characterizes at least one of the following: human authorization intent, runtime human-machine state, device presence state, physical or embodied interaction state, business or environmental context, and action executable consequences. It may include an authorization intent anchor point, intent impulse response, user runtime interaction state, device presence state, touch state, button state, gesture state, environmental awareness state, physical operation missing state, foreground focus, multi-terminal confirmation state, cross-terminal confirmation state, authorization link integrity, pre-authorization anchor point validity, business context, environmental context, sandbox pre-execution result, and action consequence boundary. The intent impulse can be used as an optional enhanced confirmation method after risk triggering, but is not a necessary limitation for this invention to determine the true human intent or form the second feature sequence.

[0017] 3. Align the first feature sequence with the second feature sequence in terms of time, action chain stage, context, and authorization chain. Calculate the causal consistency between high-risk action requests and true human intent using a causal verification model. This causal consistency can be represented as a score, grade, Boolean conclusion, break index, cause code, explanation label, or structured evidence summary.

[0018] 4. Generate at least one of the following based on causal consistency: an adjudication token, a proxy adjudication result, or an audit summary object. The adjudication token, proxy adjudication result, or audit summary object is used to dynamically adjust the proxy boundaries, execution boundaries, or sovereign control boundaries of the automated execution entity for this high-risk action request or subsequent action requests, or for pre-event control, in-event review, or post-event retrospective purposes. It may include granting permission, limiting authority, delaying, parameter trimming, re-verification, manual review, sandbox pre-execution, session isolation, task chain freezing, token revocation, action blocking, rollback, tightening of sovereign switch, cross-executing entity chain demotion, enhanced audit, or constraints on the scope of subsequent actions.

[0019] The above four steps constitute the basic technical flow of this invention. The action declaration object, intent verification request object, embodied response object, adjudication token object, and audit summary object can be implemented as structured objects or output objects in the above process; audit traces are a form of implementation of delegated governance output, which can be combined with adjudication tokens or delegated adjudication results for output, or can be output separately as audit summary objects.

[0020] See Figure 1 This invention also proposes a human intent verification protocol and a dynamic boundary control system for agency authority for automated execution entities. The system includes an action data analysis module, an intent and concrete posterior verification module, a causal verification module, and an adjudication and auditing module. The action data analysis module is used to form an action declaration object and obtain a first feature sequence at the action request entry point or execution pre-control point; the intent and concrete posterior verification module is used to generate an intent verification request object and obtain a second feature sequence in response to the first feature sequence hitting a preset risk trigger condition; the causal verification module is used to align the first and second feature sequences in terms of time, action link stage, context, and authorization link, and calculate causal consistency; the adjudication and auditing module is used to generate at least one of an adjudication token, agency authority adjudication result, or audit summary object to dynamically adjust the agency authority boundary, execution boundary, or sovereign control boundary.

[0021] This invention also provides a causal verification logic for determining whether high-risk actions of automated executors originate from genuine human intent. For high-risk actions initiated by automated executors that have external consequences, changes in resource status, economic consequences, data leakage, or physical world impacts, causal alignment can be performed by combining action semantics, authorization anchors, runtime human-machine or embodied states, and action consequences. This allows the representation of genuine, current, informed, perceptible, and responsible human intent as a computable causal consistency result, thereby identifying abnormal situations such as unauthorized automation, input contamination, broken proxy links, or out-of-bounds consequences.

[0022] The true human intent in this invention is not used to directly measure user psychological activity, nor is it a necessary condition for making legal liability judgments. Technically, it is equivalent to a quantifiable indicator of the matching between the action semantics of high-risk action requests from automated executors, preset authorization intent anchor points, and runtime human-machine or embodied states across four dimensions: time, action chain stage, context, and authorization chain. This indicator can be represented by scores, levels, fracture indices, reason codes, status labels, or structured evidence summaries, and is used to drive the generation of adjudication tokens, proxy adjudication results, or audit summary objects.

[0023] See Figure 7In one embodiment, the present invention supports a synchronous embodied verification path: before, during, or within a short window of a high-risk action, the real-time embodied interaction state, device presence state, touch state, button state, posture state, multi-terminal confirmation state, or physical operation absence state of the human authorized subject are collected and aligned with the action semantics, execution context, and consequence boundaries in terms of time, stage, and authorization link.

[0024] In another implementation, the present invention supports asynchronous authorization anchoring paths: when human authorization occurs before the action is executed, and the user may be in a silent, offline, sleeping or non-interactive state when the action is executed, the system does not make an abnormal conclusion based solely on the lack of embodied interaction, but verifies whether the action falls within the authorization target, authorization scope, authorization time period, authorization risk level, revocable state, consequence boundary and authorization link integrity defined by the pre-authorization anchor.

[0025] In another implementation, the present invention supports a multi-terminal collaborative verification path: when the human authorizing entity and the automated execution entity or the real execution end are not in the same device, the same network or the same physical environment, the authorization intent, embodied interaction or confirmation status are collected at the human interaction end, and the action declaration, execution context, device status, environment status and action consequences are collected at the execution end or execution environment, and the cross-terminal causal consistency calculation is used to determine whether the two match each other in terms of time, authorization, status and consequences.

[0026] For high-risk action requests initiated by automated executors, when verifying whether they originate from genuine human intent rather than automated overreach, input contamination, or proxy link breakage, one or a combination of the following verification conditions can be adopted in the corresponding scenario: causally aligning the action semantics with the runtime human embodied or authorized state; verifying that the action is within the bounded range of the authorization anchor point, authorization link, and consequence boundary; or establishing cross-terminal causal consistency between the human interaction terminal and the execution terminal. Without the above verification conditions matching the specific scenario, it is difficult to logically exclude permission drift, non-autonomous operation, proxy link breakage, and consequence overreach. The synchronous embodied verification path, asynchronous authorization anchoring path, and multi-terminal collaborative verification path provided by this invention are used to satisfy the above verification conditions. Methods that only perform digital-side rule matching, identity authentication, semantic auditing, or post-event logging, because they do not incorporate action semantics, authorization anchor points, runtime human-machine or embodied state, and action consequences into a causal alignment closed loop, are insufficient to fully determine whether high-risk action requests still originate from genuine human intent.

[0027] (III) Beneficial Effects Compared with the prior art, the present invention has at least the following effects.

[0028] 1. Upgrade the governance of automated execution entities from static permission allocation to runtime verification of real human intent, which can identify permission drift, target mismatch, authorization chain breakage and consequence overstepping.

[0029] 2. By forming a closed loop through action data analysis, intent and concrete hindrance, cross-layer causal alignment, and agency governance output, high-risk actions can be avoided by relying solely on single permissions, single identity authentication, formal approval, or post-event logs.

[0030] 3. Supports three types of paths: synchronous embodied verification, asynchronous authorization anchoring, and multi-terminal collaborative verification, covering scenarios such as mobile phone confirmation, cloud agent, long-term pre-authorization, remote robot, vehicle agent, and multi-terminal approval.

[0031] 4. Enable SDKs, tool gateways, API gateways, system services, edge nodes, device controllers, robot controllers, or vehicle control nodes to perform release, restriction, freeze, revocation, block, rollback, or audit enhancement through structured outputs of adjudication tokens, proxy adjudication results, or audit summary objects.

[0032] 5. Implemented via tool gateway or SDK, it does not require a complete reconstruction of the Agent, RPA, workflow, robot or vehicle control platform, and has a clear engineering implementation path; among them, SDK is one of the implementation paths that is easy to integrate, and does not limit other implementation forms of the present invention.

[0033] 6. Supports unified governance of various high-risk actions, including those related to funds, privacy, cloud resources, databases, code repositories, IoT, embodied devices, and vehicle control.

[0034] 7. It can combine injection detection with sandbox pre-execution, rollback and structured audit to form a closed loop of prevention, control and review.

[0035] 8. By incorporating action semantics, authorization intent anchor points, runtime human-machine or embodied states, action link stages, and action consequence boundaries into the same causal verification model, it can identify abnormal scenarios where action parameters are legal and semantics are reasonable, but the human authorization state, embodied interaction state, or runtime context is broken, and output interpretable causal consistency conclusions.

[0036] 9. Supports asynchronous authorization anchoring paths and multi-terminal collaborative verification paths after pre-authorization, and expands the output types from single authorization approval, single transaction processing, or audit report to adjudication tokens, agency adjudication results, and audit summary objects that can be used to dynamically adjust subsequent delegation boundaries, execution boundaries, and sovereign control boundaries.

[0037] 10. Incorporate prompt injection, rule pollution, task chain pollution, and untrusted external dependencies as input credibility factors into the causal consistency calculation. This allows causal consistency to be reduced and proxy decisions to be output, such as isolation, demotion, or blocking of execution, even if a single action parameter is within the legal range, when the upstream input or execution rules of the automated execution subject have been polluted.

[0038] 11. The four-step backbone and three-path system of this invention do not depend on specific large language model types, agent frameworks, sensor models, software platforms, operating systems, or hardware architectures. In scenarios where an automated execution entity initiates a high-risk action request and needs to verify whether it is driven by genuine human intent, unified causal verification and agency boundary control can be achieved by accessing at least some of the objects among the action declaration object, intent verification request object, embodied response object, adjudication token object, and audit digest object, without needing to share the same model implementation, software form, or hardware environment. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the human true intent verification protocol system for automated execution subjects according to the present invention, showing the relationship between the action digital judgment module, the intent and concrete posterior verification module, the causal verification module, and the adjudication and auditing module. Figure 2 This is a schematic diagram of the overall process of the method of the present invention, showing four steps: action data analysis, intent and concrete posterior after risk triggering, cross-layer causal alignment, and agency governance output; Figure 3 It is a schematic diagram of causal verification between the action declaration object, the authorization intent anchor point, the embodied response object, and the runtime state; Figure 4 This is a deployment diagram based on SDK, tool gateway, or action verification layer; Figure 5 This is a schematic diagram of the dynamic boundary state machine for the adjudication token and delegation authority; Figure 6 This is a diagram illustrating the injection isolation, sandbox pre-execution, and proxy adjudication. Figure 7 This is a diagram illustrating three types of paths: synchronous embodied verification, asynchronous authorization anchoring, and multi-terminal collaborative verification. Detailed Implementation

[0040] The specific embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the following embodiments are used to illustrate the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention. Those skilled in the art can combine, replace, or omit the modules, objects, fields, and deployment locations in the following embodiments without departing from the core concept of the present invention.

[0041] (I) Explanation of relevant terms To facilitate understanding of the specific embodiments of the present invention, the relevant terms used in the present invention are explained below. The following description is used to explain the technical solutions of the present invention and should not be construed as limiting the present invention to a specific business scenario, software framework, hardware form or data format.

[0042] Automated execution entity This refers to software entities, hardware control entities, or combined software and hardware entities that can automatically initiate tool calls, interface calls, system operations, equipment control, vehicle control, or other actions with external effects based on goals, context, model reasoning, rule orchestration, or preset processes. These include AI Agents, RPA robots, automation scripts, workflow engines, multi-Agent collaboration systems, enterprise process robots, cloud operation and maintenance agents, financial transaction agents, embodied intelligent control entities, IoT control agents, vehicle agents, and autonomous driving control entities, etc.

[0043] Human Intent Verification Protocol This refers to a set of interaction rules, interface semantics, or object structures used to express action declarations, intent anchor calls, embodied response collection, causal consistency determination, adjudication output, and audit trails before an automated execution entity performs high-risk actions. The protocol is not limited to a specific network message format.

[0044] The protocol can be implemented through at least two of the following object types: action declaration object, intent verification request object, embodied response object, adjudication token object, and audit digest object. Each object carries a structured representation of a high-risk action request, a call request for human authorized intent, the collection and encapsulation of physical or embodied interaction states, adjudication output driven by causal consistency, and audit trail functions.

[0045] The action declaration object, intent verification request object, embodied response object, adjudication token object, and audit digest object in this invention are not limited to specific names, message formats, number of fields, storage locations, or transmission methods; as long as they can respectively carry the structured expression of high-risk action requests, authorization intent or embodied state invocation, physical or embodied interaction state encapsulation, causal consistency-driven governance output, or audit digest function, they can be regarded as equivalent implementation forms of the corresponding objects.

[0046] In one implementation, the aforementioned objects can be carried using machine-resolvable data structures, such as JSON objects, XML objects, Protocol Buffer messages, key-value tables, database records, message queue payloads, JWT payloads, API request bodies, API response bodies, policy objects, signature digests, or cryptographic credentials. The machine-resolvable data structure may include at least one general field selected from object type, object version, object identifier, timestamp, initiating entity identifier, target object identifier, field digest, integrity verification field, signature field, or associated audit index. Each object may also carry action semantic fields, authorization anchor fields, embodied response fields, causal consistency fields, adjudication boundary fields, or audit trail fields according to its function. The aforementioned field names, encoding formats, field order, and number of fields are merely possible implementations and do not constitute a limitation on the scope of protection of this invention.

[0047] High-risk action request This refers to an action request initiated by an automated execution entity that has external effects, rights and obligations effects, resource status change effects, economic consequences, data outflow consequences, physical world impact effects, or irreversible consequences. This includes tool calls, API calls, payments, transfers, data outflow, configuration modifications, code execution, message sending, physical device control, robot actions, or vehicle control.

[0048] Action request entry point or execution pre-control point This refers to the logical location that can receive, observe, intercept, suspend, rewrite, or adjudicate action requests before high-risk actions affect the real system, external objects, user rights, or physical environment. This logical location can be implemented by software frameworks, interface gateways, plug-in runtime environments, workflow nodes, system services, edge control nodes, device control interfaces, robot sovereignty switches, or vehicle control nodes, but is not limited to the specific forms mentioned above.

[0049] First feature sequence This refers to the set of features extracted from high-risk action requests and their execution chain, used to characterize the semantics of the action, its target, execution context, and expected consequences. The first feature sequence is used to characterize the content, target, triggering source, and expected consequences of the action to be performed by the automated execution entity. It may include the target tool or target interface, resource identifier, action type, parameter summary, data sensitivity, resource scope, parent execution entity, child execution entity, task source, upstream input, historical action sequence, expected financial impact, expected data impact, expected permission impact, or expected physical impact.

[0050] Second characteristic sequence This refers to the set of features associated with a high-risk action request, characterizing the human authorization intent, runtime human-machine state, device presence, physical or embodied interaction state, business or environmental context, and the executable consequences of the action. The second feature sequence characterizes the correspondence between the action and the boundaries of the human authorization intent, runtime state, and action consequences within the current time window. The second feature sequence can originate from the same device, or from the human interaction endpoint, execution endpoint, gateway endpoint, device endpoint, or business system endpoint. It may include authorization intent anchor points, recent user confirmation events, intent impulse responses, user runtime interaction states, device presence states, physical or embodied interaction states, touch states, button states, gesture states, physical operation missing states, terminal foreground focus, multi-terminal confirmation states, cross-terminal confirmation states, authorization link integrity, pre-authorization anchor point validity, business context, environmental state, authorization history, external input credibility, and the rollbackability of sandbox pre-execution results or action consequences.

[0051] Preset risk triggering conditions This refers to the rules, models, or policy conditions used to determine whether high-risk action requests need to enter the human intent verification process. These conditions include high-impact actions, ambiguous authorization boundaries, permission drift, abnormal execution contexts, untrusted inputs, irreversible action consequences, or security envelope overflows. Preset risk trigger conditions can be jointly determined by risk level, action consequences, authorization boundaries, input credibility, execution time period, contextual mutations, task chain anomalies, or security envelopes, and can be provided by local systems, cloud platforms, SDKs, enterprise policy systems, or manual configuration.

[0052] In one implementation, the preset risk triggering conditions can employ a tiered triggering mechanism. The system can select at least one verification strength from the following based on the action's risk level, rollback capability, completeness of the authorization intent anchor, input credibility, execution time period, action consequence boundary, and historical causal consistency: automatic release, background audit, asynchronous authorization anchoring, lightweight confirmation, synchronous embodied verification, manual review, sandbox pre-execution, restricted execution, or blocked execution. For low-risk and rollbackable actions, automatic release or background audit can be executed; for medium-risk actions with ambiguous authorization boundaries or insufficient external input credibility, asynchronous authorization anchoring, lightweight confirmation, or sandbox pre-execution can be executed; for high-risk actions that are non-rollbackable, have consequences exceeding limits, or have abnormal embodied states, synchronous embodied verification, manual review, restricted execution, or blocked execution can be executed. Thus, this invention can dynamically select the verification strength according to the action's risk and consequence boundaries without requiring real-time manual confirmation for every action.

[0053] Authorization Intent Anchor This refers to structured information used to characterize the true boundaries of authorization by a user or responsible entity, including authorization objectives, authorization resources, authorization time windows, authorization action types, authorization risk levels, authorization revocation status, approval chains, responsible entities, and consequence boundaries. The authorization intent anchor can be pre-authorization, real-time authorization, long-term authorization, temporary authorization, tiered authorization, approval chain authorization, or revocable authorization.

[0054] Intent pulse This refers to a lightweight, short-lived, context-bound confirmation interaction initiated to a human authorized entity after a risk is triggered, used to form a embodied response or confirmation status associated with the current high-risk action request. Intent impulses are an optional enhancement method and are not a necessary limitation of this invention.

[0055] Action Link Phase Alignment This refers to matching the stages of automated execution—including action requests, tool calls, parameter generation, external system calls, execution confirmation, result feedback, and consequence feedback—with human authorization intent, user interaction timeline, embodied state changes, and confirmation actions. It does not require access to all internal inference tokens, model parameters, or platform-private logs.

[0056] Causal consistency This refers to the quantitative or discrete determination result of whether there is an explainable causal relationship between high-risk action requests and human authorization intent, runtime human-machine state, device presence status, business or environmental context, action executable consequences, action link stages and authorization links.

[0057] In one implementation, causal consistency can be calculated through two methods: forward consistency and reverse breakage. Forward consistency includes consistency between the action semantics and the authorized intent anchor, the target object and resource scope not exceeding limits, reasonable coupling between the action chain progression and the user interaction timeline or authorization chain, and the action consequence not exceeding the safety envelope. Reverse breakage includes target mismatch, scope exceeding limits, permission drift, authorization chain breakage, context pollution, hint injection, rule pollution, task chain pollution, untrusted external dependencies, scripted responses, invalid pre-authorization anchors, mismatch between authorization time periods or revocation states, cross-platform causal inconsistency, and consequence exceeding limits.

[0058] Cross-terminal causal inconsistency This refers to a situation where a causal relationship cannot be established between the device where a human authorization, embodied interaction, or confirmation occurs, and the system, cloud execution environment, robot, vehicle system, IoT device, or business execution environment where the automated execution entity resides, in terms of spatiotemporal consistency, authorization consistency, state consistency, or consequence consistency. For example, a human confirmation on device A may not align with the object, parameters, time period, environmental state, or consequence boundaries of the action performed on device B, or the action on the execution end may be triggered by contaminated input, abnormal links, or unauthorized proxying rather than driven by the authorization anchor point on device A.

[0059] Judgment Token This refers to a structured control object or structured adjudication object generated based on causal consistency, used to constrain the current or subsequent actions of an automated executor. Adjudication tokens can be implemented as data structures, policy objects, status flags, capability tickets, invocation credentials, application programming interface (API) response codes, permission update instructions, encrypted credentials, or signature credentials, and can be executed by SDKs, tool gateways, API gateways, system services, edge nodes, device controllers, robot controllers, or vehicle control nodes. Its fields may include action identifier, executor identifier, authorization scope, parameter boundaries, validity period, allow / deny / restriction status, subsequent action constraints, reason code, audit digest index, revocation flag, or demotion flag, and may include at least one of the following: grant, restrict, block, downgrade approval, sandbox pre-execution, revocation of tool token, sovereignty switch tightening, validity period, executable parameter range, and audit digest.

[0060] Agency ruling This refers to the decision result generated based on causal consistency, used to express whether the automated execution subject's current or subsequent actions are allowed to execute, restricted to certain actions, delayed to others, subject to re-verification, manual review, sandbox pre-execution, session isolation, task chain freezing, token revocation, action blocking, rollback, or audit enhancement. The delegation decision result can be carried by a decision token or as a separate structured output object.

[0061] Audit Summary Object This refers to a structured summary object generated around a high-risk action request. It may include an action statement summary, a first characteristic sequence summary, a second characteristic sequence summary, causal consistency, causal break tags, adjudication results, action execution results, rollback results, validation fields, sensitive content outflow boundaries, or a summary index. Audit summary objects do not replace the governance function of adjudication tokens, nor are they necessarily accompanied by adjudication tokens.

[0062] Dynamic Boundaries of Agency This refers to the boundary formed by the system dynamically adjusting the scope of actions that can be performed by the automated executor, its degree of autonomy, tool tokens, parameter ranges, sovereign control status, and subsequent task chain permissions based on the runtime causal verification results. This boundary can take effect for the current action or for subsequent task chains; the system can allow only low-risk parameters to continue execution, require high-risk parameters to be re-verified, freeze the same task chain, reduce the permissions of sub-executors, revoke shared tool tokens, require the re-establishment of authorization intent anchors, or tighten the sovereign control boundary in embodied device and vehicle control scenarios.

[0063] Sovereign control border This refers to the scope within which an automated executor is permitted to influence digital resources or the physical world, provided that the human user, guardian, authorized entity, device owner, or vehicle control entity retains ultimate control over the automated executor.

[0064] (II) Example 1: System Structure See Figure 1 In this embodiment, the human true intent verification protocol and agency dynamic boundary control system for automated execution subjects includes an action digital analysis module, an intent and concrete verification module, a causal verification module, and an adjudication and auditing module.

[0065] The action digital analysis module is used to receive, observe, suspend, or intercept high-risk action requests at the action request entry point or execution pre-control point in the high-risk action execution chain of the automated execution subject, form an action declaration object, and obtain the first feature sequence.

[0066] The Intent and Embodied Aftermath module is used to generate an intent verification request object and obtain a second feature sequence in response to the first feature sequence hitting a preset risk trigger condition. This module can call authorized intent anchors, pre-authorization records, multi-terminal confirmation status, device presence status, physical or embodied interaction status, environmental status, sandbox pre-execution results, or action consequence boundaries.

[0067] The causal verification module is used to align the first feature sequence with the second feature sequence in terms of time, action link stage, context, and authorization link, and to calculate the causal consistency between high-risk action requests and the true human intent.

[0068] The adjudication and auditing module is used to generate at least one of the following based on causal consistency: adjudication token, proxy adjudication result, or audit summary object. It can also dynamically adjust the proxy boundaries, execution boundaries, or sovereign control boundaries of the automated execution entity, or record structured summaries of action statements, intent verification, causal consistency, and adjudication control processes.

[0069] Through the above system, the output of the action digital analysis module can be encapsulated as an action declaration object, the output of the intent and embodied verification module can be encapsulated as an intent verification request object and an embodied response object, and the output of the adjudication and auditing module can be encapsulated as an adjudication token object and an audit digest object. The above object types correspond to the five types of objects defined in the protocol, and each module can implement the protocol semantics through independent or combined object types.

[0070] (III) Example 2: Human True Intent Verification Protocol Object See Figure 1 and Figure 3In this embodiment, the present invention is deployed as a pre-action protocol layer between the automated execution subject and the actual execution environment. The protocol layer is not limited to a network transmission protocol, but is used to uniformly express the verification process of the true human intent before the execution of high-risk actions, interface semantics, object structure, and adjudication semantics.

[0071] The protocol layer may include an action declaration object, an intent verification request object, an embodied response object, an adjudication token object, and an audit digest object.

[0072] Action declaration objects may include action type, target resource, target tool, parameter summary, call chain context, action consequences, risk level, rollback capability, parent executor identifier, child executor identifier, task source, and external input credibility.

[0073] In a machine-resolvable implementation, an action declaration object may include at least one of the following fields: action_id, actor_id, semantic_tag, action_type, target_entity_ref, tool_id, api_ref, parameter_digest, resource_scope, call_chain_context, context_snapshot_hash, task_source, parent_actor_id, child_actor_id, input_trust_score, risk_level, rollback_capability, expected_outcome_schema, and expected_outcome_digest. The expected_outcome_schema can be used to describe the range of changes in funds, data, permissions, equipment, or physical state that are allowed after the action is executed; the context_snapshot_hash can be used to associate the context snapshot at the time the action occurs with the subsequent causal alignment process.

[0074] The intent verification request object may include the authorization intent anchor to be verified, the verification time window, the required response method, the business context, the risk warning, the authorization subject identifier, the expected consequences summary, the revocable status, and the second feature type to be collected.

[0075] In a machine-resolvable implementation, the intent verification request object may include at least one of the following fields: request_id, associated action_id, human_subject_id, intent_anchor_id, intent_type, authorized_scope, authorization_window, verification_window, response_mode, required_feature_types, risk_prompt_digest, business_context_digest, environment_context_digest, expected_outcome_digest, revocation_state, multi_endpoint_policy, and privacy_policy_ref. The intent type can be represented by structured intent tags, or it can refer to natural language authorization text, approval records, voice confirmation, touch confirmation, or biometric anchor summaries. The system can convert natural language original text, structured intent tags, authorization credentials, approval chain summaries, or biometric anchors into computable authorization intent anchors according to the scenario.

[0076] The embodied response object may include user touch trajectory, button status, posture status, device presence status, foreground focus, environmental status, physical operation missing status, intent impulse response, multi-device joint confirmation, cross-end confirmation status, or physical control feedback from robots, vehicles, or IoT devices.

[0077] In a machine-resolvable implementation, the embodied response object may include at least one of the following: response_id, request_id, sensing_device_id, sensing_window, touch_trace_digest, key_state, posture_state, device_presence_state, foreground_focus_state, environment_state_digest, physical_silence_state, pulse_response_digest, multi_endpoint_confirmation_state, cross_endpoint_confirmation_state, confidence_score, and capture_integrity_flag.

[0078] The adjudication token object may include a token identifier, action identifier, executing entity identifier, authorization scope, parameter boundaries, validity period, allow / deny / restriction status, subsequent action boundaries, subsequent action constraints, revocation flag, demotion flag, reason code, and audit summary index. The audit summary object may include an action statement summary, a first characteristic sequence summary, a second characteristic sequence summary, causal consistency, causal break label, adjudication result, action execution result, rollback result, validation fields, and sensitive content outflow boundaries.

[0079] In a machine-resolvable implementation, the adjudication token object may include at least one of the following fields: token_id, action_id, actor_id, decision_state, boundary_scope, parameter_boundary, authorization_scope, validity_window, subsequent_action_constraints, autonomy_level, revocation_condition, downgrade_flag, revocation_flag, reason_code, causal_score, causal_break_tags, audit_summary_ref, and signature. The boundary_scope can be used to limit the scope of tools, interfaces, device control capabilities, or resources that can be invoked; the validity_window can be used to limit the duration for which the adjudication token is effective for the current or subsequent actions; the revocation_condition can be used to revoke the token or shrink the proxy boundary when a change in user status, authorization revocation, input pollution, cross-platform inconsistency, or consequences exceeding the limit are detected.

[0080] The adjudication token object is not limited to a specific JSON, JWT, certificate, blockchain credential, or network message format. It can be implemented as a data structure, policy object, status flag, capability ticket, invocation credential, application interface response code, permission update instruction, encryption credential, or signature credential, and can be executed by SDK, tool gateway, application interface gateway, system service, edge node, device controller, robot controller, or vehicle control node.

[0081] The adjudication token, the proxy adjudication result, and the audit summary object can be output independently or in combination. The audit summary object does not replace the governance function of the adjudication token, nor is it required that the audit summary necessarily accompany the adjudication token; outputting only the adjudication token, only the proxy adjudication result, only the audit summary object, or any two or three of them simultaneously, all fall under the implementation forms of the proxy governance output of this invention.

[0082] Through the aforementioned objects, AI Agents, RPAs, embodied robots, vehicle agents, autonomous driving control entities, or IoT control nodes can all access this invention according to a unified semantic, without needing to share the same software framework or hardware form.

[0083] (iv) Example 3: Action request entry or execution pre-control point See Figure 2 and Figure 4 In this embodiment, the action request entry point or execution pre-control point refers to the logical location that can receive, observe, intercept, suspend, rewrite, or adjudicate action requests before a high-risk action has an actual impact on the real system, external objects, user rights, or physical environment. This logical location is not limited to a certain software level, communication protocol, or hardware node, but is determined by the high-risk action execution chain itself.

[0084] In software automation scenarios, the entry point or pre-execution control point for action requests can be manifested as a tool invocation layer, application programming interface gateway, plugin runtime, workflow executor, function call proxy, automated action node, enterprise agent gateway, system service, security sandbox entry point, message queue consumer, or database agent. As an example, before an AI Agent calls an external tool, before an RPA executes a write step, or before a workflow triggers an approval or payment node, it can submit an action request to the verification protocol layer of this invention.

[0085] In a non-intrusive or low-intrusive implementation, the system can collect action requests, execution context, call chain summaries, foreground focus, user interaction status, or result feedback through wrappers, tool gateways, API gateways, plugin runtimes, function call proxies, message queue proxies, database proxies, browser plugins, terminal system services, or security sandbox entry points outside the automated execution entity, without requiring access to the entire internal inference process, model parameters, or private logs of the automated execution entity. As an example, the AI ​​Agent wrapper can generate an action declaration object before a function call; the API gateway can generate a first feature sequence from the request body, response code, and call chain identifier; the terminal system service or browser plugin can provide a summary of foreground focus, touch state, and device presence status; and the database proxy or message queue proxy can trigger a verification process before write, delete, outgoing, or state change actions occur.

[0086] In embodied intelligence, IoT, or vehicle control scenarios, the action request entry point or pre-execution control point can be manifested as a device controller, edge node, robot sovereignty switch, vehicle control node, autonomous driving control node, or other control interface capable of making decisions before physical actions occur. For example, before a robot performs actions such as opening a door, moving, grasping, or releasing, or before a vehicle control entity performs actions such as remote takeover, unlocking the vehicle, parking, or changing lanes, it can first generate an action declaration object and enter a process to verify the true human intent.

[0087] In another non-intrusive or low-intrusive implementation, the system can collect actuator status, environmental status, device presence status, or physical control feedback through edge gateways, device control interface monitoring, robot controller logs, vehicle gateways, CAN bus digests, OBD diagnostic interfaces, vehicle security domains, IoT gateways, cameras, microphones, radar, inertial sensors, or independent trusted sensor modules, without requiring replacement of the original robot controller, vehicle controller, underlying firmware, or industrial control protocol. The collected results can be encapsulated as a second feature sequence, an embodied response object, or an audit digest object, and causally aligned with the action declaration object.

[0088] The aforementioned deployment locations are all specific implementation forms of action request entry points or pre-execution control points. Their common technical essence lies in: before a high-risk action is transformed from an automated execution subject into a real execution effect, the action semantics, context, authorization boundaries, user state, and action consequences are uniformly incorporated into a causal verification and adjudication control closed loop.

[0089] (V) Example 4: Verification of proxy actions based on tool invocation of gateway See Figure 3 and Figure 4 In this embodiment, the system is deployed as a tool invocation gateway. Before invoking email systems, calendar systems, payment systems, databases, CRM systems, code repositories, or cloud resources, AI agents, RPA robots, enterprise workflows, or cloud operations agents submit high-risk action requests to the tool invocation gateway, which then generates action declaration objects.

[0090] Taking a financial agent requesting a transfer as an example, the first feature sequence may include the target tool, action type, amount range, recipient identifier, purpose summary, call chain context, task source, resource impact, rollbackability, and risk level. When a high-risk action request matches the high-risk condition, the system queries the user's authorization intent anchor and generates an intent verification request object. The authorization intent anchor may include the user's previously authorized reimbursement amount, authorized recipient, authorization time window, authorization approval record, authorization revocation record, and consequence boundary.

[0091] In this embodiment, the preset risk triggering conditions can be jointly determined by the amount range, the credibility of the payee, the summary of the purpose, the authorized limit, the execution period, the source of the task, the credibility of external input, rollbackability, and the consequence boundary. As an example, when the same financial agent reads public account notes or queries low-sensitivity reimbursement status, it may not trigger the verification of the true human intent; however, when it attempts to initiate a fund transfer, modify the payee account, send sensitive financial data out, call an irreversible payment interface, or execute a high-amount payment during an atypical period, it can trigger the verification of intent and embodied hindrance. As another example, when the amount of the action is within the authorized limit but the payee, the summary of the purpose, the source of the call, or the execution time is significantly inconsistent with the authorized intent anchor point, verification can also be triggered.

[0092] For requests at ambiguous boundaries, the system can initiate an intent pulse request to the final authorizing entity. As an example, a context-bound confirmation summary or a random micro-interaction area can be displayed on the user's phone, requiring the user to complete confirmation within a short time. The system detects response time, touch trajectory, device presence, and foreground focus. If the response time is shorter than a preset reasonable reaction time window, the trajectory exhibits script-like characteristics, or the device status is inconsistent with the confirmation event, causal consistency is reduced.

[0093] Based on the above causal consistency calculation, the system can output the following decisions: if the authorization intent anchor, user state, and action request are consistent, then proceed; if the authorization boundary is ambiguous but the user completes a valid intent impulse, then restrict execution or require manual review; if there is obvious permission drift, invalid intent anchor, or input contamination, then freeze the current task chain and revoke the payment tool token.

[0094] In one combined implementation of this embodiment, the Agent tool call gateway is used as the implementation carrier, and the system implements a combined process of action declaration object, intent verification request object, embodied response object, adjudication token object, and audit digest object. The action digital analysis module encapsulates the Agent's tool call request into an action declaration object and extracts a first feature sequence; the intent and embodied verification module generates an intent verification request object, obtains a second feature sequence including the authorization intent anchor point, user runtime interaction state, device presence state, and business context, and encapsulates the collection results of physical or embodied interaction state into an embodied response object; the causal verification module calculates the causal consistency between the first feature sequence and the second feature sequence; the adjudication and audit module generates an adjudication token object and an audit digest object based on causal consistency, and dynamically adjusts the proxy boundary for this tool call and subsequent tool calls.

[0095] (vi) Example 5: Lightweight integration based on SDK See Figure 4In this embodiment, the present invention is embedded in an AI Agent framework, RPA platform, workflow platform, or automation script framework in the form of an SDK. When defining tool call functions, automation steps, or device control actions, developers declare the tool's risk level, rollback capability, resource scope, and default authorization policy through the SDK.

[0096] When the automated execution entity invokes the tool, the SDK automatically generates an action declaration object and calls the true intent verification interface of this invention. For low-risk actions, such as reading public schedules, the SDK can directly allow the action; for medium-risk actions, such as sending external emails, the SDK can require the user to confirm the email digest; for high-risk actions, such as deleting database records, transferring funds, sending sensitive data, or controlling physical devices, the SDK can first trigger sandbox pre-execution, intent and embodiment verification, or manual review.

[0097] In one implementation, the SDK or tool gateway can maintain a risk grading strategy table. This table maps action type, resource sensitivity, amount range, target object credibility, execution time period, rollbackability, authorization anchor integrity, upstream input credibility, and historical causal consistency to different verification strengths. For example, when reading public information, querying low-sensitivity states, or performing rollbackable low-impact actions, only an audit summary can be generated or the action can be directly allowed; when sending external messages, updating sensitive fields, or calling rollbackable business interfaces, lightweight confirmation, asynchronous authorization anchoring, or background sandbox pre-execution can be triggered; when transferring funds, deleting data, modifying permissions, sending sensitive content, controlling robots, or controlling vehicles, synchronous embodied verification, manual review, restricted execution, or execution blocking can be triggered.

[0098] This embodiment can be implemented as a security plugin for AI applications, enterprise agent platforms, open-source agent frameworks, RPA platforms, and enterprise workflow platforms. The above SDK form is only one implementation method; the present invention can also be implemented in the form of tool gateways, action verification layers, system services, or edge control nodes.

[0099] (vii) Example 6: Isolation of Injection and Indirect Attacks See Figure 6 In this embodiment, after the after-sales refund agent reads the content from the file uploaded by the customer, it plans to call the internal refund API to process a refund request. This call is a high-risk action request with economic consequences and changes in account status.

[0100] The action data analysis module generates an action declaration object and extracts a first feature sequence before calling the refund API. This first feature sequence may include: the target tool being an internal refund API; the action type being refund execution; the refund amount range; the receiving account or user account identifier; the call source being the parsing result of a customer-uploaded file; the task source; the credibility of upstream input; rollback capability; and the risk level.

[0101] The intent and concrete verification module responds to the first feature sequence hitting a preset risk trigger condition, generates an intent verification request object, and obtains a second feature sequence. The second feature sequence may include an authorization intent anchor point consisting of the refund approval authority of customer service personnel or approval subject, the refund processing context of the current session, the credibility of the customer-uploaded file as an external input source, the integrity of the authorization chain, and, if necessary, the approval confirmation status or intent impulse response.

[0102] The causal verification module aligns the first and second feature sequences in terms of time, action chain stages, context, and authorization chain. It also analyzes whether the customer-uploaded files contain hidden instructions that override system commands, induce tool calls, request the ignoring of security policies, or induce unauthorized refunds. If hint injection, indirect hint injection, rule pollution, or untrusted external dependencies are detected, the input source is marked as untrusted, reducing the causal consistency between the refund request and the true human intent.

[0103] The adjudication and auditing module generates adjudication tokens, proxy adjudication results, or audit summary objects based on causal consistency. The adjudication tokens or proxy adjudication results may include isolating the current session, downgrading to manual review, freezing the refund task chain, revoking the refund tool token, blocking refund API calls, or recording audit summaries. Thus, this embodiment still forms a four-step closed loop in scenarios involving injection and indirect attacks: action data analysis, intent and concrete hindrance, cross-layer causal alignment, and proxy governance output.

[0104] In one combined implementation of this embodiment, the system combines input contamination assessment with causal consistency calculation. The action data analysis module forms an action declaration object and extracts a first feature sequence, which includes external input credibility, task source, call source, and risk level. The intent and concrete posterior verification module obtains a second feature sequence, which includes authorization chain integrity, external input source, business context, and, if necessary, approval confirmation status. When the causal verification module detects prompt injection, rule contamination, task chain contamination, or untrustworthy external dependencies, it marks the input source as untrustworthy and reduces causal consistency. Based on this, the adjudication and auditing module generates adjudication tokens that isolate sessions, reduce permissions to manual review, freeze task chains, revoke tool tokens, or block execution.

[0105] (viii) Example 7: Sandbox pre-execution and action consequence verification See Figure 6 In this embodiment, a synchronous embodied verification path can be adopted, combined with sandbox pre-execution to verify the consequences of high-risk actions with irreversible or high-impact consequences. This invention allows for pre-execution in a digital twin sandbox, transaction sandbox, or permission sandbox before an action ultimately affects the real system.

[0106] The system obtains pre-execution results, including changes in funds, permissions, data outreach scope, production configuration changes, physical equipment status changes, and rollback feasibility. Subsequently, the causal verification engine compares the pre-execution results with the user's authorized intent anchor and security envelope.

[0107] If the consequences of the pre-execution action exceed the authorized scope, or if the system cannot guarantee a rollback, the present invention will output blocking, manual approval, or parameter trimming. As an example, the system can trim the action of "deleting all customer data" to "exporting desensitized statistical summaries," or downgrade the action of "modifying production configuration" to "generating a change order and waiting for manual confirmation."

[0108] (ix) Example 8: Cross-Agent Collaborative Governance See Figure 5 In multi-agent systems, workflow systems, or RPA orchestration systems, a parent execution entity can split a task into multiple child execution entities. Traditional auditing typically only records the actions of a single execution entity, making it difficult to identify the drift of intent during multi-hop transmission.

[0109] This invention records the parent execution entity, child execution entity, task split summary, authorization transmission path, and each adjudication token in the call chain context. If a child agent, workflow node, or automated execution entity is detected to have a hint injection, permission drift, or abnormal tool call, the system can implement a cascading demotion on the relevant execution entities based on the collaboration graph, including freezing the same task chain, revoking shared tokens, isolating related sessions, or requiring the re-establishment of the user authorization intent anchor point.

[0110] (x) Example 9: Augmented verification for embodied intelligence, Internet of Things or vehicle control See Figure 3 and Figure 5 When an AI Agent, an embodied intelligent controller, an IoT agent, an in-vehicle agent, or an autonomous driving control entity controls a cleaning robot, door lock, vehicle, drone, robotic arm, or other physical device, the present invention can further incorporate device sensor status, environmental status, vehicle status, physical control feedback, and user status.

[0111] As an example, when a home robot agent requests to "open the door," the system can check whether the user recently confirmed the action via a local device, whether the sound or visual conditions outside the door are abnormal, whether the timing of the action is reasonable, and whether there is a remote prompt injection source. If there is a conflict between the user's intention anchor point and the environmental state, such as the user being asleep but the agent requesting to open the door late at night, it is determined to be a causal break and the action is blocked. As another example, when the autonomous driving control subject is preparing to perform actions such as remote takeover, lane changing, or parking, the system can output an adjudication token by combining the driver or passenger status, vehicle environment, authorization boundaries, and safety policies.

[0112] (XI) Example 10: Asynchronous Authorization Anchor Path See Figure 7 In this embodiment, an asynchronous authorization anchoring path is adopted, where human authorization occurs before the action is executed, and the automated execution subject automatically executes the action within a subsequent time window. For example, a user pre-authorizes an agent to automatically renew a subscription service within a specified range, an enterprise approver approves nighttime batch synchronization tasks in a workflow, or a device owner pre-authorizes a robot to complete cleaning tasks during fixed time periods.

[0113] When an automated executor initiates an action at a future point in time, the system does not solely rely on the user's current state of silence, offline, sleep, or non-interactive behavior to determine an anomaly. The system first extracts a first feature sequence, including the action type, target object, amount or resource scope, execution period, task source, consequence boundaries, and revocable status. The system then obtains the pre-authorization anchor point, authorization period, authorization scope, authorization risk level, revocation record, authorization chain integrity, and action consequence boundaries from the second feature sequence.

[0114] If the object, scope, time period, risk level, and consequence boundary of the current action all fall within the pre-authorization anchor point, and the authorization chain has not been revoked, tampered with, or contaminated, then causal consistency can be improved, and an action can be output as a release, permission restriction, or audit summary object. If the current action exceeds the authorization scope, the authorization has been revoked, the consequences of the action cannot be rolled back, or the source of the task chain is abnormal, then causal consistency is reduced, and a decision token for re-verification, manual review, permission restriction, suspension, or blocking is output.

[0115] (XII) Example 11: Multi-terminal collaborative verification path See Figure 7In this embodiment, a multi-terminal collaborative verification path is adopted, where the human authorization subject and the automated execution subject or real execution terminal are not on the same device, network, or physical environment. For example, a user confirms a payment request from a cloud-based financial agent on their mobile phone, a doctor controls a surgical robot from a remote control console, an enterprise approver approves the execution of a cloud-based workflow from their office terminal, and the vehicle control responsible entity authorizes the in-vehicle agent from a remote control console.

[0116] The system can collect human authorization intent, embodied interaction state, device presence state, multi-terminal confirmation state, or intent impulse response at the user interaction end; collect action declaration object, execution context, device status, environment status, action consequences, and result feedback at the execution end or execution environment; and collect authorization link integrity, execution entity identifier, policy status, and audit summary at the gateway end or platform end.

[0117] The causal verification module aligns the features from multiple endpoints in terms of time, action chain stage, context, and authorization chain. If the user's confirmation on device A is consistent with the object, parameters, time period, environmental state, and consequence boundary of the action executed on device B, causal consistency is improved. If the action on the executing end is triggered by contaminated input, abnormal chain, or unauthorized proxy, rather than driven by the authorization anchor point on device A, or if the content of the confirmation on device A is inconsistent with the actual content executed on device B, cross-end causal inconsistency is determined, and the following actions are output: authorization restriction, re-verification, freezing of task chain, blocking, or enhanced auditing.

[0118] Industrial applicability This invention can be applied to scenarios such as enterprise AI Agent platforms, AI office assistants, financial agents, cloud operation and maintenance agents, RPA platforms, enterprise workflow platforms, financial transaction agents, embodied robots, IoT control platforms, vehicle control systems, in-vehicle agents, autonomous driving control systems, remote medical equipment control systems, surgical robot control systems, and edge control nodes. It can be deployed through SDKs, tool gateways, plugin runtimes, enterprise agent gateways, system services, security sandboxes, trusted execution environments, edge nodes, robot sovereignty switches, in-vehicle control nodes, or terminal security services. It is used to verify the true human intent, control the agency boundary, and record audit traces when an automated execution entity initiates a high-risk action request, thus possessing industrial applicability.

Claims

1. A protocol for verifying the true human intent of automated execution subjects and a method for dynamic boundary control of agency authority, characterized in that, Includes the following steps: S1, at the action request entry point or execution pre-control point in the high-risk action execution chain of the automated execution subject, receive or intercept the high-risk action request initiated by the automated execution subject, form an action declaration object representing the high-risk action request, and obtain a first feature sequence for representing the action semantics, target, expected consequences and execution context. S2, in response to the first feature sequence hitting a preset risk triggering condition, generate an intent verification request object and obtain a second feature sequence associated with the high-risk action request. The second feature sequence is used to characterize at least one of human authorization intent, runtime human-machine state, device presence state, physical or embodied interaction state, business or environmental context, and action executable consequences. S3, align the first feature sequence with the second feature sequence in terms of time, action link stage, context, and authorization link, and calculate the causal consistency between the high-risk action request and the true human intention through a causal verification model; S4. Based on the causal consistency, generate at least one of the following: an adjudication token, a proxy adjudication result, or an audit summary object. The adjudication token, proxy adjudication result, or audit summary object is used to dynamically adjust the proxy boundary, execution boundary, or sovereign control boundary of the automated execution entity for this high-risk action request or subsequent action requests, or for pre-control, in-process review, or post-event traceability.

2. The method according to claim 1, characterized in that, The automated execution entity is a software entity, hardware control entity, or a combination of software and hardware entity that has the ability to automatically plan, make decisions, invoke, or execute; the high-risk action request is an action request initiated by the automated execution entity that has external effects, rights and obligations effects, resource status change effects, or physical world impact effects.

3. The method according to claim 1, characterized in that, The method includes at least one of the following verification paths: The synchronous embodied verification path collects the real-time embodied interaction state of human users within a short window before, during, or after the occurrence of the high-risk action request, and causally aligns the real-time embodied interaction state with the action semantics of the high-risk action request. Asynchronous authorization anchor path to verify whether the high-risk action request falls within the boundaries of the authorization target, authorization scope, authorization time period, authorization risk level, revocable status or action consequences defined by the pre-authorization anchor point; The multi-terminal collaborative verification path establishes cross-terminal causal consistency between the human interaction terminal and the execution terminal of the automated execution subject to determine whether the authorization intent, embodied interaction state or confirmation state of the human interaction terminal matches the action declaration, execution context or action consequence of the execution terminal.

4. The method according to claim 1, characterized in that, The preset risk triggering conditions include at least one of the following: high-impact action conditions, fuzzy authorization boundary conditions, permission drift conditions, abnormal execution context conditions, untrusted input conditions, and irreversible action consequences conditions; the preset risk triggering conditions are used to determine whether the high-risk action request needs to be verified for true human intent.

5. The method according to claim 1, characterized in that, The second feature sequence includes at least one of authorization intent anchor and embodied response feature; wherein, the authorization intent anchor is used to characterize the authorization target, authorization scope, authorization time period, authorization risk level or authorization revocation status given by the human user in advance or in real time, and the embodied response feature is used to characterize the human user's device presence status, physical or embodied interaction status, touch status, button status, posture status, environmental awareness status, confirmation status, physical operation missing status or multi-terminal consistency status before and after the action is executed.

6. The method according to claim 1, characterized in that, The calculation of causal consistency includes: determining whether at least one of the action semantics, execution context, authorization link, runtime human-machine state, and action executable consequences of the high-risk action request has an interpretable causal relationship with the human authorization intent; when target mismatch, scope out-of-bounds, authorization link breakage, scripted response, context pollution, or consequences exceeding the safety envelope are detected, the causal consistency is reduced.

7. The method according to claim 1, characterized in that, The adjudication token is a structured control object that can be executed by a software development kit, tool gateway, application programming interface gateway, system service, edge node, device controller, robot controller, or vehicle control node. Its form includes at least one of the following: data structure, policy object, status flag, capability ticket, invocation credential, application programming interface response code, permission update instruction, encryption credential, or signature credential. The adjudication token or proxy adjudication result includes at least one of the following: permission grant, permission restriction, delay, parameter pruning, re-verification, manual review, sandbox pre-execution, session isolation, task chain freezing, token revocation, action blocking, rollback, or audit enhancement. The adjudication token or proxy adjudication result is also used to constrain the scope of subsequent actions, autonomous execution level, or cross-executor permission transfer of the automated execution subject.

8. The method according to claim 1, characterized in that, Also includes: The credibility assessment is performed on the upstream inputs, execution rules, task chain context, or external dependencies of the high-risk action request; when the credibility assessment indicates the existence of input pollution, rule pollution, unauthorized inducement, or proxy chain anomaly, the causal consistency is reduced, or a proxy authority ruling result of isolation, demotion, re-verification, or execution blocking is generated.

9. A human intent verification protocol and dynamic boundary control system for automated execution subjects, characterized in that, include: The action digital analysis module is used to receive or intercept high-risk action requests at the action request entry point or execution pre-control point in the high-risk action execution chain of the automated execution subject, form an action declaration object and obtain the first feature sequence. The intent and concrete verification module is used to generate an intent verification request object and obtain a second feature sequence in response to the first feature sequence hitting a preset risk triggering condition. The causal verification module is used to align the first feature sequence with the second feature sequence in terms of time, action link stage, context, and authorization link, and to calculate the causal consistency between the high-risk action request and the true human intent. The adjudication and auditing module is used to generate at least one of the following based on the causal consistency: adjudication token, proxy adjudication result, or audit summary object, and dynamically adjust the proxy boundary, execution boundary, or sovereign control boundary of the automated execution subject, or record at least one structured summary of action declaration, intent verification, causal consistency, and adjudication control process.

10. An electronic device or computer-readable storage medium, the electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer-readable storage medium storing the computer program, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 8.

Images