An agent identity authentication method and device based on reasoning classification

Abstract

The specification provides an agent identity authentication method and device based on reasoning classification. The method comprises: obtaining reasoning process data generated by an agent in the process of performing a current task; determining a reasoning step contained in the reasoning process data and labeling the type of the reasoning step; matching a role type signature with the labeled reasoning step type to verify the compliance of the reasoning step type; and determining an identity authentication result for the agent according to the result of the compliance verification.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of terminal technology, and in particular to an Agent identity authentication method and apparatus based on reasoning classification. Background Technology

[0002] With the development of Artificial Intelligence (AI) technology, agents have been gradually applied to scenarios such as automated office work, intelligent customer service, industrial control, network operation and maintenance, digital employees, and multi-agent collaboration. Agents typically possess the ability to continuously execute tasks, access external resources, invoke application programming interfaces (APIs), and participate in cross-system collaborative processes. Therefore, effectively verifying the identity of agents to ensure that the agents currently participating in task execution are indeed legitimate and trustworthy target agents has become a key issue in ensuring the operational security of intelligent systems, the reliability of task execution, and the controllability of collaborative links.

[0003] However, most current agent identity verification methods use static authentication, which completes authentication once during the login or access phase and assumes that the subject's identity remains unchanged during subsequent operation. Since this authentication method is difficult to reflect the true identity status during operation in a timely manner, once authentication credentials are misused, sessions are hijacked, or the executing subject is replaced, unauthorized operations can easily continue to occur, seriously affecting the security and reliability of the agent execution process. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, an Agent authentication method based on reasoning classification is proposed, wherein a role type signature of the Agent is pre-registered, the role type signature including at least the types of reasoning steps that the Agent is allowed to perform and the types of reasoning steps that the Agent is prohibited from performing, the method comprising: Obtain the inference process data generated by the Agent during the execution of the current task; Identify the reasoning steps contained in the reasoning process data and label the types of the reasoning steps; The role type signature is matched with the labeled reasoning step type to verify the compliance of the reasoning step type; Based on the results of the compliance verification, the identity authentication result for the Agent is determined.

[0005] According to a second aspect of one or more embodiments of this specification, an agent identity authentication device based on reasoning classification is provided, comprising: The registration module is used to pre-register the role type signature of the Agent, wherein the role type signature includes at least the types of inference steps that the Agent is allowed to execute and the types of inference steps that the Agent is prohibited from executing; The acquisition module is used to acquire the reasoning process data generated by the Agent during the execution of the current task; The annotation module is used to determine the reasoning steps contained in the reasoning process data and to annotate the type of the reasoning steps; The matching module is used to match the role type signature with the labeled reasoning step type in order to verify the compliance of the reasoning step type. The authentication module is used to determine the identity authentication result for the Agent based on the result of the compliance verification.

[0006] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the steps of the method described above by executing the executable instructions.

[0007] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method described above.

[0008] According to a fifth aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0009] As described in the above embodiments, this specification pre-registers the role type signature of the Agent, obtains the inference process data generated by the Agent for the current task during Agent operation, determines the inference steps contained in the inference process data and marks the types of the inference steps, performs compliance verification on the marked inference step types based on the role type signature, and determines the identity authentication result for the Agent based on the compliance verification result. Compared with existing static authentication methods, this application can combine the matching relationship between the inference step types of the Agent during operation and the pre-registered role type signature to dynamically verify the Agent's identity, thereby improving the ability to identify identity anomalies during operation, reducing the risk of unauthorized operations continuing to occur, and improving the security and reliability of the intelligent system operation. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of the architecture of an Agent identity authentication service system provided in an exemplary embodiment; Figure 2 This is a schematic diagram of a process for an Agent identity authentication method based on reasoning classification, provided in an exemplary embodiment; Figure 3 This is a schematic diagram of a detection result for a reasoning step type provided in an exemplary embodiment; Figure 4 This is a schematic diagram of the detection results of reasoning ability stability provided in an exemplary embodiment; Figure 5 This is a schematic diagram of the detection results for cross-session inference type distribution consistency provided in an exemplary embodiment; Figure 6 This is an exemplary embodiment providing an overall flowchart of Agent identity authentication; Figure 7 This is a schematic diagram of the structure of a device provided in an exemplary embodiment; Figure 8 This is a block diagram of an Agent identity authentication device based on reasoning classification, provided in an exemplary embodiment. Detailed Implementation

[0011] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0012] As large-model-based agents are increasingly applied to scenarios such as automated office work, intelligent customer service, intelligent operation and maintenance, risk control, and multi-agent collaboration, these agents typically need to access external application programming interfaces (APIs), invoke tools, perform multi-step inference, and output decision results during operation. For these intelligent agents that continuously perform tasks, completing only a static identity verification during the access phase is insufficient to cover identity security issues during runtime.

[0013] In existing technologies, common authentication methods mainly rely on access tokens, credential signing, decentralized identity identifiers, or session-level authorization information. These solutions can answer the question "Does the current subject possess legitimate credentials?", but they struggle to answer "Does the current action still originate from the claimed Agent?". When authentication credentials are stolen, sessions are hijacked, prompts are maliciously injected, or the executing entity is replaced during operation, attackers may still continue to perform abnormal operations while possessing legitimate credentials, and the system may not be able to identify this in a timely manner.

[0014] Furthermore, existing model identification or model fingerprinting technologies focus more on identifying the underlying model type or version, typically targeting model-level entities rather than specific Agent instances. Even if a model type can be identified, it's difficult to distinguish different Agents deployed on the same model, let alone continuously determine whether an Agent has been replaced or hijacked during task execution. Therefore, these solutions cannot meet the requirements for Agent instance-level, runtime, and persistent identity authentication.

[0015] Meanwhile, anomaly detection methods based solely on fixed thresholds suffer from insufficient adaptability. Agents typically exhibit varying levels of behavioral fluctuation when performing tasks of different complexities. For complex tasks, with more inference steps, more frequent tool switching, and longer response times, using a uniform static threshold can easily misclassify normal fluctuations as anomalies. Conversely, for simple tasks, setting the threshold too wide may overlook genuine identity-related abnormal behaviors, leading to decreased authentication accuracy.

