Intelligent agent service access control method and system based on dynamic token multiple check

Abstract

The present application relates to the field of computer security, and particularly relates to an agent service access control method and system based on dynamic token multiple verification, wherein the server of the method generates a globally unique dynamic token in response to a context initialization request of an agent, and binds the token with a current operation context, and simultaneously updates other active tokens under the same session in a token registration table to an inactive state, so as to realize isolation of one context and one token. When the agent initiates a service request carrying the token, the server sequentially performs existence verification and state validity verification, and only when the token exists and is active, the service logic is executed, otherwise a structured error response containing an error type, a current active token and a repair suggestion is returned. The present application realizes fine-grained access control at the request level, effectively prevents context confusion, and gives the agent an automatic error recovery capability, thereby improving the reliability and security of system calls.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and in particular to a method and system for access control of intelligent agent services based on dynamic token multi-verification. Background Technology

[0002] Intelligent agent service access control refers to the mechanism by which the server verifies the identity and permissions of an intelligent agent when it calls external services, such as databases or API interfaces. This typically employs session-based or API key-based authentication methods. The server assigns a fixed session identifier or key to the intelligent agent, which carries this credential with each service call. The server verifies the validity of the credential and decides whether to grant access. This method can confirm the caller's identity and ensure basic access security.

[0003] In scenarios where agents call external services, existing technologies use fixed session identifiers or API keys for authentication, with multiple calls within the same session sharing the same credential. Because this approach uses a fixed credential, the server struggles to distinguish between requests from different rounds and with different intentions within the same session. When an agent initiates a call with outdated parameters due to contextual misunderstanding, the server struggles to identify and reject such requests. Furthermore, the credential's lifecycle is difficult to match with the rhythm of changes in the dialogue state, hindering fine-grained management synchronized with the operational phase.

[0004] In the field of access control, some solutions introduce additional validation logic, but these validations mostly focus on identity or static permissions, making it difficult to bind requests to dynamic operational contexts. When multiple requests with different intentions are initiated successively within the same session, existing solutions lack validation of the matching degree between request parameters and the current context, making it difficult to effectively prevent invalid calls caused by context mismatch. In addition, regarding error handling, existing solutions typically only return general error codes when validation fails, making it difficult for clients to obtain effective recovery guidance from them. Often, manual intervention or reliance on pre-defined exception handling logic is required, and the system's automatic error correction capability needs improvement. Summary of the Invention

[0005] To address one or more problems in the prior art, the main objective of this application is to provide a method and system for access control of intelligent agent services based on dynamic token multi-verification.

[0006] To achieve the aforementioned objectives, this application proposes a method for intelligent agent service access control based on dynamic token multi-factor authentication, the method comprising: The server receives a context initialization request sent by the agent, generates a globally unique dynamic token in response to the context initialization request, and binds the dynamic token to the current operation context; Record the dynamic token in the token registry and set it to an active state; update the status of other active tokens besides the dynamic token to an inactive state. In response to a service access request carrying a token to be verified sent by an intelligent agent, the token to be verified is extracted from the service access request; The token to be verified is subjected to an existence check and a status validity check in sequence. The existence check is used to determine whether the token to be verified exists in the token registry, and the status validity check is used to determine whether the token to be verified is in an active state. If the token to be verified passes the existence check and the state validity check, the business logic corresponding to the business access request is allowed to be executed and the business execution result is returned; otherwise, the business access request is blocked and a structured error response message is returned.

[0007] This application also provides an intelligent agent service access control system based on dynamic token multi-verification, including: The receiving module is used to receive a context initialization request sent by the intelligent agent on the server side, generate a globally unique dynamic token in response to the context initialization request, and bind the dynamic token to the current operation context; The update module is used to record the dynamic token in the token registry and set it to an active state, and update the state of other active tokens other than the dynamic token to an inactive state; The extraction module is used to extract the token to be verified from the service access request sent by the intelligent agent in response to the service access request carrying the token to be verified. The verification module is used to sequentially perform existence verification and status validity verification on the token to be verified, wherein the existence verification is used to determine whether the token to be verified exists in the token registry, and the status validity verification is used to determine whether the status of the token to be verified is active. The judgment module is configured to, if the token to be verified passes the existence check and the state validity check, allow the execution of the business logic corresponding to the business access request and return the business execution result; otherwise, block the business access request and return structured error response information.

