Integrating Lit Protocol for Enhanced Security In AI Agents

Travel Booking Use Case

By Robert Burkhart.

The advent of AI-driven solutions has revolutionized various industries, including travel and medicine, and will only become more influential. Despite the many benefits AI Agents provide, questions surrounding data privacy and usage become massive downfalls when considering AI Agent’s application in the medical field and personal leisure. With countless corporations mishandling, losing, and defrauding users’ data in the 21st century (whether that be from gross negligence or indifference is no matter) how can we trust them to secure our increasingly digital lives from being another data point to feed artificial intelligence?

This is where Lit Protocol comes into play, providing robust key management, token gating, and privacy-preserving computation capabilities needed for agent to agent communication. The provided case below is one among many like it, that display Lit Protocol’s ability to create trust-minimized AI-driven ecosystems that operate ethically and consciously aware of a user’s right to privacy.

High-Level Overview

The workflow begins when a user inputs a prompt, such as “Book a trip to Consensus 2025.” The orchestrator AI agent then coordinates multiple specialized AI agents to fulfill the booking request. These specialized AI agents include the Event Booking AI Agent, the Flight Booking AI Agent, and the Hotel Booking AI Agent. Each of these agents has a specific role: securing event tickets, arranging round-trip flights, and reserving accommodations. The orchestrator consolidates the inputs from these specialized agents and provides the user with the final travel information. Throughout the process the Orchestrator is the commander passing prompts to generally direct the Agent on the task and encrypted information on the task’s specifics. The orchestrator is essential because it handles the secure transfer of the user’s payment information and other necessary details between agents, and ultimately ensures that the decrypted travel information is returned to the user.

Components of Lit Protocol Needed To Understand This Powerful Use Case:

Programmable Key Pair (PKP): A Programmable Key Pair (PKP) in Lit Protocol is a public/private key pair generated through distributed key generation, whose usage conditions can be governed by Lit Actions. In the context of this use case a PKP is utilized to seamlessly onboard a user to the application through a social login, as well as, decrypt the final travel information.

Access Control Conditions (ACCs): ACCs define the criteria under which encrypted data can be decrypted. These conditions ensure that only authorized entities can access the data. For instance in the context of the use case, the ACC for decrypting the payment information can specify that it can only be decrypted by a specific Lit Action corresponding to the AI agents’ IPFS CID (Agent 1 Event Booking AI Agent has IPFS CID x01234, Agent 2 Flight Booking AI Agent has IPFS CID x43210, and Agent 3 Hotel Booking AI Agent has IPFS CID x54321) .

Lit Action (LAs): A Lit Action is an immutable JavaScript program that can be used to govern signing, decryption, and compute on Lit Protocol. Lit Actions are a powerful feature of Lit Protocol, that can be used for generalized computations such as making API calls, automating trading strategies, and more. Unlike Programmable Key Pairs (PKPs), which are primarily used for signing transactions, Lit Actions offer a more comprehensive solution for processing tasks within decentralized applications. By allowing each node’s Trusted Execution Environment (TEE) to handle decryption, it effectively creates a confidential compute setup; These capabilities make Lit Actions particularly suitable for workflows requiring complex computations, and secure data handling.

In the context of the travel booking use case described, Lit Actions enable AI agents to securely communicate and process booking information across different stages of the workflow. Each Lit Action decrypts the needed payment information by satisfying the ACC and decrypts the needed travel information by satisfying the ACC. Then the Lit Action calls the desired AI agent’s Remote Procedure Call (RPC) endpoint to execute the request, and returns an encrypted message holding the execution result.

Entire Simplified Workflow Process

Subdivided Detailed Workflow Processes

User Authentication and PKP Minting: Before the workflow begins, the user must first log in using their desired authentication method, such as Google. Upon successful login, a Programmable Key Pair (PKP) is minted returning a PKP Public Key of x09876 that is paired with the user’s Google account. This PKP is an ERC-721 token, which the orchestrator will use to decrypt data at the end of the booking process.

The orchestrator AI agent first encrypts the user’s payment information. This encrypted payment information is then sent to the Event Booking AI Agent (Agent 1) along with an ACC specifying that it can only be decrypted by a specific Lit Action corresponding to the AI agents’ IPFS CID, such as Agent 1 IPFS CID x01234, Agent 2 IPFS CID x43210, or Agent 3 IPFS CID x54321 can decrypt it.