[0016] Based on this, this specification provides an Agent identity authentication method based on reasoning classification. This method pre-registers the Agent's role type signature, acquires reasoning process data during the Agent's current task execution, identifies the reasoning steps contained in the reasoning process data and labels the types of these reasoning steps, then performs compliance verification on the labeled reasoning step types based on the role type signature, and determines the identity authentication result for the Agent based on the compliance verification result.

[0017] Compared to authentication methods that rely solely on static credentials, this scheme extends identity authentication from the access phase to the runtime phase. By dynamically verifying the consistency between the Agent's actual reasoning behavior and its pre-registered role constraints, it can identify abnormal situations such as unauthorized reasoning, injection-based reasoning, and subject replacement earlier, thereby improving the accuracy and continuity of runtime identity authentication.

[0018] To facilitate understanding of the technical solutions in this specification, some key concepts involved in this specification are explained below.

[0019] Agent: An intelligent agent possessing the capabilities of task understanding, step planning, inference execution, tool invocation, result generation, or collaborative orchestration. This agent can be driven by a single large model or a composite agent composed of a rule engine, retrieval module, tool invocation module, and a large model working together. Different agents can assume different business roles, such as customer service agents, financial analysis agents, system maintenance agents, or knowledge retrieval agents.

[0020] Role type signature: Used to characterize the constraint information of a specific Agent role at the inference level. A role type signature includes at least the types of inference steps that the Agent is allowed to execute and the types of inference steps that the Agent is prohibited from executing. In some embodiments, the role type signature may also include prohibited type conversion relationships, core inference step types, inference capability boundary parameters, and stability reference information related to historical sessions. The role type signature can be understood as a constraint template for runtime inference behavior.

[0021] Inference process data: Inference-related data generated, retained, transmitted back, or observable by the agent around the current task. This data can be explicit step-by-step description text, internal intermediate results, structured inference trajectories, explanatory text before and after tool calls, plan trees, Chain of Thought (CoT) fragments, action logs, or other content that can characterize the inference process. The specific carrier of inference process data can be text, JSON objects, log records, or graph structure data.

[0022] Reasoning Step: The smallest or second-smallest granularity reasoning unit parsed from the reasoning process data. One reasoning step can correspond to a query, analysis, judgment, calculation, planning, response generation, risk assessment, transaction execution decision, or system management decision. In different embodiments, the granularity of the reasoning steps can be adjusted according to business needs, such as by sentence level, action level, tool call level, or stage level.

[0023] Reasoning Step Type: A category identifier obtained by classifying reasoning steps. In one embodiment, the reasoning step type may include information query, analysis, response generation, financial risk assessment, transaction execution, system management, etc. In other embodiments, it can be further subdivided into rule matching, evidence integration, result confirmation, permission judgment, strategy execution, etc. The reasoning step type is used to characterize which role's capability category the reasoning behavior belongs to.

[0024] Compliance verification: The process of constraining and verifying the inference step type based on the role type signature. This process may include verifying whether a single inference step type belongs to the allowed type set, whether it falls into the prohibited type set, whether there is a prohibited type conversion relationship between adjacent inference steps, and whether the inference step sequence covers the core inference step type, etc.

[0025] Reasoning ability stability: This describes whether the reasoning ability exhibited by an agent in the current task is consistent with the pre-defined capability boundaries set for that agent. For example, if an agent with only basic question-answering capabilities suddenly exhibits complex transaction modeling or high-order strategy planning capabilities in the current session, there may be issues of agent substitution or capability overreach.

[0026] Cross-session inference type distribution consistency, as described in this specification, refers to whether the distribution of inference types exhibited by the same agent remains relatively stable across multiple historical sessions. For example, an agent that performs customer service tasks for a long time will typically have a high proportion of query, analysis, and response inferences. If a large number of financial assessment or system management inferences suddenly increase in a particular session, it may indicate that the agent has been hijacked or that the current inference behavior is inconsistent with its claimed identity.

[0027] The technical solutions described in the embodiments of this specification will be explained below with reference to the accompanying drawings: Figure 1 This is a schematic diagram of the architecture of an Agent identity authentication service system provided in an exemplary embodiment. For example... Figure 1 As shown, the system may include a server 11, a network 12, and several electronic devices, such as a personal computer (PC) 13, a mobile phone 14, etc.

[0028] Server 11 can be a physical server containing an independent host, or it can be a virtual server hosted in a host cluster. During operation, server 11 can run server-side programs for a certain application to implement the relevant functions of that application. For example, when server 11 runs an Agent authentication service program, it can function as a corresponding Agent authentication service platform.

[0029] PC13 and mobile phone14 are just some of the types of electronic devices that users can use. In reality, users can obviously also use electronic devices such as tablets, laptops, PDAs (Personal Digital Assistants), wearable devices (such as smart glasses, smartwatches, etc.), etc., and one or more embodiments in this specification do not limit this. During operation, the electronic device can run a client-side program of an application to implement the relevant functions of that application. For example, when the electronic device runs an Agent authentication service program, it can act as a client for that Agent authentication service. The aforementioned Agent authentication service client application can be launched and run on the electronic device. This client-side program can be a native application installed on the electronic device, or it can be a mini-program, quick app, or other similar form. Of course, when using web technologies such as HTML5 or similar, the relevant functions can be implemented through a page displayed by a browser. This browser can be a standalone browser application or a browser module embedded in some applications.

[0030] As for the network 12 that enables interaction between electronic devices such as PC13 and mobile phone 14 and server 11, communication can be achieved using either wired or wireless networks, depending on the communication methods supported by the respective electronic devices. This specification does not impose any restrictions on this. For example, PC13 can support both wired and wireless communication, so it can use either wired or wireless networks as needed. Mobile phone 14 typically only supports wireless communication, so it can use a wireless network for communication.

[0031] In this specification, the entity executing the Agent authentication method can be a server, client, task management program, or collaboration control program running the Agent; it can also be a dedicated Agent or other electronic device for authentication. For ease of description, the following will use a server as the executing entity to illustrate the Agent authentication method provided in this specification.