[0008] This application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0009] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0010] This application presents a method and system for intelligent agent service access control based on dynamic token multi-verification. This method achieves fine-grained control over intelligent agent service calls by organically combining dynamic token generation, proactive invalidation mechanisms, sequential dual verification, and structured error responses. First, this method generates a unique token for each independent operation stage and proactively invalidates the preceding token when a new token is generated, ensuring that only one active token exists at any given time within the same session. This solves the context confusion problem caused by the difficulty in distinguishing different rounds of requests due to fixed credentials in existing technologies, enabling the server to accurately identify the operation stage of each call and preventing invalid calls based on outdated contexts from being executed. Second, it provides precise lifecycle management synchronized with operation stages. The token's active state no longer depends on a fixed timeout but is dynamically bound to the progress of the operation stage; each new stage corresponds to a new token, and old tokens become invalid immediately. This allows the credential's lifecycle to accurately match the rapid changes in the dialogue state, achieving more timely and flexible security state management than traditional session mechanisms. Finally, it constructs a self-healing error handling mechanism. Sequential dual verification is set on the server side; only requests that pass existence and state validity verification can enter the business logic. When verification fails, a structured error response is returned, containing the error type, the currently valid token, and explicit repair suggestions. This allows the agent to automatically identify the problem and correct the error without human intervention, thus improving the user experience of the distributed agent system. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating an embodiment of the intelligent agent service access control method based on dynamic token multi-verification according to this application. Figure 2 This is a flowchart illustrating an embodiment of the intelligent agent service access control method based on dynamic token multi-verification according to this application. Figure 3 This is a schematic block diagram of the structure of an intelligent agent service access control system based on dynamic token multi-verification according to an embodiment of this application; Figure 4 This is a schematic block diagram of the structure of a computer device according to an embodiment of this application.

[0012] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0014] Reference Figure 1 This application provides a method for access control of intelligent agent services based on dynamic token multi-factor authentication, the method comprising: S1. The server receives a context initialization request sent by the agent, generates a globally unique dynamic token in response to the context initialization request, and binds the dynamic token to the current operation context. S2. Record the dynamic token in the token registry and set it to an active state; update the status of other active tokens besides the dynamic token to an inactive state. S3. In response to a service access request carrying a token to be verified sent by the intelligent agent, extract the token to be verified from the service access request; S4. Perform an existence check and a status validity check on the token to be verified in sequence. The existence check is used to determine whether the token to be verified exists in the token registry, and the status validity check is used to determine whether the token to be verified is in an active state. S5. If the token to be verified passes the existence check and the state validity check, then the business logic corresponding to the business access request is allowed to be executed and the business execution result is returned; otherwise, the business access request is blocked and a structured error response information is returned.

[0015] As described in steps S1-S3 above, this method achieves fine-grained control over agent service calls through the generation, registration, and expiration of dynamic tokens, as well as server-side sequence verification. S1: When an agent needs to initiate a new phase with independent operational significance, such as processing a new user query, the agent first sends a context initialization request to the server. Upon receiving this request, the server generates a globally unique dynamic token in response. The server needs to create a unique digital credential for the upcoming operational phase. To ensure the token's uniqueness and unforgeability, the server can combine various information to generate it, such as combining the current high-precision timestamp, the session identifier carried in the request, and a cryptographically secure random number. These elements are then combined and hashed to obtain the final token string. The high-precision timestamp ensures that tokens generated at different times have a natural temporal difference; the session identifier binds the token to a specific user session; and the random number further increases the token's unpredictability. The combination of these three elements, after hashing, makes the generated token both unique and difficult to reverse engineer or forge. After generating the token, the server binds it to the current operational context. Binding refers to establishing an association between the key context information involved in the current operation, such as user intent, associated business objects, or hash values ​​of ontology subgraphs, and the token. The S2 server records the generated dynamic token in the token registry and sets its status to active. The token registry can be understood as a centralized data structure storing all issued tokens and their states, which can be implemented using an in-memory database such as Redis to ensure efficient read and write performance. Simultaneously, the server queries whether there are other active token records under the same session identifier. If so, it updates the status of these older tokens to inactive. This ensures mutual exclusion of tokens within the same session, guaranteeing that at any given time, at most one token is active in a session. Whenever a new token is generated, the previous token is automatically invalidated, thus tightly binding the token's lifecycle to changes in the operation phase. This approach makes the token no longer a long-term valid static credential, but rather dynamically updated as the operation phase progresses, with each token representing only the latest operation context. When the S3 agent needs to perform specific business operations, such as querying data or performing an action, it sends a business access request carrying the token to be verified to the server. After receiving the request, the server first extracts the token to be verified from the request. This step is the starting point of the entire verification process, establishing a connection between the request and the previously generated token.