Agent 1 (Event Booking AI Agent):

• IPFS CID: x01234.
• ACC Payment Definition : Payment data can only be decrypted by these specific Lit Actions IPFS CID x01234, IPFS CID x43210, or IPFS CID x54321.
• Decryption and Processing:
• The Event Booking AI Agent receives the encrypted payment information from the orchestrator and fulfills the ACC Payment Definition to receive the payment information.
• Within the Lit Action an RPC to the Event Booking AI Agent is made. The AI Agent then finds a ticket to purchase, uses the payment information, and completes the purchase.
• Once the ticket is purchased, all relevant information such as dates, type of ticket, and location is encrypted, and the ACC specifying the Lit Action with an IPFS CID x43210 (Agent 2’s Lit Action) can decrypt. This encrypted data is then sent back to the orchestrator.

Data Transfer to Flight Booking AI Agent (Orchestrator → Agent 2):

• The orchestrator receives the encrypted event ticket information from Agent 1.
• The orchestrator then forwards this encrypted data along with payment information to the Flight Booking AI Agent (Agent 2) with ACCs specifying Lit Actions.

Agent 2 (Flight Booking AI Agent):

• IPFS CID: x43210.
• ACC Payment Definition : Payment data can only be decrypted by these specific Lit Actions IPFS CID x01234, IPFS CID x43210, or IPFS CID x54321.
• Decryption and Processing:
• The Flight Booking AI Agent receives the encrypted payment information from the orchestrator and fulfills the ACC Payment Definition to receive the payment information.
• Within the Lit Action a RPC to the Flight Booking AI Agent is made. The AI Agent then uses the decrypted ticket information, finds and books the flights based on the dates of the ticket information, then encrypts the ticket information and the flight booking information.
• The batched encrypted flight booking information and ticket information are sent back to the orchestrator and can only be decrypted by the specific Lit Action corresponding to an IPFS CID x54321(Agent 3’s Lit Action).

Data Transfer to Hotel Booking AI Agent (Orchestrator → Agent 3):

• The orchestrator receives the batched encrypted flight booking and ticket information from Agent 2.
• The orchestrator then forwards this encrypted data along with the batched encrypted flight booking and ticket information ACC and the Payment Info ACC to the Hotel Booking AI Agent (Agent 3) with ACCs specifying Lit Actions.

Agent 3 (Hotel Booking AI Agent):

• IPFS CID: x54321.
• ACC Payment Definition : Payment data can only be decrypted by these specific Lit Actions IPFS CID x01234, IPFS CID x43210, or IPFS CID x54321.
• Decryption and Processing:
• The Hotel Booking AI Agent receives the encrypted payment information from the orchestrator and fulfills the ACC Payment Definition to receive the payment information.
• Within the Lit Action a RPC to the Hotel Booking AI Agent is made. The AI Agent uses the decrypted payment information and flight information to find and book the hotel reservation, then encrypts the payment information, flight information, and hotel information.
• The final batched encryption of these three data points is sent back to the orchestrator and can only be decrypted by the PKP Public Key that started the process originally (The Orchestrator x09876).

Orchestrator Final Decryption and User Information Delivery:

The orchestrator AI agent receives the batched encrypted data from Agent 3. It then decrypts this data using its own PKP, consolidating all the booking information, including payment, flight, and hotel details. Finally, the orchestrator sends the decrypted travel information back to the user, completing the booking process.

Importance of Lit Protocol within the context of AI Agents

While this example displays the power of integrating Lit Protocol into AI-driven travel booking systems, the potential for Lit protocol to significantly enhance security, privacy, and efficiency between AI agents goes far beyond that displayed here. Lit Protocol’s secure key management with threshold cryptography, token gating with bespoke ACCs, and privacy-preserving computation with Lit Actions– ensure user data is protected at every stage, safeguarding sensitive information and fostering trust in AI-driven solutions. That trust is not emplaced in the Agents but rather Lit Protocols decentralized network that only decrypts or signs if Access Control Conditions (ACCs) are satisfied. The power of Lit Protocol as a tool to manage interactions between Agents would crumble if not for Lit Protocol’s agnostic nature that permits it to operate on-chain and off-chain; Interoperability is essential for creating user-friendly, secure, and efficient use cases that pave the way for more secure and user-centric Artificial Intelligence. Bottom line is Lit Protocol could be the glue to maintain ethical privacy aware standards between AI Agents in Web 2 and 3.