Security

Version 1.0 — 9 September 2026

This page describes the security controls that exist in the Suraag platform today. It is written so that a procurement reviewer or an investigating officer can check each claim against the product. Where a control does not exist yet, this page says so.

1. The principle: raw video stays with you

Footage is uploaded to the Suraag server assigned to your organisation (or stays on your own premises for on-premises deployments). The GPU engine receives individual frames and object crops in memory while a job runs and keeps nothing. The cloud stores analysis — detections, crops, embeddings, plate reads — not your video archive. The language model used to phrase answers receives text only: never frames, never crops.

2. Access control

• Accounts and sessions. Users sign in with a username and password. Passwords are hashed with bcrypt; the policy requires at least 10 characters, rejects the username and a list of common passwords. Session tokens are signed JWTs valid for 24 hours, refreshable for at most 7 days from first sign-in. Changing or resetting a password, or disabling a user, invalidates every existing session within a minute.
• Sign-in protection. Sign-in is rate-limited per IP (20 attempts per 5 minutes) and locked after 5 failures for a username or 15 for an IP within 5 minutes. Every attempt, successful or not, is written to the audit trail.
• Roles. Four base levels — platform superadmin, organisation admin, investigator, officer — and organisation-defined roles that can only narrow a base level and choose which screens it sees. Roles restrict; the server enforces.
• Gated capabilities. Face matching, weapon-candidate flagging and cross-camera re-identification are off unless an administrator grants them to a named user. Uses are audited with a purpose and, where applicable, a case reference.
• Device tokens. Edge devices and enrolled phones authenticate with a separate long-lived device token issued once at enrolment from a single-use code. Only the SHA-256 of the token is stored; a device can be revoked instantly and a device token can never act as a user.
• API keys. The public /v1 API uses per-organisation keys with explicit scopes. Only the SHA-256 of a key is stored; the raw key is shown once at creation and can be revoked. Every call is audited.
• Production guards. The API refuses to start in production with a default or short signing secret, or with the analysis engine in mock mode; API documentation endpoints are hidden; cross-origin access is restricted to the platform's own origin.

3. Tenant isolation

Every organisation is a tenant. Every camera, source, job, event, report, case, watchlist, device, API key, audit row and user carries the tenant identifier, and every query in the console and API is filtered by it on the server. Single-record lookups across the boundary return not found rather than forbidden, so the existence of another organisation's records is never confirmed. Within a tenant, officer-level users see only footage they uploaded themselves. Signed media links can be bound to a tenant and are refused to a signed-in user of another.

4. Chain of custody

• Hash at intake. Every upload is hashed with SHA-256 as the bytes arrive, before anything else happens to it. The stored copy has its own baseline hash and time.
• Evidence numbers. Each file receives a deterministic evidence number (E-YYYYMMDD-XXXXXX) derived from its content, stable across re-uploads.
• Integrity check on demand. The evidence record can re-hash the stored file at any time and report Intact or MISMATCH against its baseline.
• Legal hold and evidence lock. Footage can be placed under legal hold; held footage and any footage referenced by a sealed report refuses deletion and survives retention. Only an administrator can lift a hold.
• Sealed reports. A report's content is canonicalised and hashed with SHA-256 at sealing. Verify recomputes the hash and reports Seal intact or SEAL BROKEN. Every access to a sealed report is written to a custody ledger; reading the ledger is itself audited.
• Section 63 certificate. The platform renders the certificate required by section 63(4) of the Bharatiya Sakshya Adhiniyam, 2023, pre-filled from the sealed report and its digest.
• Derivative lineage. Every enhancement or redaction is a separate record with its method (classical / AI / face / blur / pixelate), parameters, tool versions, the hash of its parent and the hash of its output. The original is never modified. AI outputs are marked as leads, never evidence.
• Review states. Findings and cross-camera links carry accepted, rejected or inconclusive with the reviewer and time; rejected items are excluded from newly sealed reports and listed as excluded.
• Dual time. Where a camera's clock is found to be off, the platform stores the offset and its uncertainty and shows recorded and normalised time side by side. The recorded time is never rewritten.
• Impossible travel. Cross-camera links whose implied speed is physically impossible are flagged as contradictions, not offered as matches.

5. Audit trail

Every action in the console and the API — sign-ins and failures, searches and questions, uploads, analysis runs, reviews, report seals and reads, exports, certificate generation, settings changes, API-key and device events, alert deliveries — is written to an append-only audit table with the actor, action, target, timestamp and IP address (the real client address behind the reverse proxy). Audit entries are text only; they never contain images. The audit trail is kept indefinitely and is never pruned or edited. Administrators can filter and export it as CSV at any time; it is the record a court or inquiry may ask for.

6. Intake hygiene

• Malware scanning. Uploads can be scanned by a ClamAV sidecar before they are deduplicated, stored or analysed. An infected file is deleted and refused with the signature name; if the scanner is unreachable, production refuses the upload (fail closed) unless the operator has chosen otherwise. The scanner is enabled per deployment; ask us whether it is active on yours.
• Quotas. Uploads are checked against the organisation's plan limits before the file is kept.
• Deduplication. A file already analysed is recognised by its SHA-256 and not processed twice.
• Audio. Audio is stripped at ingest; the platform does not analyse or retain it.

7. Encryption and links

• In transit. All public traffic terminates at a reverse proxy with automatically provisioned TLS certificates; the API listens only on the local interface behind it. Outbound calls to the GPU engine, language model, WhatsApp, SMS and e-mail providers use TLS.
• Media links. Every image and video served by the platform is addressed by an HMAC-signed link with a one-hour expiry (48 hours for crops attached to alerts). The object store is never exposed publicly.
• Webhooks. Outbound alert webhooks are signed with a per-organisation secret in the X-Suraag-Signature header, and destination URLs are checked against private-network and loopback ranges before use.
• Push notifications. Browser push carries a fixed, content-free message; the alert itself is fetched over the authenticated API.
• At rest. Storage-layer encryption of the database, object store and vector store is not implemented on the hosted service. Customers who require it can take an on-premises deployment on their own encrypted disks.

8. Data flows outside the platform

9. Backups and recovery

The analysis database is dumped every six hours on the server and copied off-box to a second location where its checksum is verified against the server's; vector data is backed up daily. Raw footage is deliberately not backed up off the operator's server. Restore procedures are documented and were exercised on 17 August 2026 by restoring the artefacts and comparing checksums. Recovery targets are stated in the Service level description.

10. What is not built yet

We list these so that no one has to discover them:

• Storage-layer encryption at rest (section 7).
• Write-once (WORM / object-lock) storage for original footage; legal hold and evidence lock are the interim control.
• Multi-factor authentication and single sign-on (SAML / OIDC).
• IP allow-listing per organisation.
• Automatic retention for investigator uploads — they are kept until an administrator deletes them; only live edge clips are purged automatically.
• Rate limiting of the public /v1 API inside the application — it is applied at the reverse proxy.

11. Reporting a vulnerability

Write to support@suraag.xyz with "security" in the subject. We acknowledge within two working days, keep you informed, and do not take action against good-faith research that stays within your own organisation's data and avoids service disruption.