Security
How we protect your Amazon Data — and how security researchers can responsibly report issues to us.
- Last reviewed ·
- 26 April 2026
- Effective ·
- 26 April 2026
1. Summary of security practices
- Encryption at rest. AES-256 via AWS RDS native encryption and S3 SSE-KMS.
- Encryption in transit. TLS 1.2 or higher for every public endpoint.
- Key management. Refresh tokens and sensitive credentials are encrypted with AWS KMS customer-managed keys and never logged.
- Access controls. Role-based access. Access to Amazon Data is strictly on a need-to-know basis within the founding team. Audit trail on every privileged action.
- Safe-write rails. Every Amazon API write goes through our SafeWriter service, which enforces a circuit breaker, an
actions_logaudit entry, and a hard cap that no single automated action depletes more than 5% of the customer's daily budget. - Monitoring. Sentry for error tracking. PagerDuty for on-call alerts. API response codes, latencies, and rate-limit headers logged with timestamps.
- Data residency. Primary storage in AWS ap-south-1 (Mumbai). Data transfer to other regions only via encrypted backups under safeguards.
2. Vulnerability disclosure process
If you believe you have found a security issue in SellerSaarthi:
- Email security@sellersaarthi.com.
- Optionally encrypt your report with our PGP key: /pgp-key.txt.
- We acknowledge within 48 hours.
- We aim to provide an initial assessment within 5 business days.
- We credit responsible disclosers in the Hall of Fame below, with permission.
3. Scope
In scope: our production domains (sellersaarthi.com, app.sellersaarthi.com, staging.sellersaarthi.com), our public APIs, our LwA callback endpoints, and our published clients.
Out of scope: third-party services we use (Amazon, AWS, Razorpay, Clerk, Anthropic, PostHog, etc.); social engineering or physical attacks on the founding team; UI/UX issues with no security impact; missing rate-limits on clearly non-sensitive endpoints.
4. Safe harbour
We will not pursue legal action against good-faith researchers who:
- Follow this disclosure process.
- Do not access more data than necessary to demonstrate the issue.
- Do not publicly disclose the issue before we have had a reasonable opportunity to remediate.
5. Hall of fame
We are grateful to the following researchers for responsibly disclosing issues:
(The wall is currently empty. If you are first, your credit goes here.)
6. security.txt
An RFC 9116-compliant security.txt is published at /.well-known/security.txt.
Effective date: 26 April 2026.