🗃️
PropScreen
  • PropScreen Overview
  • Introduction
    • The Problem
    • Problem Importance and Impact
    • Solution Overview
      • How Propscreen Addresses the Problem
      • Use Cases
      • User Personas
  • System Architecture
    • Core Components of Propscreen
      • PropScreen's Checks
      • Context Strings Database
      • Hashed Organizational Sensitive Information
      • Interdiction Log Database (Reports)
    • Architecture Overview
    • Sequence Diagrams by Use Case
      • Use Case 1 Sensitive Information Disclosure Interdiction
      • Use Case 2 Logging of Interdiction Events
  • Project Considerations
    • Threat Modeling
      • Key Threats
      • Key Threat 1
      • Key Threat 2
      • Key Threat 3
    • Secure by Design
    • Alternative Solutions
      • NER and Regex Based Scans
      • Traditional Data Loss Prevention
    • PropScreen's LLM Implementation
  • The Proof of Concept
    • Demo Video
    • Try the Proof of Concept
  • Going Forward...
    • SIEM Integration
    • Role Based Access Control Dependent Response Filtering
    • The Good, The Bad, and the Learning
Powered by GitBook
On this page
  1. System Architecture
  2. Sequence Diagrams by Use Case

Use Case 1 Sensitive Information Disclosure Interdiction

PreviousSequence Diagrams by Use CaseNextUse Case 2 Logging of Interdiction Events

Last updated 10 months ago

Below is a high level sequence diagram to illustrate how the first use case of sensitive information interdiction is handled in PropScreen. The numbers on the sequence diagram will correspond to the more detailed description on this webpage.

  1. User sends Prompt - This is the action of the user entering their prompt into their organizational application and sending the request.

  2. Prompt Forwarded - Once the prompt has been sent by the user, the application will forward the prompt to PropScreen.

  3. Prompt Sent to LLM - The prompt is then immediately forwarded to the organization's LLM.

  4. LLM Response Returned - The LLM returns its response to PropScreen, which processes the response to be scanned.

  5. Response Scanned for General SI - The response is scanned by LLM Guard Sensitive Info Check, regardless of the outcome the result is saved and the LLM response is sent to the next check.

  6. Proceed to next check - PropScreen proceeds with it's next check, the search for the existence of any "context strings" inside of the LLM response.

  7. Response Scanned for Context Strings- Context String Check accesses the Context String DB and determines if there are any matches between the tokens in the response and the items in the database.

  8. Response sent to client - In the event that there were not matches in either check the model response is deemed safe and the LLM response is sent back to the LLM Application.

  9. User receives reply - The response is displayed to the user by the LLM Application.

  10. Proceed to final check - If either one of the checks find at least one match, then the response proceeds to the final scan.

  11. Response scanned for matching hashes - The final check of Hashed Organizational Sensitive Information Check hashes each token in the LLM response and checks it against the collection of hashes found in the Hashed Organizational Sensitive Information database.

  12. Response Returned - If there were not matches found in step 11 then the response is deemed safe, a false positive, and the LLM response is sent back to the LLM Application.

  13. User receives reply - The response is displayed to the user by the LLM Application.

  14. Response Returned - If at least one match was found in step 11 then the response is deemed dangerous, a true positive, and the LLM response is replaced with an error message. This error message is sent back the the application.

  15. User receives error message - The error message is displayed to the user by the LLM Application.

Sequence Diagram for First Use Case, Sensitive Information Interdiction (Click to Enlarge)