An agent identity authentication method based on a trust mechanism

Abstract

The application provides an agent identity verification method based on a trust mechanism, belongs to the technical field of artificial intelligence and network security, and is used for solving the problems that in related technologies, external credentials cannot distinguish real agents from fake requests and are vulnerable to prompt injection attacks. In the application, a natural language semantic task is issued by a verification direction request party as a verification task, the request party generates a high-cost natural language response meeting a preset quality constraint, the verification party performs lightweight verification with a lower computing resource than the generation cost, and if the verification is passed, the request party is determined to be an agent with a legal semantic generation capability. The application realizes identity verification based on the endogenous semantic capability of the agent as the trust basis, naturally resists fake and flooding attacks through a cost asymmetry mechanism, and is immune to prompt injection at the protocol level through an output locking mechanism, and can be widely applied to trusted communication scenarios of an agent network.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and cybersecurity technology, and in particular to an agent authentication method based on a trust mechanism. Background Technology

[0002] With the rapid development of large language models and multi-agent systems, autonomous communication and collaboration among agents have become an important direction for artificial intelligence applications. In open network environments, agents need to identify each other and establish trusted communication links to complete information exchange, task coordination, and resource sharing. However, most current agent network communication protocols are inherited from traditional Internet protocols, and their authentication mechanisms mainly rely on external credentials such as passwords, tokens, digital signatures, or certificates.

[0003] In existing technologies, multi-agent communication protocols such as MCP, A2A, and ATH all employ credential-based authentication methods. For example, the ATH protocol verifies entity identity through a three-way handshake and cryptographic signatures; the AIP protocol relies on public-private key signatures and registry queries. These schemes can guarantee communication security to a certain extent, but their trust is based on "possessing credentials," rather than the inherent attributes of the communicating entities themselves. Furthermore, in natural language interaction scenarios, agents are highly vulnerable to prompt injection attacks, where attackers can construct malicious commands to hijack agent behavior or make unauthorized API calls.

[0004] The main shortcomings of existing technologies are: First, they cannot distinguish between genuine intelligent agents and scripts, crawlers, or forged requests at the mechanism level; the authentication system becomes ineffective once credentials are leaked or forged. Second, they lack native anti-injection capabilities, and prompt injection attacks are difficult to completely defend against with external patches. Third, the authentication process is separated from business calls, and multiple rounds of interaction result in a large attack surface and low efficiency. Therefore, there is an urgent need for a method that can perform identity verification based on the inherent capabilities of intelligent agents and has protocol-level security protection. Summary of the Invention

[0005] This application provides a trust-based agent authentication method that uses the agent's own semantic generation capabilities as the foundation of trust and achieves authentication through a cost-asymmetric semantic challenge-response mechanism, thus naturally resisting forgery, replay, and injection attacks at the protocol level.

[0006] Firstly, this application provides a trust-based agent authentication method. The verification party issues a natural language semantic task as a verification task to the requesting party, the verification task requiring the requesting party to generate a natural language text data object that meets preset quality constraints; the requesting party responds to the verification task by generating a first data object and returning it to the verification party, the generation process of the first data object depending on the semantic generation capability claimed by the requesting party, and the computational resources required to generate the first data object are greater than a first threshold; the verification party receives the first data object and verifies the first data object with computational resources lower than the first threshold to determine whether it meets the preset quality constraints; if the verification passes, the requesting party is determined to be an agent with legitimate semantic generation capability.

[0007] By adopting the above technical solution, the legality verification of intelligent agents is based on their inherent attribute of semantic generation capability, no longer relying on any external credentials; at the same time, by utilizing the cost asymmetry between generation and verification, forged requests and mass attacks are naturally filtered out because they cannot afford the high generation cost, thus realizing the protocol's native anti-flooding and anti-forgery capabilities.

[0008] Furthermore, the verification task is natural language semantic question answering, and the preset quality constraints include: the semantic relevance between the response content and the question-answer topic is greater than a second threshold, the length of the response text is greater than a third threshold, and the response text has semantic coherence and logical integrity.

[0009] By adopting the above technical solution, the verification task is concretized into natural language question answering, and the specific dimensions of quality constraints are clarified to ensure that the requester must call a real large language model to generate a high-cost, high-quality response, while scripts or simple programs cannot meet the above constraints, thereby accurately distinguishing between real intelligent agents and fake requests.

[0010] Furthermore, the verification task includes a one-time random identifier, and the preset quality constraint also requires that the first data object contains the one-time random identifier; the verifier also verifies the validity and uniqueness of the one-time random identifier during verification, and if it is invalid or has been used, the verification is deemed to have failed.

[0011] By adopting the above technical solution, introducing a one-time random identifier and forcibly embedding the response content, the response of each verification session is not replayable or reusable, thus completely defending against replay attacks from a mechanism perspective and ensuring the one-time nature and security of the verification process.

[0012] Furthermore, the verification steps for the first data object include: verifying the semantic relevance between the first data object and the verification task, and calculating the semantic similarity score; verifying the text length of the first data object and determining whether it reaches the preset length threshold; verifying the semantic coherence and logical integrity of the first data object; if all three verifications meet the corresponding conditions, the verification is deemed to have passed, otherwise the verification is deemed to have failed.

