Security Policy

1. Who this is from

This Policy is published by Nirvest Tech Private Limited ("Nirvest", "we", "us"), a company incorporated in India, CIN U62011DL2026PTC468686. It does two things: it tells you how to report a security problem to us and what you can expect from us if you do, and it lists the security protections we have actually built. It should be read with our Privacy Policy (especially Section 12, Security) and Terms and Conditions, and it agrees with the plain-English page at nirvestlens.com/security. If the two ever differ, tell us, and the more cautious statement applies until we fix it.

Nirvest is early. We would rather tell you plainly what we do and do not have than imply more.

2. Scope

This Policy covers security reports about:

• Public website: nirvestlens.com
• Nirvest Lens (the application): app.nirvestlens.com
• Nirvest Wallet: wallet.nirvestlens.com
• Staff administrative console: admin.nirvestlens.com

It also covers the software that runs those surfaces. Other *.nirvestlens.com hostnames that we operate for email delivery or similar are in scope only if the problem lets someone attack the four surfaces above or our users.

Services run by other companies are not ours to authorise testing against. This includes Google and Microsoft sign-in, Paddle (our payment provider and Merchant of Record, and its checkout), our hosting, database, email, SMS and AI providers, and your own email provider. If you find a problem in one of those, report it to that company. If you are unsure whether it is theirs or ours, tell us and we will help route it.

3. How to report a vulnerability

Email support@nirvestlens.com with the word "SECURITY" in the subject line, and include:

• what you found and which address it is on;
• the steps to reproduce it, or a short proof of concept;
• what you think the impact is (for example, "I could read another Workspace's record");
• how to reach you, and whether you would like to be credited.

Please include as little personal data as possible in the report. Do not attach other people's data you came across; describe it instead.

We do not currently publish a PGP key, so please do not send sensitive material by encrypted email. Describe the problem and we will agree a safe way to share any further detail.

4. What we commit to

If you report in good faith and follow Section 6, we will:

1. Acknowledge your report within 3 business days.
2. Assess it and tell you whether we consider it valid, and keep you updated at least every 14 days until it is resolved, so you are never left waiting without word.
3. Fix valid issues as quickly as their severity warrants, and tell you when it is done.
4. Not take legal action against you, and not ask law enforcement to, for research that is carried out in good faith and within this Policy. If a third party starts action against you for research that followed this Policy, we will say publicly that your work was authorised.
5. Credit you in a thank-you note if you want it, once the issue is fixed. We will not publish your name without your agreement.
6. Coordinate disclosure with you: we ask you to give us a reasonable time to fix the problem before you publish anything. Our target is 90 days from your report, and sooner for issues that are easy to fix. If we need longer, we will explain why and agree a date with you. We will not ask you to keep a fixed problem secret indefinitely.
7. Handle your report in confidence. We use your report and your contact details only to deal with the problem and to stay in touch with you.

What we cannot promise. We do not run a bug-bounty programme and do not pay rewards at this time. We can offer thanks and, if you wish, credit (Section 4(5)). This Policy is a statement of our intent. It does not bind other people, such as a Workspace customer whose data you may have touched, a payment or infrastructure provider, or a regulator, and the law of your country may treat your actions differently from the way we do.

5. Coordinated disclosure

We prefer to fix the problem first and then talk about it openly. Once it is fixed, you are welcome to publish a write-up, and we will cooperate on timing and on removing anything that would put users at risk. If we confirm that personal data was affected, we will notify the people and authorities the law requires us to notify (see the Privacy Policy, Section 12); that obligation is ours and it may mean we need to publish or notify on our own timetable.

6. Rules for good-faith research

Please:

• test only against accounts and Workspaces you own or have the owner's permission to test. Create your own free test Workspace for this;
• stop and tell us at once if you reach data that is not yours, and do not read, copy, keep or share more of it than the minimum needed to show the problem;
• avoid anything that harms the Services or other users: no denial-of-service, no mass automated scanning that degrades the site, no spam, no changing or deleting data that is not yours;
• do not use social engineering, phishing, physical attacks or threats against our staff, customers or providers;
• do not move money, or abuse the referral, reward, Partner or Wallet systems to gain NT or earnings;
• do not use a vulnerability to keep access, pivot to other systems, or leave anything behind;
• comply with the law that applies to you.

Research that goes beyond these rules may not be covered by Section 4(4).

7. Out of scope

We will usually not treat the following as vulnerabilities, though you may still tell us if you think they matter:

• findings that need a rooted or jailbroken device, a malicious browser extension, malware already on the victim's machine, or physical access to an unlocked device;
• denial-of-service, volumetric attacks and rate-limit stress testing;
• spam or content problems in a Workspace that the Workspace's own administrator controls;
• missing security headers or settings on pages that hold nothing sensitive and give no practical attack, and "best practice" suggestions without a demonstrated impact (the Content Security Policy rollout is described in Section 8);
• reports from automated scanners with no analysis of whether the issue is real;
• the absence of a particular third-party certification, external audit or test (we do not represent that the Services hold any particular third-party certification or have undergone any particular external audit or test);
• known behaviour that is documented, for example that AI output can be wrong (Terms, Section 7);
• software versions or banner information that disclose nothing exploitable;
• self-inflicted issues such as a user pasting their own session cookie into someone else's browser;
• attacks that need an already compromised Google or Microsoft account for the victim;
• vulnerabilities in third-party services (Section 2);
• email-authentication policy findings (SPF, DKIM, DMARC) on domains we do not use to send mail to you.

8. Security protections we have built