[0016] As described in steps S4-S5 above, the server sequentially performs existence verification and status validity verification on the extracted tokens to be verified. Existence verification determines whether the token exists in the token registry. If the token is not in the registry, it means that the token has never been issued or has been cleared by the system, making it an invalid token. This verification effectively prevents requests using forged or invalid tokens from entering the business processing flow. Status validity verification further checks whether the token is active. If a token exists in the registry but its status is marked as inactive, it means that the operation phase corresponding to the token has ended, and a newer token represents the latest operation context. This verification ensures that only tokens representing the latest operation phase are allowed to proceed. The order of these two verifications is designed with clear logical considerations. Existence verification is fundamental; if the token does not exist, subsequent status verification becomes meaningless. Only tokens that pass the existence verification need further verification to determine their status validity. This makes the verification logic clear and efficient. If the token to be verified successfully passes the existence and state validity checks, it indicates that the token is legitimate and currently active. The server then allows the execution of the business logic corresponding to the business access request and returns the execution result to the agent. If the token to be verified fails either check, the server blocks the current business access request, stops executing the business logic, and returns a structured error response. This structured error response is not just a simple error code, but contains information that provides clear guidance to the agent, such as the error type identifier, the valid tokens available in the current session, and specific remedial suggestions, enabling the agent to automatically correct the error and re-initiate the request based on this information.

[0017] As described above, this method achieves fine-grained control over agent service calls by organically combining dynamic token generation, proactive invalidation mechanisms, sequential double verification, and structured error responses. First, this method generates a unique token for each independent operation stage and proactively invalidates the preceding token when a new token is generated, ensuring that only one active token exists at any given time within the same session. This solves the context confusion problem caused by the difficulty in distinguishing different rounds of requests due to fixed credentials in existing technologies, enabling the server to accurately identify the operation stage of each call and preventing invalid calls based on outdated contexts from being executed. Second, it provides precise lifecycle management synchronized with operation stages. The token's active state no longer depends on a fixed timeout but is dynamically bound to the progress of the operation stage; each new stage corresponds to a new token, and old tokens become invalid immediately. This allows the credential's lifecycle to accurately match the rapid changes in the dialogue state, achieving more timely and flexible security state management than traditional session mechanisms. Finally, it constructs a self-healing error handling mechanism. Sequential double verification is set on the server side; only requests that pass existence and state validity checks can enter the business logic. When verification fails, a structured error response is returned, containing the error type, the currently valid token, and explicit repair suggestions. This allows the agent to automatically identify the problem and correct the error without human intervention, thus improving the user experience of the distributed agent system.

[0018] In one embodiment, the step of generating a globally unique dynamic token in response to the context initialization request includes: Get the current timestamp; Extract the session identifier from the context initialization request; Generate cryptographically secure random numbers; The timestamp, the session identifier, and the random number are combined to form a combined string; Perform a hash operation on the combined string to generate the dynamic token.

[0019] As described above, in Step 1, the server first obtains the current high-precision timestamp. This element introduces a time dimension, ensuring that tokens generated at different times have temporal differences. Since timestamps are unidirectionally increasing, even if other elements are identical, tokens generated at different times will differ due to the different timestamps. The use of high-precision timestamps makes the time granularity of token generation finer, further reducing the probability of duplication. In Step 2, the server extracts the session identifier from the context initialization request sent by the agent. The session identifier represents the ownership of this dialogue and is typically used to identify a complete user session. Using the session identifier as one of the elements in token generation binds the token to a specific session, naturally isolating tokens generated between different sessions and avoiding cross-session token confusion. In Step 3, the server generates a cryptographically secure random number. Introducing a random number increases the unpredictability of the token, allowing external attackers to accurately deduce the token's specific value even if they understand the generation patterns of the timestamp and session identifier. In Step 4, the server combines the obtained timestamp, session identifier, and random number to form a combined string. The combination can be a simple concatenation or an arrangement in a specific order. This step integrates the three independent elements into a single whole, preparing input data for subsequent hash operations. Step five involves the server performing a hash operation on the combined string to generate the final dynamic token. Hash operations are unidirectional and deterministic; that is, the same input will always produce the same output, but the input cannot be deduced from the output. The token string generated through hash operations maintains the uniqueness of the input information while ensuring that the original combined string cannot be reversed, thus enhancing token security.

