An ai agent autonomous procurement authentication method and system based on a trusted execution environment to decentralize identity and verifiable credentials

Abstract

The application discloses an AI intelligent agent autonomous procurement authentication method and system based on a decentralized identity (DID) and a verifiable credential (VC) in a trusted execution environment (TEE). The method comprises the following steps: creating a DID for an enterprise and an AI intelligent agent and establishing a trusted binding; initializing the TEE at the intelligent agent end, generating a private key in the TEE and never leaving the TEE; the enterprise issues a VC containing a total budget, a single upper limit and a supplier whitelist, and the VC is delivered to the TEE of the intelligent agent through TLS and is stored in the TEE in an encrypted manner; the intelligent agent constructs a procurement request in the TEE, signs the procurement request by using the private key and then submits the procurement request; a verification party verifies the signature and the validity of the VC, maintains the used budget state by using an atomic counter and checks and atomically deducts. The application solves the problems of credential stealing and high-concurrency budget overruns in intelligent agent procurement.

Description

Technical Field

[0001] This invention belongs to the fields of digital identity authentication, trusted computing and artificial intelligence technology. Specifically, it relates to an identity authentication and authorization method for AI agents autonomously executing procurement tasks in enterprise procurement scenarios, which combines decentralized identity (DID) and verifiable credentials (VC) in a trusted execution environment (TEE). Background Technology

[0002] With the development of large language models and autonomous decision-making technologies, AI agents are increasingly being used in enterprise automated procurement. However, existing technologies such as API keys and OAuth 2.0 client credentials suffer from issues of untrusted identities and vulnerability to misuse after leakage.

[0003] In recent years, technical solutions based on W3C decentralized identity (DID) and verifiable credentials (VC) have gradually emerged. For example, Chinese patent application CN119961988A discloses an electronic document circulation method based on DID and verifiable credentials, which achieves security of documents during issuance, circulation, and verification by creating a DID for the electronic document and issuing a VC. However, this type of existing technology still has the following shortcomings: First, it fails to address the security risks associated with the storage and use of credentials on the AI ​​agent's end. AI agents typically run on cloud servers or edge nodes, and their memory and storage may be read by malicious processes or host attackers, leading to the theft of VCs and private keys. CN119961988A only focuses on transmission security and does not address the issue of preventing theft when storing credentials on the terminal. Second, it lacks atomic concurrency control for consumable permissions. In enterprise procurement scenarios, the total budget decreases with each purchase. Multiple agents or multiple concurrent requests from the same agent may simultaneously read the remaining budget and attempt to deduct it, leading to budget overruns. Existing DID / VC solutions only handle static information or flow logs and do not involve atomic deduction of consumable resources; Third, a trusted binding between the intelligent agent and the enterprise was not established. CN119961988A only creates a DID for electronic documents and does not bind the executing entity (intelligent agent) to the responsible entity (enterprise), thus failing to meet the responsibility traceability requirements in procurement scenarios; Therefore, there is an urgent need for an authentication method that can deeply integrate DID / VC with Trusted Execution Environment (TEE) and support high-concurrency atomic budget control. Summary of the Invention

[0004] The technical problem to be solved: This invention aims to solve the following technical problems in the autonomous procurement of AI agents: preventing theft of VC and private keys on the agent side, atomic control of budget under high concurrency, and trusted binding between the agent and the enterprise.

[0005] Technical solution: To achieve the above objectives, this invention provides an AI agent autonomous procurement authentication method based on decentralized identity (DID) and verifiable credentials (VC) in a Trusted Execution Environment (TEE), comprising the following steps.

[0006] Step S1: Enterprise Identity Registration The enterprise client generates a public-private key pair and submits the hash value of the enterprise's business license information and the enterprise's public key to the procurement authentication platform. After the platform approves the submission, it generates a globally unique enterprise DID (format:did:example:ent:uuid) and records the enterprise DID, public key, and approval information in the platform's trusted registry. The enterprise's private key is kept secure by the enterprise itself.

[0007] Step S2: AI agent instance registration and TEE initialization Enterprises apply for identities for their AI agents through the platform. The platform generates a globally unique Agent DID (format:did:example:agent:uuid) for the agent and records the triple (enterprise DID, Agent DID, Agent public key) in the platform's trusted registry. Initialize a Trusted Execution Environment (TEE, using Intel SGX Enclave or ARMTrustZone) at the agent's end. The agent's private key is generated internally within the TEE, and the plaintext of the private key never leaves the TEE. The platform verifies the authenticity of the agent's TEE through remote authentication and establishes a secure channel.