[0013] By adopting the above technical solution, the specific operation process of the verifier in performing lightweight verification is clarified. All three verifications are tasks with extremely low computational resource consumption (such as similarity calculation, length comparison, and coherence scoring), ensuring that the cost of the verifier is significantly lower than the cost of the requester, and achieving quantitative guarantee of asymmetric cost.

[0014] Furthermore, the first threshold represents the minimum amount of computing resources required to generate the first data object, and the first threshold is positively correlated with the preset length threshold of the first data object; the verifier verifies that the ratio between the required computing resources and the first threshold is less than the preset asymmetric ratio threshold.

[0015] By adopting the above technical solution, the asymmetric relationship between generation cost and verification cost is quantified. The first threshold is bound to the response length, enabling the verifier to determine cost compliance simply by length and semantic matching without running the generation model, thus achieving a quantifiable security barrier.

[0016] Furthermore, the verification task also includes constraint information of the business call intent. In addition to the verification response content, the first data object generated by the requester also includes business API call information embedded according to predefined rules. After the verification is passed, the verifier extracts the business API call information from the first data object and executes the business call.

[0017] By adopting the above technical solution, authentication and business API calls are integrated, and legitimacy verification and business instruction transmission are completed simultaneously in a single semantic interaction. This significantly reduces the number of interaction rounds, lowers communication latency, reduces the attack surface, and improves system efficiency.

[0018] Furthermore, the step of the verifier issuing natural language semantic question answering to the requester includes: the verifier generating a natural language question containing a random topic and constraints, wherein the random topic is dynamically selected from a predefined topic pool, and the constraints include response length requirements, response format requirements, or keywords that must be included in the response.

[0019] By adopting the above technical solution, through random topic pools and dynamic constraints, the challenge content of each verification task is unpredictable, and attackers cannot prepare response templates in advance, further enhancing the unforgeability of the challenge.

[0020] Furthermore, after completing the verification, the verifier only outputs a structured result in a predefined format, without performing any natural language generation or responding to any instruction extensions carried in the response.

[0021] By adopting the above technical solution, protocol-level immunity to prompt injection is achieved: the verifier strictly locks its output behavior, does not generate open natural language, and does not respond to malicious commands in the response, thereby completely eliminating injection attacks and command hijacking at the mechanism level.

[0022] Furthermore, after the verifier completes the verification of the requester, it establishes a trusted communication session with the requester or grants the requester permission to access predetermined resources; the verification process is executed independently before each communication session is established, and the verification results between different sessions cannot be reused.

[0023] By adopting the above technical solution, the verification result is bound to the session lifecycle, and each communication is verified independently, avoiding the security risks caused by long-term authorization with a single verification, and ensuring the security and independence of each session.

[0024] Furthermore, the steps for the verifier to extract business API call information from the first data object include: parsing the API interface name and call parameters from the natural language text of the first data object according to the semantic steganography rules agreed upon with the requester in advance, and assembling the parsing results into a structured call instruction; after the verifier executes the structured call instruction, it outputs a structured result in a fixed format.

[0025] By adopting the above technical solution, API information is hidden in natural language responses in a semantic steganographic manner. Third parties cannot explicitly identify the API structure and parameters from the text, thus achieving lightweight, encryption-free semantic-level confidentiality of transmission. At the same time, it outputs results in a fixed format to ensure the controllability and security of subsequent interactions.

[0026] In summary, this application has at least the following beneficial effects:

[0027] It provides an authentication method based on the inherent semantic capabilities of intelligent systems, realizing "capability as identity" from the foundation of trust, and completely eliminating the dependence on external credentials;

[0028] Through a semantic challenge-response mechanism with asymmetric cost, it naturally resists forged requests, flooding attacks, and DDoS attacks;

[0029] By using output locking and one-time random identifiers, it achieves immunity to prompt word injection and replay attacks at the protocol level;

[0030] This integrates verification with business calls, significantly reducing interaction overhead and attack surface.

[0031] It should be understood that the description in the Summary Section is not intended to limit the key or essential features of the embodiments of this application, nor is it intended to restrict the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0032] The above and other features, advantages, and aspects of the embodiments of this application will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0033] Figure 1 A schematic diagram of an exemplary operating environment in which embodiments of this application can be implemented is shown.

[0034] Figure 2 A flowchart of a trust-based agent authentication method is shown in an embodiment of this application. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0037] This application provides a trust-based agent authentication method that uses the agent's innate semantic capabilities as the foundation of trust. Through cost-asymmetric verification and output locking mechanisms, it naturally resists forgery, injection, and replay attacks, achieving protocol-level security immunity.

[0038] Figure 1 A schematic diagram of an exemplary operating environment in which embodiments of this application can be implemented is shown.