[0020] Reference Figure 2 In one embodiment, after performing existence verification and state validity verification on the token to be verified in sequence, the method further includes: S51. Extract service parameters from the service access request; S52. Obtain a snapshot of the context bound to the token to be verified from the token registry. S53. Determine whether the service parameters are within the permitted range of the context snapshot; S54. If the service parameters are not within the permitted range of the context snapshot, then block the service access request and return an error response message indicating context inconsistency. S55. If the business parameters are within the permitted range of the context snapshot, then continue to execute the business logic corresponding to the business access request and return the business execution result.

[0021] As described above, a context consistency check is further introduced as a third layer of verification after the existence and state validity checks. This third layer of verification allows the server to not only verify the legality and activity of the token itself, but also to verify whether the business parameters carried in the request match the context represented by the token. Step 1: After the token to be verified passes the existence and state validity checks, the server extracts business parameters from the business access request. Business parameters refer to the key information involved in the specific operation that the agent wants to perform. For example, in the scenario of querying an order, the business parameter might be the order number; in the scenario of obtaining device information, the business parameter might be the device identifier. These parameters reflect the specific intent of the agent's current call. Step 2: The server obtains the context snapshot bound to the token to be verified from the token registry. The context snapshot is recorded when the token is generated, and it represents the business scope permitted by the operation stage corresponding to the token. For example, if the token is generated when a user queries a specific order, the context snapshot might contain the order number or ontology subgraph information related to the order. Step 3: The server determines whether the extracted business parameters are within the permitted scope of the context snapshot. The logic behind this judgment is that a token can only be used to perform operations that match the context in which it was generated. If a user first queries order A and obtains token T1, and then queries order B and obtains token T2, then when the agent mistakenly uses T1 to query order B, the server will find that the business parameter of order B is not within the permitted scope of the context snapshot bound to T1. Step four: If the business parameter is not within the permitted scope of the context snapshot, the server will block the current business access request and return a context inconsistency error response. This error response is similar to the aforementioned structured error response, but the error type will explicitly point to the specific reason of context mismatch, making it easier for the agent to identify the problem. If the business parameter is within the permitted scope of the context snapshot, the server will continue to execute the aforementioned business logic, that is, allow the request to proceed to the subsequent business processing flow and return the execution result.

[0022] In one embodiment, the step of returning structured error response information includes: When the token to be verified fails the existence verification or the status validity verification, the current valid token with the same session identifier as the service access request and whose status is active is queried from the token registry. Based on the query results, a structured error response message is generated. The structured error response message includes an error type identifier, a currently valid token, and a repair suggestion. The repair suggestion is used to instruct the agent to re-initiate the service access request using the currently valid token. Based on the generated structured error response information, the structured error response information is returned to the agent.

[0023] As mentioned above, in step one, when the token to be verified fails the existence or state validity check, the server does not simply return a fixed error message. Instead, it actively queries the token registry for a token record with the same session identifier as the current business access request and in an active state, finding the truly valid token for the current session. Verification failure often means that the token carried by the agent is no longer an active token for the current session. However, as the token manager, the server clearly knows which token is truly valid in the current session. By actively querying and obtaining this valid token, the server can provide the agent with the most direct basis for repair. In step two, the server generates a structured error response message based on the query results. This response message contains three core elements. The first is the error type identifier, which tells the agent the specific reason for the verification failure, such as the token not existing or the token having expired, helping the agent understand the nature of the problem. The second is the currently valid token, i.e., the active token just found by the server, which is the correct credential the agent can use to re-initiate the request. The third is the repair suggestion, which explicitly instructs the agent to re-initiate the business access request using the currently valid token. The agent doesn't need to make judgments or guesses; it simply needs to follow the repair suggestions. In step three, the server returns the generated structured error response information to the agent. Upon receiving this response, the agent can understand the reason for the failure based on the error type identifier it contains. More importantly, it can extract the currently valid token and use that token to re-initiate the business access request according to the repair suggestions, thus achieving automatic error recovery.

[0024] In this embodiment, in existing technical solutions, when server-side verification fails, it typically only returns a general error code or a simple error description, such as invalid token or insufficient permissions. Upon receiving such an error, the agent often cannot determine the specific cause of the failure, let alone know how to correct it. It might repeatedly retry using the same invalid token, leading to an infinite loop; or it might simply abandon the current operation and wait for manual intervention. In either case, the system's automatic recovery capability is limited. This method, however, provides the agent with a clear recovery path by actively querying and returning the currently valid token when verification fails. The agent no longer needs to guess what the correct token is, nor does it need to rely on complex pre-defined logic to try to obtain a new token; it only needs to extract the currently valid token from the error response and retry. This design enables the agent to achieve automatic error recovery with low complexity.