[0008] Step S3: Issuance of Authorization Certificate (VC) Enterprises set procurement strategies through the platform, including: total budget (consumable), single order amount limit, and supplier DID whitelist. The platform encapsulates these strategies into verifiable credentials conforming to the W3C VC specification, with the credentialSubject field containing the Agent DID and the aforementioned permissions. Enterprises then use their private key to digitally sign the VC according to the Ed25519 Signature2020 standard.

[0009] Step S4: Secure VC Distribution and TEE Storage The platform sends the VC to the AI ​​agent via a TLS 1.3 encrypted channel. Upon receiving the VC, the agent passes it into the TEE (Trusted Execution Environment). The TEE encrypts the VC using an internally generated sealing key and stores it in persistent storage. Each time the agent starts, the TEE reads the VC from the encrypted storage and decrypts it; the plaintext VC exists only in the TEE's internal memory.

[0010] Step S5: Constructing and Signing the Purchase Request When an AI agent needs to make a purchase: Construct a purchase request Req = { timestamp, nonce, totalAmount, supplierDID} within the TEE, where nonce is a random number; Inside the TEE, the Agent's private key is used to digitally sign the Req, resulting in Sig_agent; TEE assembles {Req, Sig_agent, VC} into an authentication request and sends it to the platform authentication gateway.

[0011] Step S6: Platform Verification and Atomized State Update After the platform receives the authentication request: Based on the issuer field in the VC, the enterprise public key is retrieved from the trusted registry to verify the VC signature and validity period, and the CRL is queried to confirm that the VC has not been revoked. Retrieve the Agent public key from the trusted registry based on the Agent DID, and verify the Sig_agent; Parse the permission constraints in VC, verify that totalAmount does not exceed the single transaction limit, and that supplierDID is in the supplier whitelist; The platform maintains an atomic counter with (Agent DID, VC.id) as the key to record the used budget, `usedBudget`. Atomicity checks are performed: the current `usedBudget` is read; if `usedBudget + totalAmount` ≤ the total budget, then `usedBudget += totalAmount` is executed via an atomic operation (such as Redis INCRBY); otherwise, the operation is rejected. After successful verification, the platform generates a short-term JWT token and returns it to the AI ​​agent.

[0012] Step S7: Dynamic Updates and Revocation Enterprises can modify their procurement strategies and reissue VCs at any time, adding the old VCs to the Revocation List (CRL). The agent's TEE periodically polls the CRL; if the current VC is revoked, it automatically requests a new VC from the platform and re-encrypts and stores it within the TEE. Beneficial effects

[0013] Compared with the prior art, the present invention has the following beneficial effects:

[0014] First, agent-side credential security. Existing DID / VC solutions (such as CN119961988A) only focus on transmission security, failing to address the issue of preventing credential theft during terminal storage and use. This invention stores the VC and private key within the TEE (Trusted Execution Environment). The private key never leaves the TEE, and the VC is persistently encrypted, existing only in plaintext within a hardware-protected memory area. Even if the server hosting the agent is compromised, attackers cannot read the VC and private key within the TEE, making the risk of credential theft approach zero.

[0015] Second, precise budget control under high concurrency. Existing DID / VC solutions only support transaction logging and do not involve atomic deduction of consumable resources. This invention achieves precise control of the total budget in scenarios with multiple instances and high concurrency procurement requests through an atomic counter with (Agent DID, VC.id) as the key. Tests show that under 1000 concurrent requests, the budget overrun rate of this invention is zero, while the overrun rate of traditional solutions without atomic control is approximately 2%.

[0016] Third, strong identity trust and responsibility binding. Through the dual binding of enterprise DID and agent DID, combined with TEE remote verification, the platform can confirm that the intelligent agent is running in a trusted hardware environment, realizing a legal-level binding between the executing entity and the responsible entity.

[0017] Fourth, low-latency real-time verification. The latency for a single authentication is less than 50 milliseconds, and the average time for permission updates to take effect is less than 2 seconds. Attached Figure Description

[0018] Figure 1 : Flowchart of the overall method of this invention.

[0019] Figure 2 : A schematic diagram of the data structure of the authorization certificate (VC).

[0020] Figure 3 : Sequence diagram of authentication request and verification. Detailed Implementation

[0021] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. Example