[0032] Figure 2 This is a flowchart illustrating an agent authentication method based on reasoning classification, provided in an exemplary embodiment, including the following steps: S200: Obtain the inference process data generated by the Agent during the execution of the current task.

[0033] Before the Agent performs the actual inference task, the server can pre-register the Agent's role type signature. This registration process can be used as a pre-access initialization process or as a deployment configuration process.

[0034] The server can obtain the identity credentials declared by the Agent, configure the role type signature corresponding to the Agent, and then bind and store the identity credentials with the configured role type signature.

[0035] In this specification, identity credentials can be tokens, keys, certificates, identifier strings, or other information used to identify the Agent's identity. Role type signatures can be configured by the system administrator or automatically generated by the policy engine based on role templates.

[0036] For example, a role type signature can be represented as ,in, This represents the set of inference steps that the Agent is allowed to perform. This represents the set of inference step types that are prohibited from being executed by the Agent, and Σ represents the sequence of allowed inference step type conversions.

[0037] For example, the role type signature corresponding to a customer service agent can be: The role type signature for a financial analysis agent can be: Through this pre-registration process, the server can perform constraint verification on the collected reasoning behavior based on the bound role type signature.

[0038] For any Agent, when the Agent performs an actual inference task, the server can first perform initial authentication to determine whether the Agent has the permission to execute the current task. Authentication methods include, but are not limited to, authentication based on access credentials, authentication based on digital certificates, authentication based on tokens, or authentication based on keys. After the initial authentication is successful, the Agent is authorized to execute the current task. The server can perform continuous authentication on the Agent based on the test behavior data of the Agent during the task execution process.

[0039] There are several possible times when to perform continuous authentication on the Agent. For example, the server can perform continuous authentication periodically at preset time intervals. For instance, it can check the inference process data generated by the Agent within the current time window every 5 seconds, 10 seconds, 30 seconds, or other preset durations. Alternatively, the server can immediately trigger continuous authentication whenever a new inference step is detected, in order to perform more granular real-time verification of the Agent's inference behavior. Yet another example is that the server can perform continuous authentication after accumulating N inference steps, where N can be 2, 3, 5, 10, or other preset numbers, thereby balancing detection accuracy and processing overhead.

[0040] In practical applications, servers can obtain inference process data from multiple sources, including: The agent proactively reports data from the reasoning process. For example, when executing a task, the agent sends its internal plan, step descriptions, explanations before and after tool calls, and interim conclusions to the server in a streaming or batch manner. The server collects inference process data. For example, the server obtains inference trajectories related to the current task from log systems, task orchestration systems, gateway-side forwarding records, model intermediate output caches, or tool call monitoring modules. Hybrid data collection means that the agent actively uploads some inference data, and the server then supplements it with other related data from the task execution environment.

[0041] For example, when the current task is a user consultation task, the inference process data may include: first retrieving the user's historical questions, then analyzing the intent of the current question, and finally generating a draft response and confirming the reply. In this case, the inference process data may include: first querying basic market data, then conducting a risk assessment, and finally calculating the recommended position and generating an analysis conclusion.

[0042] For example, when the current task is a system operation and maintenance task, the inference process data may include: first querying the system status, then analyzing abnormal indicators, and then executing restart suggestions or permission confirmation steps.

[0043] The data format of the reasoning process may differ in different task scenarios, but all can be used to reconstruct the actual reasoning behavior of the Agent in the current task.

[0044] S202: Determine the reasoning steps contained in the reasoning process data and label the types of reasoning steps.

[0045] After the server obtains the reasoning process data, it can first parse out multiple reasoning steps from the reasoning process data.

[0046] In practical applications, there are several ways to determine the reasoning steps, including but not limited to: The inference steps are determined based on preset segmentation rules. For example, the inference process data can be divided into multiple step units based on line breaks, stage identifiers, action prefixes, bullet points, or tool call boundaries. If a segment of inference process data includes three parts: "querying user order information," "analyzing order status," and "generating response suggestions," the server can identify these three parts as three inference steps.

[0047] The semantic segmentation model determines the reasoning steps. The server can input the reasoning process data into the semantic segmentation model, which identifies the step boundaries, thus avoiding inaccurate segmentation caused by relying solely on text format. For example, even if a step does not have a line break, but its semantic meaning has shifted from "retrieving information" to "performing a risk assessment," the semantic segmentation model can still divide it into two independent reasoning steps.

[0048] Combining tool call logs, external resource access records, or task orchestration action nodes can help determine the inference steps. For example, a database retrieval call corresponds to information query inference, a scoring model call corresponds to analysis or risk assessment inference, and an external execution instruction corresponds to transaction execution or system management inference. By jointly parsing text and behavioral records, the completeness of inference step identification can be improved.

[0049] After determining the inference steps, the server needs to label the type of each inference step. This labeling process can use rule-based methods, classification models, or a combination of both.

[0050] The server can first determine whether the description text corresponding to the reasoning step matches the preset keywords. If it does, the type of the reasoning step is determined based on the preset mapping relationship between the keywords and the reasoning step types.

[0051] For example, when the descriptive text contains keywords such as "query," "retrieve," or "read," it can be identified as an information query-type reasoning step. When keywords such as "analysis," "evaluation," and "judgment" are included, it can be identified as an analytical reasoning step type. When keywords such as "reply," "answer," or "generate suggestions" are included, it can be identified as a response-based reasoning step type. When keywords such as "transaction," "transfer," and "place order" are included, it can be identified as a transaction execution-type reasoning step. When keywords such as "risk control," "risk exposure," and "probability of default" are included, it can be identified as a reasoning step type related to financial risk assessment. When keywords such as "authorize," "restart," and "modify configuration" are included, it can be identified as a system management-related reasoning step type. .

[0052] If the description text corresponding to the reasoning step does not match the preset keywords, it means that the description text does not explicitly contain keyword information that can directly represent the type of reasoning step. The server can input the description text into the preset classifier to determine the type of reasoning step through the classifier.

