Your clients' data
is not our
training set.
Shrixa handles sensitive financial data — PAN numbers, TDS figures, income details, P&L statements. We treat this with the seriousness it deserves. Here is exactly how we protect it.
Every layer secured.
Security is not a checklist for us — it is an architectural constraint built into every component of Shrixa from day one.
All data stored in RDS PostgreSQL and S3 is encrypted using AES-256. AWS KMS manages all encryption keys with automatic rotation. No raw data is ever written to disk unencrypted.
AES-256 · KMSAll communication between the Shrixa app and our servers uses TLS 1.3. API Gateway enforces HTTPS-only. No plaintext data ever travels over the network.
TLS 1.3 · HTTPSAll Lambda functions and RDS instances run inside a private VPC. No direct public internet access. All traffic flows through API Gateway with strict security group rules.
VPC · PRIVATE SUBNETShrixa uses Firebase Auth with magic link (email OTP). No passwords are stored anywhere in our system. No password breach is possible because there are no passwords to breach.
FIREBASE · OTPAll document access uses time-limited presigned S3 URLs. No public bucket access. Documents cannot be accessed without a valid, short-lived signed URL generated per-request.
S3 · PRESIGNEDEvery Lambda function has the minimum IAM permissions required to perform its function. The IAM enforcer Lambda runs policy checks on every request. Over-permissioned access is architecturally impossible.
IAM · ZERO TRUSTClaude AI calls run in isolated Lambda contexts. Your financial inputs are never logged, cached across sessions, or used for model training. Prompt caching applies only to the Finance Act context — never to user data.
ANTHROPIC · ISOLATEDAll primary data storage is in AWS ap-south-1 (Mumbai). This is a hard architectural constraint. No Indian user data is stored outside India. Compliant with DPDP Act 2023.
AP-SOUTH-1 · DPDPAll consent records stored in RDS PostgreSQL — not Firestore — for legal integrity. CA-to-client mapping requires explicit client consent. All optional items unchecked by default per DPDP Act 2023.
DPDP · RDSSecurity by design,
not by policy.
Security controls are embedded at every layer of the Shrixa stack — from the client device to the database. No layer trusts another unconditionally.
- Firebase Auth magic link — no passwords stored
- JWT token validated on every request by dedicated authorizer Lambda
- Tokens expire and rotate — no long-lived sessions
- Biometric unlock is device-local only — never transmitted
- RDS PostgreSQL inside private VPC subnet — not publicly accessible
- AES-256 encryption at rest, KMS-managed keys
- S3 documents accessible only via time-limited presigned URLs
- ElastiCache Redis for rate tables only — no PII cached
- Anthropic Claude API — isolated per-request context
- Prompt caching on Finance Act only — never on user data
- No user inputs logged or retained by Anthropic for training
- RAG pipeline over Income Tax Act — no user data in index
Built for Indian law.
Every architectural decision reflects the requirements of India's data protection and tax law — not retrofitted after the fact.
Digital Personal Data Protection Act compliance — consent by default unchecked, data minimisation, purpose limitation, right to deletion.
All data stored in AWS ap-south-1 Mumbai. Hard architectural constraint. No cross-border transfer for primary storage.
Built natively for the Income Tax Act 2025 effective 1 April 2026. Section citations version-aware — old Act for pre-April 2026, new Act for FY 2026-27.
CA-to-client consent architecture ensures the CA remains data fiduciary under DPDP. Client consent required, recorded, and revocable.
Found a vulnerability?
Tell us first.
We take security reports seriously. If you discover a vulnerability in Shrixa or our infrastructure, please report it directly to our security team before public disclosure. We commit to responding within 48 hours, investigating all reports, and crediting researchers where appropriate.