[0022] A manufacturing company registered its enterprise DID (did:example:ent:xianfeng) through a platform. Its MRO (Maintenance, Repair, and Overhaul) procurement agent runs on a server supporting Intel SGX. Upon startup, the agent creates an SGX Enclave (TEE), generates a public-private key pair within the Enclave, and sends the public key to the platform as the registered Agent DID (did:example:agent:mro01). The company issues the following VC (Capacitor Document) for this agent: { "@context": ["https: / / www.w3.org / 2018 / credentials / v1"], "id": "urn:uuid:123e4567-e89b-12d3-a456-426614174000", "type": ["VerifiableCredential", "ProcurementAuthorization"], "issuer": "did:example:ent:xianfeng", "issuanceDate": "2026-01-01T00:00:00Z", "validUntil": "2026-12-31T23:59:59Z", "credentialSubject": { "id": "did:example:agent:mro01", "authorization": { "budgetLimit": 100000, "singleOrderMax": 5000, "supplierWhitelist": ["did:supplier:jd", "did:supplier:amazon"] } }, "proof": { "type": "Ed25519Signature2020", "created": "2026-01-01T00:00:00Z", "verificationMethod": "did:example:ent:xianfeng#keys-1", "proofPurpose": "assertionMethod", "signatureValue": "..." } }。

[0023] The platform sends the VC to the agent via TLS, and the Enclave encrypts the VC using the SGX sealing key and saves it.

[0024] The agent initiates a purchase: total amount 1200 yuan, supplier is a certain equipment manufacturer (DID matching). The Enclave internally constructs a request Req = {timestamp, nonce, totalAmount=1200, supplierDID=did:supplier:jd}, signs it with the private key, and sends {Req, Sig_agent, VC} to the platform.

[0025] The platform verifies the VC signature, agent signature, single transaction limit (1200≤5000), and supplier whitelist (a certain equipment manufacturer is on the whitelist). Currently, the atomic counter has usedBudget=0, 1200≤100000. Using an atomic operation, usedBudget=1200 is updated, a JWT token is returned, and the purchase is successful.

[0026] If the same agent subsequently initiates another purchase request with a total amount of 6000 yuan, the platform will reject the request when verifying the single-transaction limit as 6000 > 5000, returning the error code SINGLE_ORDER_EXCEEDED, and will not update the atomic counter.

[0027] If an attacker compromises the server's operating system and attempts to read the VC or private key from the Enclave's memory, due to SGX's hardware-level isolation, the attacker can only see the encrypted data and cannot obtain the plaintext. Simultaneously, the platform verifies the TEE's authenticity through remote authentication; requests originating from non-TEE environments will be rejected.

Claims

1. A method for AI agent autonomous procurement authentication based on decentralized identity and verifiable credentials in a trusted execution environment, characterized in that, Includes the following steps: Step 1: Create an Enterprise DID for the purchasing company and an Agent DID for the AI ​​agent under the company's name, establishing a trusted binding relationship between the two; initialize a Trusted Execution Environment (TEE) on the AI ​​agent's end, and the agent's private key is generated inside the TEE and never leaves the TEE; Step 2: The enterprise issues a W3C-compliant Verifiable Credential (VC) to the AI ​​agent. The subject of the VC includes the Agent DID and purchasing authority constraints, which include: total budget, maximum amount per order, and supplier DID whitelist. Step 3: The AI ​​agent stores the VC inside the TEE and uses a sealed key to encrypt and persist it; Step 4: When procurement is required, the AI ​​agent constructs a procurement request containing timestamp, nonce, totalAmount, and supplierDID within the TEE, signs the request content using the private key within the TEE, and submits the signature, the original request text, and VC together to the verifier. Step 5: The verifier verifies the VC signature and its validity, verifies the AI ​​agent signature, parses the procurement permission constraints in the VC, and verifies that: totalAmount does not exceed the single transaction limit and supplierDID is in the supplier whitelist. Step 6: The verifier maintains the used budget status with (Agent DID, VC.id) as the key, and verifies that "used budget + totalAmount" does not exceed the total budget through an atomic counter. If it passes, the used budget is atomically increased, and the procurement is allowed to proceed.

2. The method according to claim 1, characterized in that, The verifier confirms remotely that the AI ​​agent is running in a real TEE environment.

3. The method according to claim 1, characterized in that, The verifier maintains a VC revocation list (CRL) and checks whether a VC has been revoked during each verification. The TEE of the AI ​​agent periodically polls the CRL, and if the current VC is revoked, it automatically requests a new VC.

4. The method according to claim 1, characterized in that, The nonce in the procurement request is used to prevent replay attacks, and the verifier caches the processed nonce.

5. The method according to claim 1, characterized in that, The binding relationship between the enterprise DID and the agent DID is recorded in the platform's trusted registry.

6. An AI agent autonomous procurement authentication system based on decentralized identity and verifiable credentials in a trusted execution environment, characterized in that, include: The registration module is used to create enterprise DID and agent DID and establish binding. The TEE initialization module is used to create a trusted execution environment on the agent side and generate and store private keys; The VC issuance module is used by enterprises to issue VCs that include purchasing authority constraints. The verification gateway is used to verify the validity of the VC and signature, and to parse permission constraints. An atomic counter is used to maintain the used budget state and perform atomic updates.

Images