Each statement below corresponds to something that exists in our product today. They are descriptions of the design, not a guarantee against every failure. No system is completely secure.

Workspace isolation. Every table that holds Workspace data carries the Workspace it belongs to, and the database itself refuses to return a row from another Workspace. This is enforced by the database engine on every query, not only in application code. Background jobs and the AI work on one Workspace at a time: every job carries the Workspace it belongs to, and the code that runs it works only on that Workspace's data. They run with wider database access than a member, so for them that limit is enforced by our code rather than by the database rule above. AI context, learned preferences and search results are never shared across Workspaces.

Sign-in. You sign in only with your Google or Microsoft account. Nirvest has no passwords of its own for members, so there is no Nirvest password to lose, and no magic-link sign-in. If your organisation disables an account or enforces its own multi-factor policy, that applies to Nirvest. Workspace Admins can also require two-factor authentication for all members of a Workspace, and members can see and revoke their active sessions.

Session cookies. The session cookie is HttpOnly (scripts running on a page cannot read it), Secure (sent only over HTTPS), and SameSite=Lax. It is shared across app., wallet. and nirvestlens.com by design so that the Wallet needs no second sign-in; it is not shared with the staff console, which has its own cookie. Our server code does not see the session cookie except where it has to. Details are in the Cookie Policy.

Security headers. Each of the four surfaces sends a set of browser security headers: HTTP Strict Transport Security (HTTPS only, including subdomains), a ban on being framed by other sites (clickjacking protection), X-Content-Type-Options: nosniff, a restrictive referrer policy, a restrictive permissions policy, and a Content Security Policy that uses a fresh per-request nonce for scripts on Lens, Wallet and the staff console. The Wallet's policy allows Paddle's checkout and nothing else third-party. The Content Security Policy is currently in monitoring mode while it is rolled out: browsers report any violations to us, and enforcement will follow. We do not give a date.

Encryption. Data is encrypted in transit (HTTPS) and the database is encrypted at rest. Authenticator secrets are encrypted in the database and backup codes are stored only as hashes. On top of that, much of your content is encrypted inside our application with a separate key for each firm, protected by a master key in Google Cloud's key service that cannot be exported. This extra encryption does not cover all content yet.

Audit log. Sensitive actions and exports are written to an append-only audit log recording who did what and when. Security events, such as sign-ins, are logged and deleted after 12 months; the records that show a Workspace was suspended for low balance, deleted, or had its kept NT balance restored are kept with no time limit (Privacy Policy, Section 10). The administrative audit log, which records what our staff do, is kept with no time limit, and our staff cannot edit or delete it.

Staff access is separate, restricted and recorded. The administrative console is a separate application on a separate domain with its own accounts and its own session; it is not reachable from a customer account. Every staff account requires an authenticator app. Staff sessions are short: they end after 30 minutes of inactivity and 12 hours at most. Riskier actions require a written reason and a fresh authenticator or backup code for each action (one code, one action), and the most sensitive can be performed only by a Super Admin. The console has no screen that shows your emails, documents, notes or the records in your Workspace; it shows accounts, statuses, counts and billing, and the messages, bug reports (including any screenshots) and form answers that you choose to send us. Separately from the console, the people who maintain the Services can reach the underlying database in order to keep the Services running. Support mode needs a written reason, is limited to one Workspace for at most 60 minutes, is logged, and adds only these fixed summaries: activity counts for the last 7 days; the last 50 background jobs and their statuses; the connected mailboxes, without their addresses, and their sync status; the active members with their roles; and notification counts. It never shows your emails, documents or notes. There is no feature that lets staff sign in as you. Repeated failed staff sign-ins lock the account and are rate-limited.

Payments. Card and payment details are collected by Paddle, our Merchant of Record, on Paddle's checkout. We do not receive or store full card details.

Internal security review. On 9 October 2026 our own team completed an internal review of the code and its security controls and addressed its findings, including the browser security headers and the HttpOnly session cookie described above.

9. What we have not done

To keep this Policy honest, and consistent with nirvestlens.com/security:

• You cannot yet choose the region where your data is stored, or bring your own encryption keys.
• Our extra layer of encryption does not cover all content yet.

If this is a requirement for you, tell us, and we will be straight about timing.

10. If something goes wrong

If a personal data breach affects you, we will notify you and the relevant authorities as the law requires (Privacy Policy, Section 12). Tell us immediately at support@nirvestlens.com if you suspect unauthorised access to your account (Terms, Section 4.4).

11. security.txt

We publish a security.txt file (RFC 9116) at https://nirvestlens.com/.well-known/security.txt so researchers and scanners can find this Policy. It contains:

• Contact: mailto:support@nirvestlens.com
• Expires: 2027-10-09T00:00:00.000Z
• Preferred-Languages: en
• Canonical: https://nirvestlens.com/.well-known/security.txt
• Policy: https://nirvestlens.com/security-policy

We renew the Expires date at least once a year.

12. Changes to this Policy

We may update this Policy. The "Last updated" date will change when we do. Researchers who have an open report with us will be told of changes that affect them.

13. Contact and governing law

Security reports: support@nirvestlens.com.

General and grievance contact: Vanshaj Sharma, Director and Grievance Officer, Nirvest Tech Private Limited, nirvest29@gmail.com.

This Policy is governed by the laws of India, and the courts at Delhi have exclusive jurisdiction over any dispute arising from it, in line with the Terms and Conditions, Section 24. If you are in another country, you may also have rights under the mandatory laws of your country that this Policy does not override.