[0053] The classifier can be a lightweight text classification model, a classification model fine-tuned from a pre-trained language model, a matching model based on vector similarity, or a hybrid classifier composed of a rule engine and a statistical model. For example, for a descriptive text that "infers the risk of escalation of complaints based on customer interaction records over the past seven days," if standard keywords do not appear directly, the classifier can still label it as an analysis-type or risk assessment-type reasoning step based on the contextual semantics.

[0054] Furthermore, the server can fuse the rule matching results with the classifier output to improve annotation accuracy. For example, when the rule matching result matches the classifier result, the type is directly output; when they do not match, the final type can be determined based on confidence level, priority, or review strategy. In some embodiments, a first candidate type and a second candidate type can also be output, and a stricter strategy or a manual review strategy can be adopted in subsequent compliance verification.

[0055] In some complex task scenarios, the reasoning steps may have multiple labeled attributes. For example, the description "first retrieve user asset information, then determine whether the risk threshold is met based on this information" includes both query and risk assessment components. The server can choose any of the following implementation methods for this: This composite step is further broken down into two finer-grained inference steps and labeled separately; Label the primary and secondary types for this step; It can be directly labeled as a composite type, and the constraint rules for composite types can be pre-configured in the role type signature. Different implementation methods can be selected according to the system's requirements for accuracy, performance, and complexity.

[0056] S204: Match the role type signature with the labeled reasoning step type to verify the compliance of that reasoning step type.

[0057] In this embodiment, the server can obtain the role type signature corresponding to the Agent from the registered binding relationship, and perform compliance verification on the labeled inference step type based on the role type signature.

[0058] Specifically, the server can determine whether a labeled inference step type belongs to the inference step types allowed for the Agent to execute, and whether the inference step type belongs to the inference step types prohibited for the Agent to execute. If an inference step type belongs to the allowed type set, it can be determined that the inference step type has passed the basic compliance verification; if an inference step type belongs to the prohibited type set, it can be determined that the inference step type has failed the compliance verification.

[0059] For example, for a customer service agent, their role type signature allows information query, analysis, and response-type inference steps, while prohibiting financial risk assessment, transaction execution, and system management inference steps. If the server identifies the inference steps in the current task as "querying order information," "analyzing user issues," and "generating response suggestions," these inference step types all belong to the allowed type set and can continue to pass subsequent verification. If the server further identifies a certain inference step as "calculating transaction execution plans" or "assessing asset allocation risks," then this inference step type belongs to the prohibited type set, and the server can directly mark the agent as failing this compliance verification.

[0060] In practical applications, there may be situations where a certain inference step type belongs to neither the allowed type set nor the prohibited type set. This can be understood as an undefined type or a type awaiting confirmation. For example, a newly emerging inference step type may not be covered by the current role template, or the classifier may output a new category that has not yet been registered in the role type signature. In such cases, the server can determine that the Agent is in an unconfirmed state and trigger secondary authentication for that Agent.

[0061] Two-factor authentication can employ methods such as certificate re-verification, token re-issuance, challenge response, manual review, additional security checks, or increased sampling frequency. By setting a pending status, it avoids treating all unknown types as violations, thus achieving a balance between security and adaptability.

[0062] In addition, the character type signature may include prohibited type conversion relations, which are used to characterize the sequential connection relationships that are not allowed between the same reasoning step types.

[0063] When performing compliance verification on the marked inference step types, the server can determine whether a prohibited type conversion relationship exists between the types of two adjacent inference steps. If such a relationship exists, it can be determined that the inference step type has failed the compliance verification.

[0064] For example, for a given role, although both information query and response reasoning steps belong to the allowed type set, the system can further require that its reasoning path should follow the basic order of "query first, then analyze, then respond." If the server detects that adjacent reasoning step types jump directly from "response type" to "transaction execution type," or from "query type" to "system management type," then this type conversion relationship may be prohibited. Similarly, for a customer service agent, it can be pre-configured to prohibit direct conversion from "query type" to "transaction execution type," because this would mean the agent directly provides transaction action suggestions without going through the authorized analysis chain. By introducing prohibited type conversion relationships, the server can not only check whether a single step has exceeded its limits, but also check whether the entire reasoning chain is structurally abnormal.

[0065] Additionally, the types of inference steps allowed for an agent to execute can include at least one core inference step type. During compliance verification, the server can determine whether the labeled inference step types include this core inference step type. If not, it can be determined that the inference step type has failed compliance verification.

[0066] For example, for a customer service agent, information query and response steps might be core inference step types. If a task's inference steps only include analysis and other auxiliary steps, but completely lack query or response steps, it may indicate that the current inference chain is incomplete, or that the inference process has been truncated, replaced, or injected with irrelevant steps. Similarly, for a financial analysis agent, financial risk assessment steps might be core inference step types. If a risk assessment step is completely absent from an inference chain claiming to generate investment advice, the inference process may not conform to the expected behavior pattern of this role. By checking the coverage of core inference step types, the server can further identify situations where prohibited types are not apparent on the surface, but the actual structure is abnormal or key capability steps are missing.

[0067] In one embodiment provided in this specification, the server may first perform prohibited type verification, then prohibited conversion verification, and finally core type coverage verification. If a prohibited type is found, the verification can be directly considered a failure, thereby reducing subsequent computational overhead.

[0068] In another embodiment provided in this specification, all verification results can be generated uniformly first, and then these results can be input into the decision module, which will then output the final compliance verification result.

[0069] In practical applications, the server can choose one or more of the above compliance verification methods to perform compliance verification; when only one compliance verification method is performed, the allowed type and prohibited type verification shall be given priority.

[0070] S206: Based on the results of the compliance verification, determine the identity authentication result for the Agent.

[0071] In the basic implementation, the server can directly determine the identity authentication result based on the compliance verification result.

[0072] Figure 3 This is a schematic diagram of the detection result of a reasoning step type provided in an exemplary embodiment.

[0073] If the marked inference step type passes the compliance verification, the identity authentication result for that Agent is determined to be successful; if the marked inference step type fails the compliance verification, the identity authentication result is determined to be rejected; if the Agent is in a pending confirmation state, the identity authentication result is determined to be pending secondary authentication or pending manual confirmation.