[0025] In one embodiment, the step of updating the state of other active tokens besides the dynamic token to an inactive state includes: Query the token registry for token records that have the same session identifier as the context initialization request and are in an active state; Based on the query results, a set of token records to be expired is obtained, and the record corresponding to the dynamic token is removed from the set of token records to be expired; Update the status of each remaining token record in the set of token records to be invalidated to an inactive state.

[0026] As described above, after the server records the newly generated dynamic token in the token registry and sets it to an active state, the server immediately queries the token registry for token records with the same session identifier as the current context initialization request and whose state is active. This query operation finds all tokens currently active in this session, including both newly generated tokens and previously issued but not yet expired tokens. Step two: Based on the query results, the server obtains a set of token records to be expired. This set contains all the active token records found in the query. Subsequently, the server removes the record corresponding to the dynamic token from this set, which is the newly generated token. After this operation, only the old tokens that need to be expired remain in the set of token records to be expired. Step three: The server updates the state of all remaining token records in the set of token records to inactive. At this point, all previously active old tokens become inactive, while new tokens remain active, thus achieving the goal of having only one active token in the same session. By querying first, then removing the current token, and finally updating in batches, the server ensures the correctness and completeness of the expiration operation. Regardless of how many active tokens have accumulated in the same session, this process can clean them all up at once.

[0027] It is worth mentioning that this embodiment provides a specific and reliable operation path for the token invalidation mechanism. While it specifies updating the status of other active tokens to inactive, ensuring that this invalidation operation executes correctly under various circumstances, especially preventing the accidental invalidation of newly generated tokens, is a technical detail that needs clarification. In actual operation, multiple active tokens may exist within a single session for various reasons. For example, in normal operation, old tokens are invalidated promptly when a new token is generated, so usually there is only one active token (the new token). However, in some abnormal scenarios, such as network latency or high system load causing the status update to fail to complete in time, multiple active tokens may coexist. If the invalidation operation is not designed rigorously enough, it may mistakenly invalidate the new token as well, or fail to invalidate some old tokens.

[0028] In one embodiment, the method further includes: When generating the dynamic token, an expiration timestamp is bound to the dynamic token, and the expiration timestamp is determined based on the current time and the preset window duration; When the dynamic token is recorded in the token registry, the expiration timestamp is stored in association. After extracting the token to be verified from the business access request, the current time is obtained, and it is determined whether the current time exceeds the expiration timestamp bound to the token to be verified. If the current time exceeds the expiration timestamp, the service access request is blocked, and an error response message indicating that the token has expired is returned. If the current time has not exceeded the expiration timestamp, then the existence check and status validity check will continue to be performed.

[0029] As mentioned above, the time-based token expiration mechanism adds an extra layer of protection to token lifecycle management. This mechanism ensures that even if a token is not overwritten by a new token, it will automatically expire after a preset time window. Step one: When generating a dynamic token, the server simultaneously binds an expiration timestamp to it. This expiration timestamp is calculated based on the current time plus a preset window duration. The specific value of the window duration can be flexibly set according to the needs of the business scenario, for example, it can be set to a few minutes, tens of minutes, or longer. This window duration represents the validity period of the token from generation to automatic expiration. This introduces a time-sensitivity attribute to the token, independent of state management. Even if the token remains active and is never overwritten by a new token, it will naturally lose its validity after reaching this time boundary. This sets an absolute upper limit on the token's lifecycle, avoiding the potential risks of tokens remaining valid for extended periods due to various reasons. Step two: When the server records the dynamic token in the token registry, it also stores the token's expiration timestamp. This way, when the token needs to be verified later, the server can quickly obtain its expiration time information. Step 3: After extracting the token to be verified from the business access request, the server obtains the current system time and determines whether the current time has exceeded the expiration timestamp bound to the token. Step 4: If the current time has exceeded the expiration timestamp, it means the token has exceeded its preset validity period, even if its status in the registry may still be active. In this case, the server blocks the business access request and returns an error response indicating the token has expired. This error response is similar to a structured error response, with the error type pointing to the specific reason of time expiration. If the current time has not exceeded the expiration timestamp, it means the token is still valid, and the server continues to perform the existence and status validity checks, proceeding to the subsequent verification process.

