AI and data use

1. Scope of this policy

This AI and Data Use Policy explains how SwiftSafe ("SwiftSafe", "we", "us", "our") uses data in and around the artificial intelligence that powers Prava AI. "SwiftSafe" means the SwiftSafe company that contracts with the Customer, as set out in the Terms of Service: SwiftSafe LLC, our United States office, for Customers based in the Americas, and SwiftSafe Cybersecurity Technologies India Pvt Ltd, our headquarters in India, for all other Customers. Both companies follow this policy, and model training on a Customer's data stays in that Customer's region whichever of them is involved. It applies to every Customer and Authorised User of the Platform and the Services, and forms part of the Terms of Service. Capitalised terms have the meaning given in the Terms of Service.

This policy should be read with the Privacy Policy, which explains how we handle Personal Data for which we are the Data Fiduciary, and the Data Processing Addendum ("DPA"), which governs our processing of Personal Data on the Customer's behalf. If this policy conflicts with a signed Order Form or a signed DPA, the signed document prevails for that Customer. Nothing in this policy limits any right that individuals have under Applicable Law.

2. About Prava AI and its models

Prava AI is an enterprise cybersecurity platform built around models developed by SwiftSafe. At a high level, it uses two kinds of model:

• The Prava large language model (LLM). A proprietary language model adapted for security work. It powers the Prava AI assistant, which lets Authorised Users ask questions in natural language, and produces automated triage, investigation summaries, recommendations, detection rules (such as YARA and Sigma), scripts, policies and reports. The LLM works by predicting likely sequences of text based on patterns learned during training and on the context supplied to it, such as the user's prompt and relevant data retrieved from the Customer's tenant.
• Detection and analytics models. Machine-learning models that score behaviour, files, network traffic, email, configurations and threat intelligence for signs of compromise, misconfiguration or policy violation. They include classifiers, anomaly-detection models that learn a baseline of normal activity for an environment, and models that cluster related events into incidents.

These models work together with deterministic rules, threat intelligence feeds, policy engines and human analysts. The models do not have independent goals. They act within the permissions, scope and response policies configured by the Customer.

3. Data we use

This policy covers the following categories of data, each defined in the Terms of Service:

• Customer Data: data the Customer or its Authorised Users submit to or make available through the Platform, such as files, email content, documents, evidence, configurations and policies.
• Telemetry: technical data collected by Agents, connectors, sensors and integrations from the Customer's endpoints, servers, applications, cloud accounts, networks, email systems and IoT/OT devices, such as process, file, network, authentication and log events.
• Service Data: data generated by the operation of the Platform, such as detections, alerts, verdicts, model scores, performance metrics, error logs and diagnostic data.
• Usage analytics: information about how Authorised Users interact with the Platform, such as features used, pages viewed, actions taken, session duration and device and browser information. Website cookies are described in the Cookie Policy.
• Feedback: ratings, corrections, comments, false-positive and false-negative markings, and other feedback on detections or Outputs.
• Prompts and Outputs: questions, instructions and context submitted to the Prava AI assistant, and the responses, summaries, rules, scripts and reports it produces.

Some of this data will include Personal Data, for example usernames, email addresses, IP addresses and message content. The categories of Personal Data and Data Principals are set out in section 5 of the DPA.

4. Real-time processing

Effective security depends on analysing data as it is generated. When a Module is enabled, Prava AI processes Customer Data and Telemetry continuously and in real time. This includes:

• Stream analysis: evaluating events as they arrive against detection models, rules and behavioural baselines.
• Enrichment: adding context such as asset ownership, user identity, geolocation of IP addresses, reputation of files, domains and URLs, vulnerability data and threat intelligence.
• Correlation: linking related events across endpoints, identities, cloud accounts, email and networks, and with dark-web and open-source threat intelligence, to build incidents and attack timelines.
• Autonomous actions: where the Customer has enabled them, taking response actions such as isolating a host, terminating a process, quarantining a file, disabling a session or blocking a message, according to the response policies the Customer has configured. Section 10 explains the controls that apply.

Real-time processing is necessary to deliver the Services and cannot be switched off for a Module that is in use. The Customer controls which assets, users and data sources are in scope, and can adjust collection settings and exclusions within the Platform.

5. What we use data for

We use the data described in section 3 for the following purposes:

• Delivering the Services: operating the Modules the Customer has enabled, generating detections, alerts and Outputs, carrying out response actions and producing reports.
• Securing the Platform: protecting the Platform, our customers and our personnel against misuse, fraud and attack, and investigating security incidents.
• Support: troubleshooting, answering support requests and providing incident response and other professional services.
• Analytics: understanding how the Platform is used and how it performs, measuring detection quality, planning capacity and improving the user experience.
• Research and model improvement: researching new detection techniques, and training, fine-tuning, evaluating and benchmarking our models. This includes red-teaming, which means deliberately testing our models with adversarial inputs to find weaknesses, unsafe behaviour or leakage of data, so that we can fix them.
• Collective defence: using non-personal security artefacts, such as malware hashes, indicators of compromise, detection signatures and malicious infrastructure, stripped of any Personal Data and Customer Confidential Information, to improve protection for all customers.
• Legal compliance: meeting our obligations under Applicable Law, including the CERT-In Directions of 28 April 2022, and responding to lawful requests.

We do not sell Customer Data or Telemetry, use it for advertising, or use it to build profiles of individuals for purposes unrelated to security. For processing on the Customer's behalf we act as Data Processor. For research, model improvement and collective defence we determine the purpose and act as Data Fiduciary, as explained in section 3 of the DPA.

6. Your agreement and notice to individuals

6.1 What you agree to

When a Customer accepts the Terms of Service, signs an Order Form, creates an account, installs an Agent or uses the Services, the Customer agrees, and each Authorised User acknowledges, that SwiftSafe may:

• process Customer Data and Telemetry in real time to deliver the Services, as described in section 4;
• collect usage analytics, as described in section 3; and
• use Customer Data, Telemetry, Service Data, feedback, prompts and Outputs to operate, secure, improve and develop Prava AI, including training, fine-tuning and evaluating its models, subject to the safeguards in section 7 and any restriction agreed under section 8.

We present this information before acceptance so that the agreement is informed and specific to these purposes. Where we rely on the consent of an individual Authorised User for any of our own processing, for example optional analytics cookies, that consent can be withdrawn at any time as described in the Privacy Policy. Withdrawing consent does not affect processing that was lawful before withdrawal, and may mean that some features no longer work.

6.2 Customer's duty to give notice and obtain consent

Prava AI monitors devices, accounts, email and activity of people within the Customer's organisation and others who interact with it. The Customer, as Data Fiduciary for that data, is responsible for:

• giving clear notices to its employees, contractors, end users and other affected individuals about the monitoring, including workplace monitoring, and about the uses described in this policy, including model improvement;
• obtaining any consent required by Applicable Law, or identifying another lawful basis for the processing, such as a legitimate use under section 7 of the Digital Personal Data Protection Act, 2023; and
• handling requests from those individuals to exercise their rights.

6.3 Individuals' rights

Individuals whose Personal Data is processed through Prava AI keep all their rights under Applicable Law, including rights to withdraw consent, to access information about the processing, to correction, completion, updating and erasure, to nominate another person to exercise their rights, and to grievance redressal. Nothing in this policy or in any agreement waives those rights. Requests about Customer Data should normally be made to the relevant Customer. Requests about data for which we are the Data Fiduciary, including our use for model improvement, can be sent to privacy@prava.dev or to our Grievance Officer at grievance@prava.dev. Data that has already been irreversibly aggregated or incorporated into model parameters may not be capable of individual extraction, as explained in section 7.

7. Safeguards for model improvement

When we use data for research and model improvement, we apply the following safeguards:

• Data minimisation: we use only the data reasonably needed for the improvement task and prefer synthetic, public or SwiftSafe-generated data where it will do.
• De-identification and pseudonymisation: wherever reasonably possible, we remove or replace direct identifiers such as names, email addresses, usernames, hostnames and internal IP addresses with tokens before data enters a training or evaluation dataset. Re-identification keys, where kept, are stored separately with restricted access.
• Aggregation: where individual records are not needed, we use aggregated statistics, such as event frequencies or detection rates, rather than raw records.
• Removal of secrets and credentials: we apply automated scanning and filtering to remove passwords, API keys, access tokens, private keys, session cookies and similar secrets before data is used for training.
• Exclusion of sensitive content: we take reasonable steps to exclude from training, in identifiable form, special categories of data that may incidentally appear in Telemetry, email or forensic images, such as health or financial information.
• Access controls: training and evaluation datasets are held in restricted environments, accessible only to authorised personnel with a need to know, and access is logged.
• No cross-customer disclosure: we design, train and test our models so that Customer Confidential Information and identifiable Personal Data of one customer are not disclosed to another customer through Outputs or otherwise. This includes red-team testing for memorisation and data leakage, and tenant isolation in how the assistant retrieves context.
• Local data centres & zero foreign storage: we process and store each Customer's data, including Customer Data, Telemetry and Personal Data, strictly in local data centres in the Customer's designated region or country, without storing in foreign countries. Training, fine-tuning and evaluation on a Customer's data take place entirely within that sovereign local region.
• What crosses regions: only two kinds of data are used across regions. The first is non-personal security artefacts, such as malware hashes, indicators of compromise, detection signatures and malicious infrastructure, once stripped of any Personal Data and Customer Confidential Information. These may be shared across our customer base to detect and block threats, and are not attributed to the Customer they came from. The second is anonymised, aggregated model parameters or weights, which do not contain recoverable Personal Data or Customer Confidential Information.
• Retention: training datasets are reviewed periodically and data that is no longer needed is deleted. Models trained on data cannot always "unlearn" individual records. We address this by de-identifying data before training and by excluding data from future training runs when a restriction applies.

