# Privacy Auditing in Differential Private Machine Learning:
## 5 Discussion and Future Research
The use of data poisoning for auditing can be generalized to different models and algorithms, making it a versatile tool for evaluating the privacy of different machine-learning implementations [61]. However, it also poses challenges in terms of complexity, potential misuse, and the limits of the scope of application, which must be carefully considered in practice. Conducting data-poisoning attacks requires significant computational resources and expertise. Developing effective poisoning strategies can be complex and may not be feasible for all organizations [43; 61]. Data-poisoning attacks may not cover all aspects of privacy auditing. While they may reveal certain vulnerabilities, they may not address other types of privacy breaches or provide a comprehensive view of the overall security of a model [43]. Techniques developed for data poisoning in the context of audits could be misused by malicious actors to exploit vulnerabilities in ML models. This dual use raises ethical concerns about the impact of such research [43]. The effectiveness of data-poisoning attacks can vary greatly depending on the specific characteristics of the model being audited. If the model is robust against certain types of poisoning attacks, the auditing process may lead to misleading results regarding its privacy guarantees. Future research could focus on developing more robust data-poisoning techniques that can effectively audit DP models. By refining these methods, auditors can better assess the resilience of models to different types of poisoning attacks, leading to improved privacy guarantees. As federated learning becomes more widespread, interest in how data-poisoning attacks can be used in this context is likely to grow. Researchers could explore how to audit federated learning models for DP, taking into account the particular challenges posed by decentralized data and model updates. The development of automated frameworks that utilize data poisoning for auditing could streamline the process of evaluating differentially private models. Such frameworks would allow organizations to routinely assess the privacy guarantees of their models without the need for extensive manual intervention. There is a trend towards introducing standardized quantitative metrics for evaluating the effectiveness of DP mechanisms using data poisoning [63]. This could lead to more consistent and comparable assessments across different models and applications. Model inversion attacks can expose vulnerabilities in DP models by showing how easily an attacker can reconstruct sensitive training data from the model outputs. This helps identify vulnerabilities that may not be obvious through standard auditing methods [58]. The model inversion serves as a benchmark for evaluating the effectiveness of different DP mechanisms. By evaluating a model's resilience to inversion attacks, auditors can assess whether the models fulfil the privacy guarantees, enhancing trust in privacy protection technologies [200]. By using model inversion techniques, auditors can quantitatively measure the privacy guarantees provided by DP algorithms [199]. This empirical approach provides a better understanding of how well privacy is maintained in practice. The insights gained from the model inversion can inform developers about necessary adjustments to strengthen privacy protection. This iterative feedback loop can lead to continuous improvement of model security against potential attacks. Model inversion techniques can be applied to different types of ML models, making them versatile tools for evaluating the privacy of different implementations. Performing model inversion audits can be computationally expensive and time-consuming, requiring significant resources for both implementation and analysis. This can limit accessibility for smaller organizations or projects with limited budgets [48]. Model inversion methods often rely on strong assumptions about the attacker's capabilities, including knowledge of the architecture and parameters of the model [198].