[0030] For example, suppose a user quickly and consecutively asks two questions in an intelligent customer service system. The first question triggers the agent to call the initialization service and obtain token T1. Immediately afterwards, the user asks the second question, and the agent again calls the initialization service, obtaining a new token T2. ​​Simultaneously, the server begins updating the state of T1 to inactive. In this high-concurrency scenario, a subtle timing issue may arise. When the agent uses the old token T1 to execute the business query corresponding to the first question, the server's verification request and the registration request for T2 arrive almost simultaneously. Without an expiration timestamp mechanism, the verification process would execute in the order of existence verification and state validity verification. If the state update operation of T1 has not yet been completed, the state validity verification might consider T1 still active, thus incorrectly allowing a request that should be rejected. This results in T1 and T2 being active simultaneously in the same session, violating the core mechanism of context isolation and potentially causing subsequent context confusion. However, with the expiration timestamp mechanism defined in this implementation, the server, upon receiving a business request carrying T1, will first perform a time verification. Because T1 is bound to an expiration timestamp during its generation, and this timestamp is typically set to a short period, such as a few minutes, time verification plays a crucial role even if the state update operation of T1 is delayed due to concurrent timing. If a period of time has elapsed from the generation of T1 to the current request, time verification may detect that the current time is close to or exceeds the expiration timestamp, thus blocking the request in time. More importantly, even if time verification fails to intercept, subsequent existence verification and state validity verification will correctly identify the inactive state of T1 after the state update is completed. The existence of time verification provides an additional buffer mechanism for timing issues in concurrent scenarios, reducing the probability of false positives due to state update delays. This dual-protection design enables the system to maintain consistent context isolation when facing high-concurrency requests. The time expiration mechanism and the state expiration mechanism work together to ensure that old tokens are expired in a timely manner when switching operation phases, and to provide a layer of protection against timing issues in concurrent scenarios, making token lifecycle management more robust and reliable.

[0031] In one embodiment, the method further includes: Upon receiving the context initialization request, the operation identifier carried in the context initialization request is obtained. The operation identifier is used to uniquely identify the business operation to be executed this time. When generating the dynamic token, the operation identifier is encoded in the dynamic token; After extracting the token to be verified from the service access request, the target operation identifier is decoded from the token to be verified. Determine whether the target operation identifier matches the actual operation corresponding to the service access request; If the target operation identifier does not match the actual operation, the service access request is blocked, and an error response message indicating an operation mismatch is returned.

[0032] As described above, in step one, when receiving the context initialization request from the agent, the server simultaneously obtains the operation identifier carried in the request. The operation identifier is a unique marker representing the business operation to be performed; it can be understood as telling the server what type of operation the agent intends to perform next. For example, in an intelligent customer service system, the agent might explicitly state during initialization that it will perform an order query operation, in which case the operation identifier would be "query order." Or, if the agent intends to perform an address modification operation, the operation identifier would be "modify address." This identifier is actively provided to the server by the agent when initiating the initialization request, allowing the server to clearly understand the goal of the current operation phase. In step two, when generating the dynamic token, the server encodes the obtained operation identifier into the token string. There are several encoding methods, such as directly embedding the operation identifier as part of the token composition, or converting it into a specific field in the token through some mapping relationship. Regardless of the encoding method used, the final result is that the token itself carries its corresponding operation type information, not just a randomly generated string. The operation identifier becomes part of the token's inherent attributes and no longer needs to be stored separately in the token registry. During subsequent verification, the server can directly parse the operation identifier from the token without querying additional data, making the verification process more efficient. Step 3: When the agent sends a business access request carrying the token to be verified, the server, after extracting the token, decodes the target operation identifier from it. This target operation identifier represents the operation type permission granted when the token was generated. Step 4: The server determines whether the decoded target operation identifier matches the actual operation corresponding to the current business access request. The actual operation refers to the type of operation the agent actually intends to execute in this request, which can be identified from the request's interface address, request parameters, or other characteristics. For example, if the operation identifier decoded from a token is "query order," but the agent's current request is "modify order," then the two do not match. Step 5: If the target operation identifier does not match the actual operation, it means the agent is attempting to use a token issued for a different operation type to execute the current operation, which constitutes unauthorized behavior. In this case, the server will block the business access request and return an error response indicating an operation mismatch, clearly informing the agent that the operation type does not match the token. If the target operation identifier matches the actual operation, it means that the scope of the token is consistent with the operation type of the current request. The server will continue to execute the subsequent verification process and finally allow the business request.