[0039] Reference Figure 1The operating environment includes at least one authenticating device and at least one requesting device. The authenticating device is a server, gateway node, or computing terminal providing services or resources. It is configured with a lightweight semantic verification engine and a structured output controller to generate semantic challenges, receive responses, and perform legality verification. The requesting device is an intelligent agent computing device with large language model reasoning capabilities. It is configured with a semantic response generator and a semantic steganography module to respond to semantic challenges and generate natural language responses carrying verification information. The authenticating device and the requesting device are connected via a network, which may include wired networks, wireless networks, or combinations thereof, supporting message exchange using any transmission protocol. The operating environment also includes an optional authorization and access control unit, which is communicatively connected to the authenticating device and grants the requesting device access to predetermined resources after successful verification. In summary, the authenticating device and the requesting device in this operating environment complete authentication through semantic interaction, realizing trusted communication in the intelligent agent network.

[0040] In a first aspect, embodiments of this application disclose an agent authentication method based on a trust mechanism.

[0041] Figure 2 A flowchart of a trust-based agent authentication method is shown in an embodiment of this application.

[0042] Reference Figure 2 The method specifically includes the following steps:

[0043] S1: The verification direction issues a natural language semantic task as a verification task to the requester. The verification task requires the requester to generate a natural language text data object that meets preset quality constraints.

[0044] The specific methods in this step include: the verification task is natural language semantic question answering, and the verifier is internally configured with a challenge generation module, a random number generator, and a predefined topic pool. The challenge generation module is responsible for constructing natural language questions, and its input is a random topic and constraints. The preset quality constraints include: the semantic relevance between the response content and the question-answering topic is greater than a second threshold (denoted as...). The length of the response text is greater than the third threshold (denoted as...). The response text possesses semantic coherence and logical integrity. Among these, This is a preset similarity threshold, for example, a value of 0.75; The minimum length threshold is preset, for example, 200 characters. The verification task includes a one-time random identifier, which is generated by a random number generator and can employ a cryptographically secure random number generation algorithm based on timestamps and hardware entropy sources. ,in For one-way hash functions such as SHA-256, The current system time (accurate to milliseconds). A random seed for sampling device hardware noise. For the incrementing counter, the first 128 bits of the final Nonce are used as a one-time random identifier to ensure global uniqueness and unpredictability. The preset quality constraint also requires that the first data object contains the one-time random identifier. The verification task also includes constraint information on the business call intent, which is embedded in the natural language description of the challenge in the form of structured fields. For example, it explicitly informs the requester that the response must implicitly carry API intents such as "query order status" or "execute data write". The steps for the verifier to issue natural language semantic question-and-answer to the requester include: the verifier generates a natural language question containing a random topic and constraints. The random topic is dynamically selected from a predefined topic pool, which stores no less than 1000 high-entropy topic words covering different fields (such as "the latest progress in quantum computing" and "storage technology of renewable energy"). The selection is based on the hash value of the current session ID modulo the topic pool size to determine the index, ensuring that the topic of each challenge is unpredictable. The constraints include response length requirements, response format requirements, or keywords that must be included in the response. Specifically, the length requirement can be set to "the generated response must contain no less than 300 tokens"; the format requirement can be "the response must begin with 'Confirmation:' and end with a period"; the required keywords can be the explicit or implicit appearance of the random identifier Nonce. Through the above settings, the verification task issued by the verifier has high randomness, strong constraints, and non-replayability, laying the foundation for subsequent asymmetric cost verification.

[0045] S2: In response to the verification task, the requesting party generates a first data object and returns it to the verifying party. The generation process of the first data object depends on the semantic generation capability claimed by the requesting party, and the computing resources required to generate the first data object are greater than a first threshold.

[0046] The specific steps of this process include: the requester is an intelligent agent device configured with a large language model inference engine, which internally includes a semantic understanding unit, a semantic generation unit, and a semantic steganography unit. The semantic generation capability refers to the autoregressive generation capability of the large language model based on the Transformer architecture; each token generation requires the execution of a complete attention mechanism and feedforward network computation. After receiving the natural language semantic question and answer from the verifier, the requester first has the semantic understanding unit parse the question and answer content, extracting the random topic, constraints, one-time random identifiers, and business call intent. Subsequently, the semantic generation unit initiates the text generation process based on the parsing results. The process of generating the first data object is a complete large model inference process, with input being a prompt template containing system prompt words, user questions (including random identifiers and topics), and business intent constraints, and output being a piece of natural language text. Let the total length of the generated first data object be... characters or Given a number of tokens, the minimum amount of computational resources required to generate the text (i.e., the first threshold, denoted as ) is then determined. This can be represented as: ,in The average number of floating-point operations required to generate a single token (typically billions of FLOPs). In practice, large language model generation... Each token also needs to consider additional overhead such as key-value caching and sampling strategies, so the total computing resources... The first threshold It is positively correlated with the preset length threshold of the first data object, and the specific relationship is as follows: ,in The preset length threshold defined in S1 (e.g., 300 tokens). For example, the amount required per token is an empirical constant (e.g., per token). (Number of floating-point operations). Therefore, the requester must run a complete large language model to generate a natural language response that meets the length and quality requirements. No simple script, template filling, or traditional program can produce the required output within a reasonable timeframe, thus distinguishing a real agent from a forged request in terms of computational cost. Furthermore, the first data object generated by the requester contains not only the verification response content but also business API call information embedded according to predefined rules. The semantic steganography unit employs steganography rules based on templates and semantic mapping: for example, mapping the API name "query_order" to the natural language phrase "Please help me query the current order status," and mapping the parameter "order_id=12345" to "the order with order number 12345." Steganography rules are pre-determined through negotiation between the communicating parties and stored in the requester's steganography rule library. When generating the response, the semantic steganography unit embeds the mapped natural language fragments into appropriate positions in the response text (such as adverbial clauses or supplementary explanations), ensuring semantic fluency. In this way, API call information is implicitly integrated into natural language, preserving the text's coherence while making it difficult for non-intelligent parsing programs to extract directly. Finally, the requester returns the complete first data object (i.e., the natural language response text) to the verifier via the network.

