## 3 Methodology
### Categorization of Sensitivity and Security
To validate the categories developed and the analysis capabilities of the GPT-3.5 and GPT-4 APIs, which at the time of writing were the most efficient GPT models available and promptable via API, we compiled a dictionary of 200 variable names, equally divided among the non-sensitive, low-sensitivity, medium-sensitivity, and high-sensitivity categories. In preparing the dictionary, we introduced challenges for the models. Some variant names had deliberate misspellings, some were in foreign languages like Hungarian, German, or Italian, and some combined sensitive words with less sensitive endings. The GPT-3.5 API incorrectly classified 45.5% of the dictionary, with the majority of cases being trivial. In contrast, GPT-4 only made errors in 23.5% of the cases, and a deeper examination of the errors revealed that it only failed on the explicitly difficult terms, and in more than half of the cases, it correctly identified the errors as sensitive data but incorrectly categorized the exact category. Although both models were used throughout our investigations, preliminary results suggested that GPT-4 might be able to produce more accurate results by analyzing codes, whereas GPT-3.5 appeared more prone to failure in all but the most straightforward cases. The aim of this preliminary assessment was not to successfully evaluate a domain-specific set of variables with the models. We merely wanted to see how effectively the models could understand the rules outlined and to assess in advance whether there were any significant differences in the interpretive abilities of the two models. A more extensive or domain-specific dictionary in terms of methodology and experiments would not have changed the assumptions reached here. Additionally, we have sought to align the application's protection scale with the three-level sensitivity scale. Although this alignment assumes some level of security measures in the data path to the front-end application, such as two-factor authentication, front-end applications might offer supplementary measures that can help mitigate the risk of unauthorized access, especially when server-side and data path protections have vulnerabilities. These include isolation of functionality combined with strict role handling and access control. The scale presented is as follows:
* **Protection Level 0**: The component has no protection at all. * **Protection Level 1**: Bare-bones authentication: the application checks whether the user trying to access the resource is logged in to the application. * **Protection Level 2**--RBAC [36]: In addition to being logged in, the user has different roles that define their scope of privileges within the application. * **Protection Level 3**--ABAC [37]: In addition to the login and possible role scopes, other attributes such as time, physical location, or type/ID of device used are checked before granting access. In our experiments, we attempted to identify instances in which the AI-based analysis of the source code produced pairings in which these two values did not match, i.e., in accordance with the definition of CWE-653 failure, a service dealing with sensitive data could be
accessed and called by a component with a protection level lower than the sensitivity level of the data due to a lack of proper isolation.