[0033] For example, in an intelligent customer service system, an agent receives two different user requests when processing a user query. The first request is to query the order status; the agent calls the initialization service with an operation identifier for querying the order and obtains token T1. The second request is to modify the shipping address; the agent calls the initialization service again with an operation identifier for modifying the address and obtains token T2. ​​If only the above method is used, when the agent mistakenly uses the order query token T1 to call the address modification service due to a program logic error, the server will perform existence and status validity checks. Since T1 was marked as inactive when T2 was generated, the status check will fail, and the request will be rejected. Although this prevents the erroneous call, the returned error message is that the token has expired, not that the operation is mismatched. The agent may mistakenly believe that it is a token expiration issue and obtain a new token, unaware that the root cause is the use of an incorrect type of token. Now, with the operation identifier binding mechanism of this embodiment, suppose the agent has already initiated the address modification request with T1 before T1 is marked as inactive. In this case, the state of T1 may still be active, and both the existence and status validity checks will pass. However, the operation identifier verification comes into play. The operation identifier decoded by the server from T1 is "query order," while the agent's current request is "modify address." Since they don't match, the request is promptly intercepted, and an operation mismatch error message is returned. Upon receiving this error, the agent clearly understands that the problem stems from using an incorrect token type, allowing it to take appropriate recovery measures, such as re-initializing with the correct operation identifier and obtaining a new token before re-initiating the request.

[0034] Reference Figure 3 This application also provides an intelligent agent service access control system based on dynamic token multi-verification, comprising: Receiving module 1 is used to receive a context initialization request sent by the intelligent agent on the server side, generate a globally unique dynamic token in response to the context initialization request, and bind the dynamic token to the current operation context; Update module 2 is used to record the dynamic token in the token registry and set it to an active state, and update the state of other active tokens other than the dynamic token to an inactive state; Extraction module 3 is used to extract the token to be verified from the service access request sent by the intelligent agent in response to the service access request carrying the token to be verified. Verification module 4 is used to sequentially perform existence verification and status validity verification on the token to be verified, wherein the existence verification is used to determine whether the token to be verified exists in the token registry, and the status validity verification is used to determine whether the status of the token to be verified is active. The judgment module 5 is used to allow the execution of the business logic corresponding to the business access request and return the business execution result if the token to be verified passes the existence check and the state validity check; otherwise, it blocks the business access request and returns structured error response information.

[0035] As described above, it is understood that each component of the intelligent agent service access control system based on dynamic token multi-verification proposed in this application can realize the function of any of the intelligent agent service access control methods based on dynamic token multi-verification as described above, and the specific structure will not be described in detail.

[0036] Reference Figure 4 This application also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores monitoring data and other data. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements an intelligent agent service access control method based on dynamic token multi-factor authentication.

[0037] The processor described above executes the intelligent agent service access control method based on dynamic token multi-verification, comprising: receiving a context initialization request sent by an intelligent agent; generating a globally unique dynamic token in response to the context initialization request; binding the dynamic token to the current operation context; recording the dynamic token in a token registry and setting it to an active state; updating the state of other active tokens besides the dynamic token to an inactive state; extracting the token to be verified from the service access request sent by the intelligent agent carrying a token to be verified; sequentially performing existence verification and state validity verification on the token to be verified, wherein the existence verification is used to determine whether the token to be verified exists in the token registry, and the state validity verification is used to determine whether the state of the token to be verified is active; if the token to be verified passes the existence verification and the state validity verification, then the execution of the business logic corresponding to the service access request is allowed and the service execution result is returned; otherwise, the service access request is blocked and a structured error response information is returned.

[0038] One embodiment of this application also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements an intelligent agent service access control method based on dynamic token multi-verification, including the following steps: a server receives a context initialization request sent by an intelligent agent; in response to the context initialization request, generates a globally unique dynamic token and binds the dynamic token to the current operation context; records the dynamic token in a token registry and sets it to an active state; updates the states of other active tokens besides the dynamic token to inactive states; in response to a service access request carrying a token to be verified sent by an intelligent agent, extracts the token to be verified from the service access request; sequentially performs an existence check and a state validity check on the token to be verified, wherein the existence check is used to determine whether the token to be verified exists in the token registry, and the state validity check is used to determine whether the state of the token to be verified is active; if the token to be verified passes the existence check and the state validity check, then the execution of the business logic corresponding to the service access request is allowed and the service execution result is returned; otherwise, the service access request is blocked and a structured error response information is returned.

[0039] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in this application and in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0040] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method 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, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0041] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for intelligent agent service access control based on dynamic token multi-verification, characterized in that, The method includes: The server receives a context initialization request sent by the agent, generates a globally unique dynamic token in response to the context initialization request, and binds the dynamic token to the current operation context; Record the dynamic token in the token registry and set it to an active state; update the status of other active tokens besides the dynamic token to an inactive state. In response to a service access request carrying a token to be verified sent by an intelligent agent, the token to be verified is extracted from the service access request; The token to be verified is subjected to an existence check and a status validity check in sequence. The existence check is used to determine whether the token to be verified exists in the token registry, and the status validity check is used to determine whether the token to be verified is in an active state. If the token to be verified passes the existence check and the state validity check, the business logic corresponding to the business access request is allowed to be executed and the business execution result is returned; otherwise, the business access request is blocked and a structured error response message is returned.