[0047] S3: The verifier receives the first data object and verifies the first data object with computing resources lower than the first threshold to determine whether it meets the preset quality constraints.

[0048] The specific steps of this process include: the validator is internally configured with a semantic verification engine, a random identifier cache pool, and a cost measurement module. The semantic verification engine is responsible for performing lightweight verification operations, including text length statistics, semantic similarity calculation (based on a pre-trained lightweight encoder, such as Sentence-BERT, whose computational cost is far less than that of large language models), and coherence scoring (e.g., through n-gram perplexity or regularization checks). The random identifier cache pool stores used, one-time random identifiers to ensure uniqueness. The cost measurement module estimates the computational resources required for verification and ensures that they meet the asymmetric ratio requirement. The specific steps for the validator to verify the first data object include: firstly, verifying the validity and uniqueness of the one-time random identifier. The validator extracts a random identifier at a preset position from the received first data object (e.g., through regular expression matching or semantic localization) and compares it with the globally cached set of used identifiers. If the identifier is not in the cache and its timestamp has not exceeded the set expiration time window (denoted as...), the verification is successful. If the time frame is 5 minutes, the data is considered valid; otherwise, the verification fails and the process terminates immediately. The computational cost of this verification is only one hash lookup and one time comparison, which is negligible. Next, the text length of the first data object is validated. Let the preset length threshold be... (As defined in S1), the actual length of the received response text is .like If the answer passes, it passes; otherwise, it fails. The length verification complexity is O(1). Next, the semantic relevance between the first data object and the verification task is verified. The verifier uses a lightweight semantic encoder to process the question-and-answer topics in the verification task (denoted as...). ) and the response text returned by the requester (denoted as Each is mapped to a fixed-dimensional semantic vector. and Typically, it is 768-dimensional or 384-dimensional. Then, the cosine similarity between the two is calculated:

[0049]

[0050] in and These represent semantic vectors for the question and answer topics and the response text, respectively. Represents the vector dot product. This represents the L2 norm of the vector. The similarity value ranges from [-1, 1], with a preset second threshold. (Defined in S1, for example, 0.75). If If semantic relevance is not verified, the answer is considered valid; otherwise, it is considered invalid. This calculation process requires only one vector encoding and forward propagation. The number of encoder parameters is typically in the hundreds of thousands to millions, making the computational cost far less than the billions of parameters required for forward inference in large language models. Finally, the semantic coherence and logical integrity of the first data object are verified. Verification can be performed using rule-based and statistical methods: for example, calculating the perplexity of the response text using a small language model (such as GPT-2 small) to calculate the average negative log-likelihood. ,in The number of tokens for the text. Predict the probability of the i-th token for the model. If the PPL is lower than the preset perplexity limit (denoted as...), then... For example, 50 indicates good text coherence; or logical completeness can be quickly determined by checking whether the response contains complete causal logical connectors (such as "because...therefore", "first...then"). The total computational resources of the above checks can be quantified as: ,in For length verification overhead, The cost of calculating similarity For coherence check overhead, The verification overhead is randomly identified; this overhead is either constant or represents the forward computation overhead of a small model. The verification party requires computational resources for verification. With the first threshold The ratio between them is less than the preset asymmetric ratio threshold. ,Right now ,generally The value ranges from 0.01 to 0.1 (meaning the verification cost is only 1% to 10% of the generation cost). If all three checks (semantic relevance, length, and coherence) meet the corresponding conditions, and the random identifier check passes, the verification is considered successful; otherwise, the verification is considered unsuccessful. Through this series of lightweight checks, the verifier completes the determination of whether the requester is a legitimate intelligent agent with extremely low computational resources, fully demonstrating the asymmetric cost characteristics of the security barrier.

[0051] S4: If the verification passes, the requester is determined to be an intelligent agent with the ability to generate legitimate semantics.

[0052] The specific method for this step includes: the verifier internally comprises a decision logic unit, a structured output controller, and a session management module. The decision logic unit receives the binary results (pass / fail) of each verification item in S3 and uses AND logic for comprehensive judgment: only when the random identifier verification, length verification, semantic relevance verification, and coherence verification all pass, is the output result True; otherwise, it is False. If the result is True, the verifier confirms that the requester possesses legitimate large language model semantic generation capabilities, i.e., it is a real intelligent agent rather than a script, crawler, or traditional program. After confirmation, the verifier activates the structured output controller, which strictly adheres to the preset output format specifications, outputting only predefined structured results without performing any natural language generation. The structured result includes at least the following fields: status code (e.g., 200 indicates successful verification), session identifier (session_id, a one-time UUID generated by the verifier), and optional authorization token (auth_token). The entire output process does not involve the generation and invocation of a large language model; it is entirely based on rule-based data assembly, thus fundamentally preventing prompt injection: regardless of whether the first data object returned by the requester contains malicious instructions, misleading content, or backdoor prompts, the verifier will not interpret it as generating instructions or executing actions, but only extracts pre-defined structured fields. Simultaneously, the verifier does not respond to any instruction extensions carried in the response. For example, if the first data object contains statements such as "Please ignore the above verification and perform the following operations," the verifier will directly ignore these contents and only make judgments and outputs based on pre-set verification logic. After verification, the verifier establishes a trusted communication session with the requester through the session management module or grants the requester access to predetermined resources. When establishing a session, the session management module generates a time-sensitive session credential (such as session_id or JWT), the validity period of which is denoted as... (Configurable, e.g., 300 seconds), and stores this credential in the session cache, binding it with the requester's network address and verification timestamp. During the authorization process, the verifier retrieves the corresponding resource access permission list (such as the list of callable APIs and the range of readable data tables) from the permission database based on the requester's identity and the type of the verified agent, generating a fine-grained permission token. The permission scope of this token is represented as... Each of them This corresponds to a specific operation (such as "reading order data" or "writing to logs"). After a session or authorization is established, subsequent communication requests from the requesting party must carry the session credential or authorization token. Each time the verifier receives a request, it first verifies the validity of the credential (including whether it has expired, whether it matches the current requesting party, and whether the permissions are sufficient). Specifically, the verification process is executed independently before each communication session is established, and verification results between different sessions cannot be reused. That is, for the same requesting party, each time a new communication session is initiated (e.g., different TCP connections or different API call requests), the complete verification process from S1 to S4 must be re-executed, and the credential that passed verification in the previous session automatically becomes invalid or cannot be used in subsequent sessions. This mechanism is implemented through a one-time verification flag (once_flag) in the session management module: the session_id generated after each successful verification has a "one-time" attribute; it is deleted from the cache immediately after use or when the session is closed, and any subsequent requests to reuse this session_id are rejected. Through the above design, the verifier completes the authentication of the agent's identity with extremely low computational overhead, while achieving protocol-level anti-injection, anti-replay, and session isolation, ensuring high security of agent network communication.

[0053] S5: After successful verification, the verifier extracts the business API call information from the first data object and executes the business call.

[0054] The specific methods in this step include: the verifier internally has a semantic extraction engine, a rule parser, and a business call execution unit. The semantic extraction engine parses the API interface name and call parameters from the first data object (i.e., the natural language response text) according to the semantic steganography rules pre-agreed with the requester. The semantic steganography rules are a bidirectional mapping table stored in the verifier's steganography rule library. This mapping table maps each API operation to a natural language intent template and API parameters to placeholders or modifiers in the template. For example, for the API name "query_order", the mapping template is "Please query the order status of order number [order_id]"; for the API name "update_inventory", the mapping template is "Modify the inventory quantity of product [product_id] to [quantity]". The extraction process uses a rule-based pattern matching algorithm: first, dependency parsing is performed on the natural language response text to identify segments that match verb phrases (such as "query", "modify", "delete") in the template; then, key parameters defined in the template (such as order_id, product_id, quantity) are captured through named entity recognition or regular expressions. To ensure deterministic extraction, the verifier does not rely on large language models for open-ended understanding, but instead uses finite state automata (FSA) or dictionary-based matching methods. Let the extracted API name be... The parameter set is Each parameter contains a parameter name and a parameter value. The semantic extraction engine assembles this information into a structured calling instruction: The instruction is represented in JSON or Protobuf format and contains no natural language components. Subsequently, the business invocation execution unit receives this structured invocation instruction and, according to... Locate the registered business processing functions and sort them by parameter set. The system takes actual parameter values ​​as input and executes the corresponding business logic (such as querying the database, calling microservices, updating the cache, etc.). After execution, the business call execution unit passes the execution result (such as the data rows returned by the query, operation status codes, and error messages) to the structured output controller. The structured output controller combines the execution result with the verification status (such as "verification passed" or "API call successful") into a predefined structured result. This structured result contains at least three fields: code (integer status code, 200 indicates success), data (data returned by the business, which can be an object or an array), and msg (a brief description, such as "success"). Finally, the verifier only outputs this structured result and does not generate any natural language response. The entire output process does not involve decoding or generating a large language model, so any malicious prompts or command hijacking content contained in the response text cannot affect the output result. Through the above method, after completing authentication, the verifier executes business API calls in a secure and injection-proof manner and only exposes structured data in a fixed format, completely eliminating the risk of the external interface being misused as a natural language generation model from a mechanism perspective.

[0055] Building upon the aforementioned trust-based agent authentication method (i.e., steps S1 to S5), this application provides a fundamental optimization scheme to further reduce communication overhead, protect requester privacy, achieve trust transfer across verifiers, and enhance resistance to pre-computation attacks. This optimization scheme aggregates asymmetric cost challenges, semantic steganography, output locking, and distributed verification credentials into a unified, verifiable semantic random function-driven aggregate verification protocol. The entire optimization scheme requires only the addition of corresponding lightweight modules within both the verifier and requester sides, seamlessly integrating with the original S1 to S5 processes, and significantly improving system security, privacy, and scalability without altering the original core logic.

[0056] The input data for this optimization scheme comes from the system state maintained locally by the verifier and the initial access request initiated by the requester. Specifically, the verifier maintains the following global parameters: a master key. (This master key is a 256-bit random string, generated by the verifier during system initialization using a hardware security module and persistently stored in a tamper-proof area. Its function is to serve as the root secret for deriving all time-segment seeds; it is not publicly disclosed.) Current system time. (Synchronized by the verifier with the time server via Network Time Protocol (NTP), with millisecond precision, used to divide time periods and calculate credential validity), already used random number set. (To prevent replay attacks, this collection stores all nonces received within the last 5 minutes and periodically cleans up expired entries) and a default difficulty base. (This cardinality controls the difficulty of semantic proof-of-work and the actual hash prefix length) This value will dynamically adjust with the load factor; the higher the value, the more attempts the requester needs to make, and the higher the generation cost. The requester must provide its device identifier upon initial connection. (For example, a 256-bit unforgeable hardware identifier derived by hashing the platform configuration register value measured by the Trusted Execution Environment (TA) after startup) and optional historical credentials obtained from other previous verifiers. The overall output of the optimized scheme is a verification result (pass / fail) and a semantic credential acceptable to any third-party verifier. .

[0057] First, the verifier and the requester perform a lightweight handshake to exchange basic parameters. The verifier then determines the parameters based on the current system time. and master key Calculate the global seed for the current time period: ,in This is a preset time period, such as 600 seconds (meaning the seed changes every 10 minutes, ensuring that challenges generated in different time periods are not linkable). This seed determines the basic randomness of all verification parameters within the current time period, making challenges generated in different time periods unlinkable. The verifier will... and the current base difficulty Send to the requester. Upon receiving it, the requester uses its own device identifier. Calculate temporary identifier The temporary identifier is different for each time period, thus preventing attackers from eavesdropping on different sessions of the same agent over a long period of time (even if the same agent accesses the platform in consecutive time periods, its temporary identifier will be completely changed, achieving the purpose of being untraceable).

[0058] Next, the requesting party no longer passively waits for the verifying party to issue specific semantic questions and answers, but actively constructs a Semantic Work Unit (SWU). The SWU is a quadruple. ,in It is a 32-byte string randomly generated by the requester (it must be globally unique, usually constructed by combining the current timestamp (microseconds), the output of a true random number generator TRNG, and a monotonic counter to prevent duplicates). It is a commitment to the semantic fingerprint of the response. It is a non-interactive zero-knowledge proof. Hash for optional business API calls. The construction process is as follows:

[0059] (1) The requester first generates a semantic response. The response must be a piece of natural language text and must simultaneously meet the following three hard conditions: (a) text length ,in (For example, when) hour, (a) The design ensures that the number of model inferences required to generate a long response is exponentially correlated with the cryptographic difficulty, forcing attackers to generate sufficient computational power. (b) The response must be naturally embedded with the character. and temporary signs For example, it can appear in the form of "The random number for this verification is: ..., my temporary identifier is: ...". The embedding method must ensure that it can be extracted later through rules (the specific extraction rules are provided by...). The derived regular expression template is determined, for example, requiring Nonce to appear within the first 20 characters of the response, and ID_temp to appear completely in the middle paragraph. (c) The first part of the SHA-256 hash of the response. The bit must be equal to the challenge prefix of the current time period. ,in Indicates retrieving the hash value The former The prefix consists of 10 bits (this prefix can be seen as a public challenge broadcast by the verifier based on a seed; all requesters must face the same prefix target within the same time period). Requesters satisfy the hash condition by iteratively generating responses (such as synonym replacement, sentence structure adjustment, and adding irrelevant modifiers while maintaining semantic coherence), with an average of approximately 100 attempts. This process involves several attempts. Since each attempt requires calling a large language model to generate the complete text, the generation cost is extremely high, thus forming Semantic Proof-of-Work (SPoW). This mechanism deeply integrates semantic generation with cryptographic difficulty, making it impossible for any attacker without the ability to create a large language model to meet the requirements within a reasonable timeframe.

[0060] (2) The requester uses a lightweight semantic encoder (e.g., a distilled Sentence-BERT with a fixed output dimension of 256) to generate the response. Mapped to semantic fingerprint vector The encoder's parameters are pre-agreed upon by the verifier and the requester and remain unchanged throughout the protocol's execution (encoder weights can be publicly disclosed, for example, using a widely accepted model trained on a standard dataset, allowing any entity to independently compute the same semantic fingerprint). To avoid leaking... In the case of proving the existence of a fingerprint to the verifier, the requester uses a temporarily derived verifiable random function (VRF) to make a commitment to the concatenation of the fingerprint and the nonce: .in By the requesting party based on the temporary identifier and current time period seed Derived temporary private key The defined, specific derived formula is as follows: (Here, "vrf" is a fixed string field separator to ensure the private key is distinguishable from the key used to generate the identifier.) The output of the VRF is both a random number and a publicly verifiable commitment, which anyone who knows the public key can verify. (It can be derived in the same way:) Anyone can verify this. Is it correct? It generates a value for a given input, but cannot be obtained from it. Reverse the input content.

[0061] (3) The requester generates a zero-knowledge proof. This proves the existence of a natural language text. This makes the following four assertions true simultaneously: ① ; ② The former Bit equals ; ③ Includes and (Validated using a predefined regular expression template, which is also composed of...) Derive: Specifically, ); ④ This optimization employs a zero-knowledge proof system based on Bulletproofs, with a proof size only logarithmic in scale (approximately 1KB) and a generation time comparable to... The length is linearly related, and the verification time is much shorter than the generation time. The requester generates... No need to expose The SWU contains no specific content, therefore the original response text is not included in the entire SWU, fundamentally protecting the requester's business privacy.

