Trust and security

Six facts, as of 21 October 2026.

Deployment

0

foreign cloud services needed to run any product. Everything runs on-premise or air-gapped on Indian soil.

Personal data

Never

stored: identifiable personal data of private persons. The access policy denies it with no override.

Audit

3 years

for the hash-chained audit log. Its checkpoint roots carry no personal data and are kept permanently.

Sensor tracks

90 days

then deleted, unless a track is attached to an incident under a legal hold.

Approval

2 people

to search records about people or copy sensor tracks out. Approvals are single-use and expire in 24 hours.

Public site

0 cookies

and no analytics. Pages load fonts from Google Fonts; pages with maps load basemap tiles from Esri.

Three ways to run it. None needs a foreign cloud.

Model	Where it runs	Network	Updates	Typical user
Air-gapped	A server at the unit or headquarters	None. Public data arrives on approved media; pipelines rebuild from that cache with `--offline`.	Release bundles carried in, checked against published hashes	Border posts, sensitive sites
On-premise	The customer's servers in an Indian data centre	Outbound only, through the customer's proxy, to the public data sources each product lists	Customer-controlled rollout	Headquarters, state agencies, district control rooms
Public pages	Static files on Vercel's content delivery network. No product depends on it.	Read-only for visitors	Continuous	Citizens, researchers, press

The stack is static web pages, Python pipelines and JSON files with open schemas. There is no database server to expose and no remote control channel. Signed release bundles and a software bill of materials for each release are in build.

Every record belongs to a data class with a retention period that the software enforces.

Data class	Personal	Kept	On expiry	Why
Public OSINT	No	2 years	Delete	Public documents are kept two years for trend analysis and can be fetched again from the source.
Aggregated statistics	No	10 years	Archive	No record-level data. Kept for long-run trends and transparency reports.
Sensor tracks	No	90 days	Delete	Kept only for operational need. A track attached to an incident moves under a legal hold.
Simulated	No	30 days	Delete	Regenerable from the recorded seed.
Environmental	No	10 years	Archive	Long records are needed for climatology baselines.
Personal, redacted	Yes	1 year	Delete	Erased once the purpose is served (DPDP Act 2023 s.8(7)).
Personal, identifiable	Yes	Never stored	Never stored	Red line 3. Not collected, not stored, not served. Always denied.

Source: Sakshi access policy, /dashboard/data/sakshi/policy.json, version 1.0.0, effective 21 Oct 2026.

Sakshi, the witness: every action recorded, every sensitive request bound to a purpose.

Sakshi

The audit chain

Each operator action becomes one entry: time, actor, action, declared purpose, resource.
Each entry is hashed with SHA-256 over canonical JSON (RFC 8785) and carries the previous entry's hash, so an edit, deletion or reordering breaks the chain.
Every 16 entries a checkpoint records a Merkle root (RFC 6962). Roots published outside the system, for example in our transparency report, let anyone detect a rewrite of everything before them.
A verifier checks the whole chain, and inclusion proofs show a given entry is in it without revealing the rest.

Status: library and tamper tests written; integration into each product in build.

Purpose and approval

Disaster response: needs an incident or event ID, at most 30 days.
Interdiction operations: needs a case, FIR or operation reference, at most 30 days.
Search and rescue: needs an incident ID, at most 7 days.
Oversight and audit: needs an audit or inquiry reference, at most 90 days.
Training and public research: public, aggregate, environmental or simulated data only.

Any deny wins; unknown means deny. Person-level searches and copies of sensor tracks need a second approver who is not the requester. Requests that select people by religion, caste, ethnicity, language or origin are refused and the refusal is logged.

Where we stand under India's data protection and cyber security rules.

Digital Personal Data Protection Act, 2023. The DPDP Rules were notified on 13 November 2025. Rules on the Data Protection Board applied at once, consent managers follow on 13 November 2026, and the core duties (notice, security safeguards, breach notice, rights) apply from 13 May 2027 (Hogan Lovells Cadwalader). We build to those duties now.

Our role. When an agency runs our software on its own data, the agency decides the purpose and we act as its processor. For the public-record corpus we compile ourselves, we treat ourselves as a Data Fiduciary.

Exemptions do not lower our bar. Section 17(1)(c) lifts consent and notice duties for the prevention and investigation of offences, but the duty to keep personal data secure still applies (DPDP Act s.17). Our products apply purpose binding, redaction and retention whether or not an exemption is available to the user.

Security safeguards. Rule 6 asks for encryption, access control and one year of logs. Penalties for failing to keep reasonable safeguards reach ₹250 crore per breach (Schedule). Our audit chain is kept three years.

CERT-In. The 28 April 2022 directions require reporting cyber incidents within 6 hours, keeping ICT logs for 180 days in India, and synchronising clocks to NIC or NPL time servers (CERT-In). We follow them for our own systems and support customers in following them for theirs.

Proportionality. The Supreme Court's test for any intrusion on privacy asks for legality, a legitimate aim, proportionality and procedural safeguards (Puttaswamy, 2017). Purpose tickets and the audit chain give users a record that answers the last two.

This section explains our position. It is not legal advice.

Habits that keep the attack surface small.

No web framework. Pages are plain HTML, CSS and JavaScript; every string from data is escaped before it reaches the page.
Third-party browser code is limited to pinned, exact versions of mapping and graph libraries from two public CDNs.
The public site sends security headers: no content sniffing, no framing, strict transport security, a strict referrer policy, and camera, microphone and payment access switched off.
Pipelines use a short list of Python packages, explicit timeouts, and cached responses, and their tests run without a network.
Secrets are never committed to the repository.
The public demo of the console uses a password check in the browser. It is a demo gate, not access control, and the demo shows only public data and labelled simulations. Customer deployments use the customer's own sign-in on their own network.

Found a vulnerability? Tell us at security@trinetra.in.

What to send

The page or component, steps to reproduce, what an attacker could do, and how to reach you. A proof of concept helps; a working exploit against someone else's data does not.

What we promise

A reply within 2 working days and an assessment within 10. Critical issues fixed within 30 days. We agree a public disclosure date with you, normally within 90 days, and credit you if you wish. We do not run a paid bounty yet.

Safe harbour

If you act in good faith, stay in scope, avoid privacy harm and service disruption, and give us time to fix, we will not pursue or support legal action against you.

In scope: This website and its pages under trinetra.in and trinetrahq.com, the public product pages and data files, and our open-source SDK.
Out of scope: Denial of service, social engineering, physical attacks, automated scanner output without a demonstrated issue, and systems run by our customers. Report those to the customer, or to CERT-In.
Other contacts: Data protection requests: privacy@trinetra.in. Concerns about our doctrine: oversight@trinetra.in.