[0074] For example, for an Agent registered as a customer service role, if all reasoning steps in the current task belong to the query, analysis, and response categories, and no prohibited conversion relationships appear, while covering the core reasoning step types, the server can determine its authentication result as passed. If the Agent encounters a transaction execution reasoning step during the reasoning process, its authentication result can be directly determined as rejected. If a step of the Agent is marked as a new type not defined in the current role template, the server can determine its authentication result as pending confirmation and further trigger a secondary authentication process.

[0075] In some embodiments, the server can also combine the inference capability stability test results and the cross-session inference type distribution consistency test results to jointly determine the identity authentication result for the Agent. In this case, identity authentication no longer relies solely on compliance verification in a single session, but introduces two supplementary dimensions: operational capability boundaries and historical stability.

[0076] Specifically, the server can detect the stability of the Agent's reasoning ability. This detection may include: evaluating the Agent's current reasoning ability for the labeled reasoning step type to obtain the Agent's real-time reasoning ability score; if the real-time reasoning ability score does not exceed the reasoning ability boundary set in advance for the Agent, then the Agent is determined to have passed the reasoning ability stability detection; otherwise, the Agent is determined to have failed the reasoning ability stability detection.

[0077] In practical applications, the reasoning capability boundary can be pre-established during the registration phase. The server can use exploratory tasks to calibrate the agent's reasoning capabilities across multiple domains and form a capability boundary declaration B for that agent. This capability boundary declaration B can be expressed as: in, Indicates the first Each area of ​​competence This represents the agent's baseline reasoning ability score in this capability domain.

[0078] For example, for a customer service agent, the server can probe it based on customer service question-and-answer tasks, basic query tasks, financial analysis tasks, and system management tasks, and form the following capability boundary declaration: B = {(Customer Service, 0.9), (Query, 0.85), (Finance, 0.1), (System Management, 0.05)} This indicates that the customer service agent possesses high reasoning ability in the customer service and inquiry fields, but only low ability or should not possess such ability in the financial and system management fields.

[0079] During runtime, the server can evaluate the agent's inference performance in the current task and generate a real-time capability score B′. This real-time capability score B′ can be represented as: in, This indicates that the Agent is in the current task at the [number]th [period]. Real-time reasoning ability scores in each ability domain.

[0080] In practical implementation, the server can evaluate real-time inference capabilities based on multiple dimensions. For example, it can determine the real-time inference capability score for each capability domain based on at least one of the following: step completion quality, inference depth, answer complexity, domain terminology usage level, task solution success rate, and standard sample test results. The final score can be generated using weighted summation, normalized scoring, or model scoring methods for different dimensions. .

[0081] Building upon this, the server can also perform capability-identity consistency verification. Specifically, the server can calculate capability deviations. The calculation method can be expressed as: in, Indicates the first The deviation tolerance threshold corresponding to each capability domain is used to allow the Agent to have a certain degree of capability change within the normal fluctuation range.

[0082] like If the preset capability deviation threshold is not exceeded, then the agent can be determined to have passed the inference capability stability test; if... If the deviation exceeds the preset threshold, it can be determined that the Agent has failed the test of reasoning ability stability.

[0083] For example, if a customer service agent's baseline reasoning ability score in the financial domain is 0.1 during the registration phase, but their real-time reasoning ability score in the financial domain rises to 0.75 in the current task, this will result in a significant ability discrepancy in the financial domain, leading to... Significantly increased. In this case, the server may consider that the Agent has exhibited abnormally high reasoning ability outside the declared capability boundaries, and that the stability of its reasoning ability is abnormal. This may indicate model replacement, capability overreach, or subject tampering.

[0084] Figure 4 This is a schematic diagram illustrating the detection results of reasoning ability stability as provided in an exemplary embodiment.

[0085] like Figure 4 As shown, in the customer service and query domains, the agent's actual capabilities are close to the declared limits, indicating that the agent's reasoning performance in these capability domains is within the normal fluctuation range. However, in the financial and operations domains, the agent's actual capabilities are significantly higher than the declared limits, indicating that the agent has exhibited abnormally enhanced reasoning performance in domains where it originally had low or limited capabilities.

[0086] Furthermore, the server can also detect the consistency of the cross-session inference type distribution of the Agent. This detection may include: determining the number of inference steps belonging to each inference step type in the current session, and determining the inference type distribution corresponding to the current session based on the number; obtaining the historical inference type distribution corresponding to historical sessions; calculating the distribution deviation between the inference type distribution corresponding to the current session and the historical inference type distribution; if the distribution deviation does not exceed a preset deviation threshold, the Agent is determined to have passed the cross-session inference type distribution consistency detection; otherwise, the Agent is determined to have failed the cross-session inference type distribution consistency detection.

[0087] The server can type-label the inference steps of the same agent in each session and extract the inference type distribution corresponding to that session. This type of reasoning distribution It can be represented as: in, Indicates the first Types of reasoning steps This indicates the number or percentage of this inference step type in the current session.

[0088] For example, the distribution of inference types corresponding to the current session can include: the proportion of query steps, the proportion of analysis steps, the proportion of response steps, the proportion of financial risk assessment steps, and the proportion of transaction execution steps. The distribution of historical inference types corresponding to historical sessions can be the mean distribution of the most recent sessions, or a baseline distribution continuously maintained through a sliding window.

[0089] Based on this, the server can calculate the distribution deviation between the inference type distribution corresponding to the current session and the inference type distribution corresponding to historical sessions. In one embodiment, the server can use Jensen-Shannon divergence as a measure of distribution deviation. Specifically, for the k-th session and the (k+1)-th session, the server can calculate: in, This represents the distribution of reasoning types corresponding to the k-th session. This represents the distribution of reasoning types corresponding to the (k+1)th session. This indicates the deviation in the distribution of reasoning types between the two sessions.

[0090] Of course, in other embodiments, the server may also use KL divergence, Euclidean distance, cosine distance or other statistical distribution difference measures to calculate the distribution deviation, and this specification does not limit this.

[0091] Under normal circumstances, the distribution of inference types for the same agent across different sessions usually remains relatively stable, therefore Generally at a low level. If If the deviation threshold is not exceeded, the server can determine that the Agent has passed the cross-session inference type distribution consistency detection; if If the deviation exceeds the preset threshold, the server can determine that the Agent has failed the cross-session inference type distribution consistency test.