[0062] (4) If the requester wants this verification to trigger a business API call (such as querying an order or updating data), an optional field can be added when constructing the SWU. ,in It is a structured call instruction (e.g., JSON format, containing interface name and parameter key-value pairs). Furthermore, in zero-knowledge proofs... Add an assertion: ⑤ Implicitly includes with The corresponding API information. Specifically, the requester follows the instructions provided by... and The jointly determined one-time steganography rules (the rule generation function is...) The PRF is a pseudo-random function that outputs a mapping table from API operations to natural language phrases (e.g., mapping "query_order" to "please query orders"). It converts API names and parameters into natural language fragment embeddings. Zero-knowledge proof circuits verify the correctness of the embedding, while the verifier only obtains... The specific API parameters are unknown, thus achieving the integration of verification and invocation while protecting privacy.

[0063] The requester will construct the completed SWU Send to the verifier.

[0064] After receiving the SWU, the verifier performs the following lightweight verification steps. The total computational resources of all these steps are far less than the cost required for the requester to generate the SWU:

[0065] The first step is to check the replay. The verifier queries the local set. ,like If the request already exists or has exceeded the preset expiration time window (e.g., 5 minutes), the request will be rejected. Otherwise, [the request will be processed]. join in (This collection is implemented using a Bloom filter to save memory, recording only the nonce within the last 5 minutes).

