Dhruv.AI uses defence in depth: collect less, keep secrets off public pages, verify identity through established providers, restrict database access at the data layer, and make high-risk features unavailable until they can be introduced safely.
Identity and account protection
- Passwords are processed by Supabase Authentication and are never placed in the website source or owner dashboard.
- Email verification remains required for password accounts; Google sign-in uses Google’s OAuth consent flow.
- Browser sessions are encrypted in transit, refreshed by the authentication provider, and protected by restrictive cache rules on private pages.
- Successful sign-ins and versioned policy acceptance can be recorded for account administration, legal evidence, and incident review.
- Administrative decisions and Academy publishing are protected by database row-level security—not merely by hidden links.
Application and data safeguards
- HTTPS is enforced with long-lived transport security, anti-framing, MIME protection, strict referrer rules, and restricted browser permissions.
- A Content Security Policy limits executable scripts, connections, forms, frames, media, and cross-origin resources to approved origins.
- Academy videos use private storage and short-lived member playback links. Upload and publishing rights are owner-only.
- Welcome email runs in an authenticated server function with an encrypted, domain-restricted provider key and duplicate-send controls.
- Public browser code contains only a publishable Supabase anonymous key; server-role, SMTP, deployment, and provider secrets must never be committed.
Data-minimisation boundaries
The website does not request location, camera, microphone, contacts, payment cards, health data, or government identifiers. The Studio Planner remains browser-only and does not store its answers. Visitors should never provide credentials, sensitive client documents, regulated data, or production source code through ordinary email.
Operational controls
Dhruv.AI should review privileged accounts, provider access, dependencies, database policies, backups, delivery logs, and unusual authentication activity on a regular schedule. Temporary publishing credentials must be project-scoped, short-lived, and revoked after use. Material changes require a fresh security and privacy review before release.
Responsible disclosure
Report a suspected vulnerability to hidhruvai@gmail.com ↗ with affected URL, impact, reproducible steps, and non-sensitive evidence. A machine-readable contact is published at /.well-known/security.txt ↗. Do not access other accounts, retain personal data, alter records, demand payment, or disrupt service. Good-faith reports will be reviewed and coordinated; this statement does not authorise unlawful testing.
Incident response
For a credible incident, Dhruv.AI will preserve evidence, contain access, rotate affected secrets, review logs and provider controls, assess data impact, restore safely, and notify people or authorities where legally required. Security reports and response records are restricted to those who need them.
Responsible AI principles
Academy and Studio work should use approved source material, narrow permissions, human review at consequential points, measurable tests, audit trails where appropriate, and a defined fallback or escalation path. Every production client system still requires its own threat, privacy, and impact assessment.
Honest assurance: No online service is literally unhackable. These controls materially reduce avoidable risk; they do not replace monitoring, backups, incident preparation, vendor review, or qualified security testing before payments, public uploads, AI APIs, or enterprise integrations are added.