8. Opt-out and restriction options

Enterprise customers can negotiate restrictions on our use of their data in an Order Form or a signed DPA. Options we can offer include:

• opting out of the use of Customer Data, Telemetry, prompts and Outputs for training and fine-tuning our models;
• limiting model improvement to aggregated or fully de-identified data only;
• the choice of region where offered, recorded in the Order Form (all Customer data is kept in the Customer's region in any case);
• shorter retention periods for prompts and conversations; and
• dedicated deployment or customer-managed encryption keys, where available.

Customers on Pro and Max plans can contact privacy@prava.dev to discuss options available to them.

What an opt-out changes: from the effective date, the Customer's content will not be added to datasets used to train or fine-tune our models, and data already in training datasets that is still identifiable as coming from the Customer will be removed from future training runs.

What an opt-out does not change: we will still process data in real time to deliver, secure and support the Services; still collect usage analytics and Service Data needed to operate and maintain the Platform; still use non-personal security artefacts for collective defence unless the Order Form says otherwise; and still use the Customer's data to evaluate the Services it receives, such as measuring detection accuracy for that Customer. An opt-out does not remove what models have already learned from de-identified or aggregated data before the opt-out took effect.

9. Third-party models

Prava AI is built primarily on models developed by SwiftSafe. Where we use models or AI services provided by third parties for particular features, they are listed at [Third-party AI models and providers used, if any] and, where they process Customer Personal Data, in the [Sub-processor list]. Where we use a third-party model:

• we will engage the provider on terms that prevent it from using Customer Data, prompts or Outputs to train or improve its own models, unless the Customer has expressly agreed otherwise in writing;
• the provider will act as our Sub-processor under the DPA, with the notice and objection rights set out there, and will process Customer data only in the Customer's region; and
• we remain responsible for the feature as part of the Services.

Open-source or open-weight models that we run on our own infrastructure are treated as our own models for the purpose of this policy.

10. Human oversight of autonomous actions

Prava AI can take actions that affect the Customer's systems and people. We provide controls so that the Customer keeps meaningful human oversight:

• Configurable autonomy: the Customer decides, for each type of action and asset, whether Prava AI may act automatically, must seek approval first, or may only recommend. High-impact actions are set to require approval by default.
• Scope and exclusions: the Customer can exclude critical systems, such as OT controllers, production databases or executive devices, from autonomous containment.
• Audit trail: every autonomous action is logged with the triggering evidence, the model or rule involved, the time and the outcome.
• Reversal: containment actions such as host isolation and file quarantine can be reversed through the Platform.
• Human responders: for DFIR and penetration testing, SwiftSafe's human professionals supervise the work, and offensive testing is carried out only within written authorisation and agreed scope, as set out in the Module Terms.

The Customer is responsible for reviewing and approving its response policies, monitoring autonomous actions, and making final decisions with legal or employment consequences for individuals. Prava AI Outputs should not be the sole basis for disciplinary action, dismissal, reports to law enforcement or other decisions that significantly affect a person without human review.

11. Accuracy and the limits of Outputs

AI Outputs are probabilistic. They are generated from patterns, not from certain knowledge, and may be incomplete, out of date or wrong. In particular:

• the LLM may "hallucinate", meaning it can produce statements, references, indicators or code that look plausible but are false;
• detection models will produce false positives (benign activity flagged as malicious) and false negatives (malicious activity not detected);
• generated rules, scripts and remediation steps may have unintended effects if run without testing; and
• compliance mappings and policy drafts are aids to the Customer's own assessment and are not legal advice or a certification of compliance.

The Customer should review Outputs before relying on them, test generated code and rules in a safe environment before deployment, and apply professional judgement. No security product can prevent every attack. The warranties and limitations of liability that apply to Outputs are set out in the Terms of Service. We welcome feedback on inaccurate Outputs, which helps us improve our models.

12. Prohibited AI uses

The Customer and its Authorised Users must not use Prava AI or its Outputs in breach of the Acceptable Use Policy. In particular, they must not use the Platform to attack systems without authorisation, develop or deploy malware against third parties, conduct unlawful surveillance of individuals, attempt to extract other customers' data or our model weights, circumvent the models' safety controls, or use Outputs to make unlawful decisions about individuals. We may monitor for and act against misuse, as described in the Acceptable Use Policy.

13. Prompt and conversation retention

Prompts submitted to the Prava AI assistant and the resulting Outputs are stored in the Customer's tenant so that Authorised Users can view conversation history and investigation records, and so that actions can be audited. Unless a different period is agreed in an Order Form:

• conversation history is retained for the life of the Customer's subscription, and Customer administrators can delete conversations through the Platform where that feature is available;
• deleted conversations are removed from active systems within 30 days and from backups in line with our backup cycle;
• prompts and Outputs that have been de-identified for model improvement under section 7 may be retained in training and evaluation datasets after deletion from the tenant, unless the Customer has opted out under section 8; and
• at the end of the subscription, conversation data is returned or deleted under section 14 of the DPA, subject to retention required by Applicable Law.

14. Ownership of models and Outputs

As between the Customer and SwiftSafe, the Customer retains its rights in Customer Data. SwiftSafe owns the Platform, the Prava AI models, their weights and parameters, training methods, and all improvements to them, including improvements made using data under this policy. Training a model on data does not give the Customer any ownership interest in the model.

Subject to the Terms of Service and payment of fees, SwiftSafe assigns to the Customer any rights it has in Outputs generated for the Customer, or, where assignment is not possible, grants the Customer a perpetual, worldwide licence to use them for its internal business purposes. Because Outputs are generated by a model, similar Outputs may be produced for other customers, and the Customer does not acquire exclusive rights in generic content, such as common detection rules or standard remediation steps. Detailed terms are in the Terms of Service.

15. Transparency and explainability

We aim to make Prava AI understandable to the people who use it. In particular:

• Outputs generated by AI are labelled as such in the Platform;
• detections and alerts show, where technically feasible, the evidence, indicators, rules and contributing factors behind them, and a confidence or severity score;
• investigation summaries link back to the underlying events so that analysts can verify them;
• autonomous actions record the reason they were taken; and
• on request, we will provide Customers with documentation describing the general design, intended use, known limitations and evaluation approach of the models used in the Modules they subscribe to, subject to protection of our trade secrets and security-sensitive information.

Machine-learning models cannot always give a complete, human-readable explanation of each individual result. Where that is so, we provide the most useful supporting evidence we can.

16. Responsible AI principles

We develop and operate Prava AI according to these principles:

• Security and safety first: our models are built to defend, and we test them for misuse, prompt injection, data leakage and unsafe behaviour before and after release.
• Privacy by design: we minimise data, de-identify it for model improvement, and keep customer tenants isolated.
• Human accountability: people remain accountable for consequential decisions, and the Customer controls the level of autonomy.
• Fairness: we seek to avoid models that treat individuals differently on the basis of protected characteristics, and we focus detections on behaviour and technical indicators rather than on who a person is.
• Transparency: we explain what our models do, what data they use and what their limits are, including through this policy.
• Reliability: we evaluate models against benchmarks and real-world feedback before deployment, monitor their performance in production, and roll back changes that reduce quality.
• Accountability: we maintain internal governance for AI development, including review of significant model changes and a route for reporting concerns to legal@prava.dev.

17. Regulatory alignment

India. We process Personal Data in accordance with the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025, and the Information Technology Act, 2000 and rules made under it. We follow the approach of the India AI Governance Guidelines issued by the Ministry of Electronics and Information Technology, which emphasise trust, people-first design, accountability, safety, fairness and understandability, and we will review our practices as Indian guidance develops. These guidelines are not, at the date of this policy, a binding certification scheme, and we do not claim certification against them.

European Union. Where the EU Artificial Intelligence Act (Regulation (EU) 2024/1689) applies to our models or to a Customer's use of them, we will meet the obligations that apply to us, such as transparency obligations and AI literacy measures, as they take effect. Prava AI is designed for cybersecurity purposes and is not intended for uses that the AI Act classifies as prohibited. Whether a particular use is high-risk depends on how the Customer deploys it, for example in employment-related decisions or as a safety component of critical infrastructure. Customers deploying Prava AI in such contexts should tell us, so that we can discuss the information and support they need to meet their own obligations as deployers.

Other jurisdictions. We monitor AI and data protection laws in the other jurisdictions where our customers operate, including the EU and UK GDPR and US state laws, and will update this policy as needed.

18. Changes and contact

We may update this policy as our models, the Services and the law change. We will post the updated policy with a new "last updated" date and, where a change materially expands the ways we use Customer Data or Telemetry for model improvement, we will give Customers at least 30 days' notice before it takes effect. A change will not apply to a Customer that has agreed a contrary restriction in an Order Form or DPA.

Questions about this policy can be sent to privacy@prava.dev or legal@prava.dev. Grievances can be raised with our Grievance Officer at grievance@prava.dev. Security vulnerabilities can be reported to security@prava.dev. More information is available in the Legal centre.