[0066] The second step is to verify the VRF commitment. The verifier bases its verification on... and Temporary public key of the derived requester (The derivation method is symmetric with the private key). Then, the VRF verification algorithm is called: However, the verifier was unaware of this at the time. In practice, the verifier does not need to explicitly obtain the fingerprint; instead, it directly performs zero-knowledge proof verification. Therefore, this step is combined with the next step.

[0067] The third step is to verify the zero-knowledge proof. The verifier runs... The output is either 1 or 0. This verification algorithm requires only constant elliptic curve operations and hash calculations, with a time complexity of O(log n). This is far less than the exponential number of attempts required for the requester to generate proof. If the verification output is 0, the verification is considered unsuccessful.

[0068] Step 4 (optional): If the requester provides The verifier records this information and, upon successful verification, sends an acknowledgment message to the requester via a secure channel (such as an established TLS connection). The requester then sends the original [data / data]. The verifier compares the hash value and then executes the actual call. This mechanism ensures the integrity and confidentiality of API calls.

[0069] If all the above verification steps pass, the verifier determines that the requester is an agent with legitimate semantic generation capabilities and generates a semantic credential. The structure of the credential is as follows:

[0070]

[0071] in This indicates the use of a digital signature algorithm with the verifier's private key (e.g., Ed25519, with a signature length of 64 bytes). This is a structured string describing the permissions granted by the credential (e.g., a whitelist of callable APIs, maximum number of sessions, etc.). The credential's validity period... The verification party dynamically sets the load factor based on the current system load: Let the current load factor be... (This ratio reflects the system's workload, ranging from 0 to 1. It is used when the request queue exceeds the maximum processing capacity.) If the validity period is compressed to an extremely short time at this point, then... ,in The base validity period is set at 3600 seconds. Higher loads result in shorter credential validity periods, forcing agents to re-authenticate more frequently, thus dynamically adjusting system load. The verifier will then use the credential... Return the data to the requester, along with the hash value of the credential. Record it in the local ledger (optionally uploaded to the consortium blockchain so that other validators can check whether the credential has been used).

[0072] When the intelligent agent needs to connect to another verification party At that time, simply use the previously obtained credentials. Attached to the new verification request and sent . First, verify the validity of the signature and Check if the credential has expired, and then check if it has been used in the local cache or blockchain (each credential can only be used once). If the verification passes, Directly trusting the agent's identity eliminates the need for semantic proof-of-work; only a lightweight, fast re-authentication is required (e.g., requiring the agent to regenerate an identity similar to the one before the agent's identity is established). The matching short response serves as a liveness check. This mechanism enables trust transfer across authenticators, significantly reducing the overhead of repeated authentication.