[0092] Furthermore, the server can also... Cases exceeding a preset deviation threshold are identified as potential session hijacking or role anomaly events. This is because when an Agent is hijacked, replaced, or injected with unauthorized inference logic, its inference type distribution often undergoes abrupt changes, leading to a significant increase in cross-session distribution deviation.

[0093] For example, an agent that has long been responsible for customer service might have a high proportion of query and response reasoning steps in its historical sessions, while financial risk assessment reasoning steps are close to zero. If, in the current session, this agent suddenly exhibits a large number of financial risk assessment reasoning steps, or a significant increase in the proportion of transaction execution reasoning steps, the discrepancy between the reasoning type distribution in the current session and that in historical sessions will widen significantly, leading to… A significant increase. In this situation, the server can trigger a cross-session consistency anomaly check and use the result as one of the bases for determining subsequent authentication results.

[0094] Figure 5 This is a schematic diagram of the detection results of cross-session inference type distribution consistency provided by an exemplary embodiment.

[0095] like Figure 5 As shown, under normal conditions, the consistency index value of this agent in each session from S1 to S5 remains at a high level with small fluctuations, indicating that the overall distribution of the inference type of this agent in multiple sessions remains stable and its cross-session inference mode has strong consistency.

[0096] In the hijacked state, the agent's consistency metrics were close to those in the normal state in the first two sessions. However, starting from S3, the consistency metrics dropped significantly and remained below the preset consistency detection threshold. This indicates that in subsequent sessions, the agent's inference type distribution shifted significantly compared to historical sessions, exhibiting a sudden change.

[0097] Figure 6 This is an exemplary embodiment of the overall flowchart of Agent identity authentication.

[0098] like Figure 6As shown, after completing the inference step type annotation, the server can perform type compliance checks, inference capability stability checks, and inference type distribution consistency checks, respectively. The type compliance check can further include allowed / prohibited type checks, type conversion relationship checks, and core inference step checks to determine whether the current inference step type conforms to the type constraints of the Agent's corresponding role. The inference capability stability check determines whether the Agent's real-time inference capability in the current task exceeds a pre-defined inference capability boundary. The inference type distribution consistency check determines whether the inference type distribution in the Agent's current session is consistent with historical sessions. Role type signatures can be used as type constraint inputs to the above checks, especially to support type compliance verification after inference step type annotation. Subsequently, the server summarizes the type compliance check results, inference capability stability check results, and inference type distribution consistency check results, and enters the comprehensive decision-making stage.

[0099] Furthermore, the server can employ multiple strategies during comprehensive decision-making. In one embodiment, if compliance verification passes, inference capability stability detection passes, and cross-session inference type distribution consistency detection passes, the authentication result is determined to be successful. If there are pending confirmation items in the compliance verification, or a slight anomaly in inference capability stability, or a slight deviation in cross-session consistency, the authentication result is determined to be secondary authentication. If compliance verification fails, or inference capability stability is severely abnormal, or the cross-session consistency deviation exceeds a high-risk threshold, the authentication result is determined to be rejected, and further actions may include interrupting task execution, restricting tool calls, freezing the session, or triggering a security alert.

[0100] To further illustrate how this method is applied, several exemplary scenarios are given below.

[0101] In an intelligent customer service scenario, a customer service agent declares their role as solely responsible for querying orders, analyzing frequently asked questions, and generating customer responses. When executing these tasks, the server obtains the following reasoning steps: "Query user order status," "Analyze the reasons for order anomalies," "Assess whether to recommend asset rebalancing to the user," and "Generate customer response." The first two steps and the last step can be labeled as query, analysis, and response types, respectively, while the third step can be labeled as a financial risk assessment type. Since financial risk assessment is a prohibited type for customer service agents, the server can determine that the agent has failed compliance verification and will issue a rejection for identity authentication.

[0102] In an enterprise knowledge assistant scenario, the allowed types for a knowledge retrieval agent primarily include query and response types, while the prohibited types include system management types. The server detects that the agent's reasoning steps in a certain task are "retrieving documents," "summarizing key content," "modifying server configuration suggestions," and "outputting a response." Among these, "modifying server configuration suggestions" can be categorized as a system management reasoning step. Although the agent still generates an external response similar to a knowledge question answer, the server can still determine that its identity is inconsistent because a system management step, which is not permitted for its role, has appeared in the reasoning chain.

[0103] In a multi-session monitoring scenario, a customer service agent primarily engages in query, analysis, and response-related tasks in most historical sessions. However, the current session exhibits a significant number of transaction execution and financial risk assessment reasoning steps. Furthermore, the agent's real-time reasoning ability score for complex financial analysis tasks clearly exceeds the preset capability boundaries. Even if not all prohibited rules are directly triggered in a single step, the server can still determine that the current entity poses a high risk based on capability boundary detection and cross-session consistency detection results, and thus determine the authentication result as rejection or mandatory secondary authentication.

[0104] Optionally, in addition to authenticating the Agent based on the above methods, the Agent's behavioral characteristics can also be referenced during the continuous authentication process.

[0105] Specifically, the server can pre-extract features from the historical behavioral data generated by the Agent under normal working conditions to determine the baseline behavioral features corresponding to the Agent.

[0106] In actual operation, the server can collect the behavioral data to be tested from the Agent runtime framework, call gateway, tool executor, logging system, or task orchestration system. The behavioral data to be tested can be structured logs, event streams, message records, API call records, inference process records, or timestamp sequences, etc.

[0107] The server can extract features from the behavioral data to be tested to obtain real-time behavioral features. In order to improve the ability to characterize different types of behavioral patterns, in some embodiments, the server can extract features from the behavioral data to be tested from multiple dimensions, and then concatenate the extracted features from each dimension to obtain real-time behavioral features; wherein, the behavioral data to be tested from multiple dimensions may include one or more of the following: API call data, tool usage data, inference chain data, and time distribution data of the output decision process.

[0108] For API call data, the server can construct sequence features based on information such as API endpoint identifier, call order, call interval, parameter type and return status, and extract API call features using a sequence coding model.