2. The intelligent agent service access control method based on dynamic token multi-verification according to claim 1, characterized in that, The step of generating a globally unique dynamic token in response to the context initialization request includes: Get the current timestamp; Extract the session identifier from the context initialization request; Generate cryptographically secure random numbers; The timestamp, the session identifier, and the random number are combined to form a combined string; Perform a hash operation on the combined string to generate the dynamic token.

3. The intelligent agent service access control method based on dynamic token multi-verification according to claim 1, characterized in that, After performing the existence check and state validity check on the token to be verified in sequence, the method further includes: Extract business parameters from the business access request; Obtain a snapshot of the context bound to the token to be verified from the token registry; Determine whether the business parameters are within the permitted range of the context snapshot; If the service parameters are not within the permitted range of the context snapshot, the service access request is blocked, and an error response message indicating context inconsistency is returned. If the business parameters are within the permitted range of the context snapshot, then the business logic corresponding to the business access request is allowed to be executed and the business execution result is returned.

4. The intelligent agent service access control method based on dynamic token multi-verification according to claim 1, characterized in that, The steps for returning structured error response information include: When the token to be verified fails the existence verification or the status validity verification, the current valid token with the same session identifier as the service access request and whose status is active is queried from the token registry. Based on the query results, a structured error response message is generated. The structured error response message includes an error type identifier, a currently valid token, and a repair suggestion. The repair suggestion is used to instruct the agent to re-initiate the service access request using the currently valid token. Based on the generated structured error response information, the structured error response information is returned to the agent.

5. The intelligent agent service access control method based on dynamic token multi-verification according to claim 1, characterized in that, The step of updating the status of other active tokens besides the dynamic token to an inactive state includes: Query the token registry for token records that have the same session identifier as the context initialization request and are in an active state; Based on the query results, a set of token records to be expired is obtained, and the record corresponding to the dynamic token is removed from the set of token records to be expired; Update the status of each remaining token record in the set of token records to be invalidated to an inactive state.

6. The intelligent agent service access control method based on dynamic token multi-verification according to claim 1, characterized in that, The method further includes: When generating the dynamic token, an expiration timestamp is bound to the dynamic token, and the expiration timestamp is determined based on the current time and the preset window duration; When the dynamic token is recorded in the token registry, the expiration timestamp is stored in association. After extracting the token to be verified from the business access request, the current time is obtained, and it is determined whether the current time exceeds the expiration timestamp bound to the token to be verified. If the current time exceeds the expiration timestamp, the service access request is blocked, and an error response message indicating that the token has expired is returned. If the current time has not exceeded the expiration timestamp, then the existence check and status validity check will continue to be performed.

7. The intelligent agent service access control method based on dynamic token multi-verification according to claim 1, characterized in that, The method further includes: Upon receiving the context initialization request, the operation identifier carried in the context initialization request is obtained. The operation identifier is used to uniquely identify the business operation to be executed this time. When generating the dynamic token, the operation identifier is encoded in the dynamic token; After extracting the token to be verified from the service access request, the target operation identifier is decoded from the token to be verified. Determine whether the target operation identifier matches the actual operation corresponding to the service access request; If the target operation identifier does not match the actual operation, the service access request is blocked, and an error response message indicating an operation mismatch is returned.

8. A smart agent service access control system based on dynamic token multi-verification, characterized in that, include: The receiving module is used to receive a context initialization request sent by the intelligent agent on the server side, generate a globally unique dynamic token in response to the context initialization request, and bind the dynamic token to the current operation context; The update module is used to record the dynamic token in the token registry and set it to an active state, and update the state of other active tokens other than the dynamic token to an inactive state; The extraction module is used to extract the token to be verified from the service access request sent by the intelligent agent in response to the service access request carrying the token to be verified. The verification module is used to sequentially perform existence verification and status validity verification on the token to be verified, wherein the existence verification is used to determine whether the token to be verified exists in the token registry, and the status validity verification is used to determine whether the status of the token to be verified is active. The judgment module is configured to, if the token to be verified passes the existence check and the state validity check, allow the execution of the business logic corresponding to the business access request and return the business execution result; otherwise, block the business access request and return structured error response information.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images