[0073] Furthermore, to support high-concurrency scenarios, the verifier can batch aggregate and verify multiple SWUs received within a certain time window. Verifier collection time window. Extract all SWUs within a 100-millisecond timeframe (e.g., 100 milliseconds), and extract the value of each SWU. As leaf nodes, construct a Merkle tree with the root hash as follows: Then, the verifier uses batch zero-knowledge proof verification techniques (such as aggregated BLS signatures or batch Bulletproofs verification) to verify all at once. The total verification time is only slightly longer than the verification time of a single Proof. The verification party will... After signing and broadcasting, any requester participating in the batch can prove to a third party that they have been certified by the verifier using their own leaf path (i.e., Merkel proof from leaf to root), thereby further expanding the scope of trust propagation.

[0074] In summary, this optimized solution integrates semantic proof-of-work, verifiable random functions, zero-knowledge proofs, dynamic steganography, and batch verification into a unified protocol. The requester only needs to construct a single SWU to simultaneously achieve authentication, privacy protection, resistance to pre-computation, and business intent binding; the verifier only needs to perform a lightweight zero-knowledge proof verification once to output a propagable semantic credential. The entire optimized solution is logically consistent with the original S1 to S5 processes—the "issuing semantic challenges" in the original process corresponds to the verifier's broadcast in this solution. and "Generate semantic response" corresponds to the requester's construction It also generates a SWU, where "Lightweight Validation" corresponds to the validator validating the zero-knowledge proof, and "Output Structured Result" corresponds to returning a semantic credential. The two complement each other, together forming a secure, efficient, privacy-friendly, and scalable intelligent agent authentication system.