[0109] Baseline behavioral features and real-time behavioral features can be obtained by feature extraction from a pre-trained feature extraction model.

[0110] In some embodiments, the feature extraction model can be trained in the following manner: the server acquires sample behavior data of the Agent; the sample behavior data is segmented according to a preset time window to obtain each sample behavior segment; each sample behavior segment is input into the feature extraction model to be trained to obtain the sample behavior features corresponding to each sample behavior segment, so as to form a sample behavior feature sequence, and the feature extraction model is used to predict the (t+1)th sample behavior feature based on the t-th sample behavior feature; wherein, the t-th sample behavior feature in the sample behavior feature sequence corresponds to the t-th time window; the model parameters of the feature extraction model are adjusted according to the deviation between the prediction result and the (t+1)-th sample behavior feature until the training conditions are met.

[0111] The server can then compare the real-time behavioral characteristics with the baseline behavioral characteristics to obtain the agent's behavioral deviation, and then determine the corresponding detection result based on the behavioral deviation.

[0112] The server can comprehensively evaluate the above test results and obtain the final identity authentication result.

[0113] In some embodiments, the methods described herein can also be used in conjunction with external behavior monitoring or tool call auditing mechanisms. In this case, reasoning-based authentication primarily focuses on whether the Agent's internal reasoning conforms to its role type constraints, while external behavior monitoring focuses on whether API call patterns, tool usage sequences, or resource access paths are abnormal. Together, they form a two-layer authentication framework from internal reasoning to external behavior. However, the core of this specification remains: dynamic authentication of runtime identity through the matching relationship between role type signatures and reasoning step types.

[0114] In addition to inference process data, the runtime authentication input obtained by the server may also include input-side security detection results and / or output-side constraint detection results. The input-side security detection results characterize whether there is any suspected injection content in the task input, while the output-side constraint detection results characterize whether the Agent's output exceeds the preset format or content range. The server can combine this supplementary data with the inference process data to help identify anomalies and risks.

[0115] Figure 7This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 7 As shown, device 700 mainly consists of a communication interface 702, a user interface 704, a processor 706, and a data storage 708. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 710. The communication interface 702 enables device 700 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 702 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 702 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 702 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 702 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0116] User interface 704 includes receiving user input and providing output to the user. Therefore, user interface 704 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 704 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 704 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 700 may support remote access from other devices via communication interface 702 or another physical interface (not shown). User interface 704 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 704 may also be configured as a display device for rendering or displaying text fragments.

[0117] Processor 706 may contain one or more general-purpose processors and / or special-purpose processors.

[0118] Data storage 708 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 706. Data storage 708 may include removable and non-removable components.

[0119] Processor 706 is capable of executing program instructions 718 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 708 to perform the various functions described herein. Data storage 708 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 700, enable device 700 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 706 executing program instructions 718 may result in processor 706 using data 712.

[0120] For example, program instructions 718 may include an operating system 722 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 700 and one or more applications 720 (e.g., a browser, social application, or game application). Similarly, data 712 may include operating system data 716 and application data 714. Operating system data 716 is primarily accessible to the operating system 722, while application data 714 is primarily accessible to one or more applications 720. Application data 714 may reside in a file system visible or hidden from the user of device 700.

[0121] Application 720 can communicate with operating system 722 through one or more application programming interfaces (APIs). These APIs help application 720 read and / or write application data 714, transmit or receive information via communication interface 702, receive or display information on user interface 704, etc.

[0122] In some terminology, application 720 may be simply referred to as "app". Furthermore, application 720 can be downloaded to device 700 through one or more online app stores or app markets. However, applications can also be installed on device 700 in other ways, such as through a web browser or a physical interface on device 700 (e.g., a USB port).

[0123] Please refer to Figure 8 Inference-based classification-based agent authentication devices can be applied to, for example... Figure 7 The device shown is used to implement the technical solution of this specification. The device may include: The registration module 800 is used to pre-register the role type signature of the Agent, wherein the role type signature includes at least the types of inference steps that the Agent is allowed to execute and the types of inference steps that the Agent is prohibited from executing; The acquisition module 802 is used to acquire the reasoning process data generated by the Agent during the execution of the current task; The annotation module 804 is used to determine the reasoning steps contained in the reasoning process data and to annotate the type of the reasoning steps; The matching module 806 is used to match the role type signature with the labeled reasoning step type in order to verify the compliance of the reasoning step type. The authentication module 808 is used to determine the identity authentication result for the Agent based on the result of the compliance verification.

[0124] Optionally, the registration module 800 is specifically used to obtain the identity credentials declared by the Agent, configure the role type signature corresponding to the Agent, bind the identity credentials with the configured role type signature, and store them.

[0125] Optionally, the annotation module 804 is specifically used to determine whether the description text corresponding to the reasoning step matches a preset keyword; if yes, then determine the type of the reasoning step according to the preset mapping relationship between the keyword and the reasoning step type; if no, then input the description text corresponding to the reasoning step into a preset classifier to determine the type of the reasoning step through the classifier.

[0126] Optionally, the matching module 806 is specifically used to determine whether the marked inference step type belongs to the inference step type that the Agent is allowed to execute; and to determine whether the marked inference step type belongs to the inference step type that the Agent is prohibited from executing; if the marked inference step type belongs to the inference step type that the Agent is allowed to execute, then the Agent is determined to have passed the compliance verification; if the marked inference step type belongs to the inference step type that the Agent is prohibited from executing, then the Agent is determined to have failed the compliance verification.

[0127] Optionally, the matching module 806 is further configured to determine that the Agent is in a pending confirmation state and trigger secondary authentication for the Agent if the marked inference step type is neither a type of inference step that the Agent is allowed to execute nor a type of inference step that the Agent is prohibited from executing.

[0128] Optionally, the role type signature may also include prohibited type conversion relationships; The matching module 806 is further configured to determine whether a prohibited type conversion relationship is formed between the types of two adjacent inference steps; if so, it is determined that the marked inference step type has not passed the compliance verification.

[0129] Optionally, the types of inference steps that the Agent is allowed to execute include at least one core inference step type; The matching module 806 is specifically used to determine whether the marked reasoning step type contains the core reasoning step type; if not, it is determined that the marked reasoning step type has not passed the compliance verification.