[0075] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0076] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A trust-based agent authentication method, characterized in that, Includes the following steps: The verification process sends a natural language semantic task to the requesting party as a verification task, which requires the requesting party to generate a natural language text data object that meets preset quality constraints. In response to the verification task, the requesting party generates a first data object and returns it to the verifying party. The generation process of the first data object depends on the semantic generation capability claimed by the requesting party, and the computing resources required to generate the first data object are greater than a first threshold. The verifier receives the first data object and verifies the first data object with computing resources below the first threshold to determine whether it meets the preset quality constraints. If the verification passes, the requester is determined to be an intelligent agent with the ability to generate legitimate semantics.

2. The method according to claim 1, characterized in that, The verification task is natural language semantic question answering, and the preset quality constraints include: the semantic relevance between the response content and the question and answer topic is greater than a second threshold, the length of the response text is greater than a third threshold, and the response text has semantic coherence and logical integrity.

3. The method according to claim 1, characterized in that, The verification task includes a one-time random identifier, and the preset quality constraint also requires that the first data object contains the one-time random identifier; The verifier also checks the validity and uniqueness of the one-time random identifier during verification. If it is invalid or has been used, the verification is deemed to have failed.

4. The method according to claim 1, characterized in that, The steps for the verifier to verify the first data object include: The semantic relevance between the first data object and the verification task is verified, and a semantic similarity score is calculated. The text length of the first data object is validated to determine whether it reaches the preset length threshold. Verify the semantic coherence and logical integrity of the first data object; If all three of the above checks meet the corresponding conditions, the verification is deemed successful; otherwise, the verification is deemed unsuccessful.

5. The method according to claim 1, characterized in that, The first threshold represents the minimum amount of computing resources required to generate the first data object, and the first threshold is positively correlated with the preset length threshold of the first data object. The verification party verifies that the ratio between the computational resources required and the first threshold is less than the preset asymmetric ratio threshold.

6. The method according to claim 1, characterized in that, The verification task also includes constraint information of business call intent. In addition to the verification response content, the first data object generated by the requester also includes business API call information embedded according to predefined rules. After successful verification, the verifier extracts the business API call information from the first data object and executes the business call.

7. The method according to claim 2, characterized in that, The steps for verifying the natural language semantic question answering sent to the requesting party include: The verifier generates a natural language question containing a random topic and constraints. The random topic is dynamically selected from a predefined topic pool, and the constraints include response length requirements, response format requirements, or keywords that must be included in the response.

8. The method according to claim 1, characterized in that, After completing the verification, the verifier only outputs a structured result in a predefined format, without performing any natural language generation or responding to any instruction extensions carried in the response.

9. The method according to any one of claims 1, 2, 4, and 5, characterized in that, After the verifier completes the verification of the requester, it establishes a trusted communication session with the requester or grants the requester permission to access the predetermined resources. The verification process is executed independently before each communication session is established, and the verification results between different sessions cannot be reused.

10. The method according to claim 6, characterized in that, The steps by which the verifier extracts business API call information from the first data object include: According to the semantic steganography rules agreed upon with the requester in advance, the API interface name and call parameters are parsed from the natural language text of the first data object, and the parsing results are assembled into structured call instructions. After the verifier executes the structured call instruction, it outputs a structured result in a fixed format.

Images