[0130] Optionally, the authentication module 808 is further configured to detect the stability of the inference capability of the Agent and the consistency of the cross-session inference type distribution of the Agent; and determine the identity authentication result for the Agent based on the compliance verification result, the detection result of the inference capability stability, and the detection result of the cross-session inference type distribution consistency.

[0131] Optionally, the authentication module 808 is specifically used to evaluate the Agent's current reasoning ability for the labeled reasoning step type to obtain the Agent's real-time reasoning ability score; if the real-time reasoning ability score does not exceed the reasoning ability boundary set in advance for the Agent, then it is determined that the Agent has passed the test of reasoning ability stability; otherwise, it is determined that the Agent has not passed the test of reasoning ability stability.

[0132] Optionally, the authentication module 808 is specifically configured to: determine the number of inference steps belonging to each inference step type in the current session, and determine the inference type distribution corresponding to the current session based on the number; obtain the historical inference type distribution corresponding to the historical session; calculate the distribution deviation between the inference type distribution corresponding to the current session and the historical inference type distribution; if the distribution deviation does not exceed a preset deviation threshold, determine that the Agent has passed the cross-session inference type distribution consistency detection; otherwise, determine that the Agent has not passed the cross-session inference type distribution consistency detection.

[0133] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0134] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0135] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0136] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0137] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0138] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0139] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0140] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0141] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0142] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0143] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. An agent authentication method based on reasoning classification, wherein the agent's role type signature is pre-registered, the role type signature including at least the types of reasoning steps allowed to be executed by the agent and the types of reasoning steps prohibited from being executed by the agent, the method comprising: Obtain the inference process data generated by the Agent during the execution of the current task; Identify the reasoning steps contained in the reasoning process data and label the types of the reasoning steps; The role type signature is matched with the labeled reasoning step type to verify the compliance of the reasoning step type; Based on the results of the compliance verification, the identity authentication result for the Agent is determined.

2. The method as described in claim 1, specifically including registering the role type signature of the Agent, includes: Obtain the identity credentials declared by the Agent, and configure the role type signature corresponding to the Agent; The identity credential is bound to the configured role type signature and stored.

3. The method as described in claim 1, wherein labeling the inference step type corresponding to the inference step specifically includes: Determine whether the description text corresponding to the reasoning step matches the preset keywords; If so, the type of reasoning step is determined according to the preset mapping relationship between the keywords and the reasoning step types; If not, the description text corresponding to the reasoning step is input into a preset classifier to determine the type of the reasoning step.

4. The method as described in claim 1, specifically including compliance verification of the labeled reasoning step types, includes: Determine whether the marked inference step type belongs to the inference step type that the Agent is allowed to execute; as well as Determine whether the marked inference step type belongs to the inference step type that the Agent is prohibited from executing; If the marked reasoning step type belongs to the reasoning step type that the Agent is allowed to execute, then the Agent is determined to have passed the compliance verification; If the marked reasoning step type belongs to the type of reasoning step that the Agent is prohibited from executing, then it is determined that the Agent has failed the compliance verification.

5. The method of claim 4, further comprising: If the marked reasoning step type is neither a type of reasoning step that the Agent is allowed to execute nor a type of reasoning step that the Agent is prohibited from executing, then the Agent is determined to be in a pending confirmation state, and secondary authentication for the Agent is triggered.

6. The method as described in claim 4, wherein the role type signature further includes prohibited type conversion relationships; Compliance verification of the labeled reasoning step types also includes: Determine whether the prohibited type conversion relationship exists between the types of two adjacent reasoning steps; If so, then it is determined that the type of reasoning step marked has not passed the compliance verification.

7. The method of claim 4, wherein the types of inference steps allowed to be performed by the Agent include at least one core inference step type; Compliance verification of the labeled reasoning step types also includes: Determine whether the marked reasoning step type includes the core reasoning step type; If not, then the type of reasoning step marked has failed the compliance verification.

8. The method of claim 1, further comprising: The stability of the Agent's reasoning ability is tested, and The consistency of the cross-session inference type distribution of the Agent is detected; Based on the compliance verification results, the identity authentication result for the Agent is determined, specifically including: Based on the results of the compliance verification, the detection results of the inference capability stability, and the detection results of the cross-session inference type distribution consistency, the identity authentication result for the Agent is determined.

9. The method as described in claim 8, wherein detecting the stability of the Agent's reasoning ability specifically includes: The Agent's current reasoning ability for the labeled reasoning step type is evaluated to obtain the Agent's real-time reasoning ability score; If the real-time reasoning ability score does not exceed the reasoning ability boundary set in advance for the Agent, then the Agent is determined to have passed the reasoning ability stability test; otherwise, the Agent is determined to have failed the reasoning ability stability test.

10. The method as described in claim 1, wherein detecting the consistency of the cross-session inference type distribution of the Agent specifically includes: Determine the number of inference steps belonging to each inference step type in the current session, and determine the distribution of inference types corresponding to the current session based on the number; as well as Obtain the distribution of historical reasoning types corresponding to historical sessions; Calculate the distribution deviation between the inference type distribution corresponding to the current session and the historical inference type distribution; If the distribution deviation does not exceed a preset deviation threshold, the Agent is determined to have passed the cross-session inference type distribution consistency detection; otherwise, the Agent is determined to have failed the cross-session inference type distribution consistency detection.

11. An agent authentication device based on reasoning classification, comprising: The registration module is used to pre-register the role type signature of the Agent, wherein the role type signature includes at least the types of inference steps that the Agent is allowed to execute and the types of inference steps that the Agent is prohibited from executing; The acquisition module is used to acquire the reasoning process data generated by the Agent during the execution of the current task; The annotation module is used to determine the reasoning steps contained in the reasoning process data and to annotate the type of the reasoning steps; The matching module is used to match the role type signature with the labeled reasoning step type in order to verify the compliance of the reasoning step type. The authentication module is used to determine the identity authentication result for the Agent based on the result of the compliance verification.

12. An electronic device, comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1-10 by executing the executable instructions.

13. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-10.

14. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-10.

Images