Security overview

Taska runs entirely on AWS in us-east-1. The architecture: a Fargate-hosted API behind an ALB, a Fargate worker that processes inbox sync + AI extraction, RDS Postgres 16 for primary storage, S3 for meeting uploads, Cognito for identity, and AWS Bedrock (Claude Sonnet 4.5 + Haiku 4.5) for AI inference. Live system status is published at /status.

• At rest: all customer data in RDS and S3 is encrypted with AWS KMS using customer-managed keys (CMKs). OAuth refresh tokens use envelope encryption — each token is sealed with a per-user data key so a stolen database row cannot be decrypted without the matching KMS grant.
• In transit: TLS 1.2+ everywhere. HSTS is preloaded; HTTP requests are redirected to HTTPS at the ALB.
• In use: the worker decrypts mailbox tokens just-in-time to call Gmail / Outlook APIs. Plain-text tokens never touch disk.

Extraction uses AWS Bedrock — your content never trains Anthropic or AWS models (AWS Bedrock data protection). Additionally:

• Prompt-injection defense: inbound user content (email bodies, meeting transcripts) is wrapped in XML tags and the system prompt instructs Claude to treat tag contents as untrusted data — not instructions. Known jailbreak patterns are detected and reported to our telemetry pipeline so we can tune the defense over time.
• PII redaction: email addresses, phone numbers, SSN-shaped, IBAN-shaped, and credit-card-shaped strings are redacted before logs leave our infrastructure (Sentry / observability). Customer content is never logged in plain text outside the database it's stored in.
• Cost caps: per- user and global daily Bedrock spend caps prevent runaway costs and limit blast radius in the unlikely event of a credential compromise.
• No content training: we never use your tasks, emails, meeting transcripts, or any other customer data to train models — ours or anyone else's.

Taska uses the following sub-processors to deliver the service:

We update this list when adding a sub-processor and notify enterprise customers in advance per their DPA.

We use AWS IAM roles with least-privilege policies: the API task role can read only its own secrets, the worker task role can call Bedrock + Gmail / Outlook + KMS-decrypt. No shared admin credentials. Internal access to production data is restricted to the founding team via SSO, audited via CloudTrail, and used only for incident response with the user's permission.

• Content Security Policy + HSTS preload + clickjacking protection are enforced site-wide.
• Per-route authorization: team admins and members see different data; the dashboard and audit log require role gates enforced server-side, not just hidden in the UI.
• All admin actions on a team (rename, invite, role change, remove, assign, delete) are written to an immutable audit log visible to owners.
• Rate limiting at the API (300 requests/min per user) prevents credential-stuffing and abuse. Per-route tightening on high-cost endpoints (extraction, public booking).
• Webhook signatures (Stripe, Slack Events) are verified with HMAC- SHA256 and constant-time compare; replay attempts older than 5 minutes are rejected.
• Dependencies are tracked via npm and patched on a rolling basis; CI runs typecheck + tests on every PR.

• Backups: RDS automated backups are retained for 7 days with point-in-time restore enabled. S3 versioning is on for meeting uploads.
• Account deletion: requesting account deletion triggers a cascade purge of mailbox content, meeting uploads, extracted tasks, and any audit history referencing you. Backups age out of the 7-day window within a week.
• Source disconnect: disconnecting a mailbox deletes its messages and revokes the refresh token within 24 hours; previously-extracted tasks remain unless you delete them individually.

• Detection: errors and anomalies are surfaced via Sentry + CloudWatch alarms on Bedrock spend, API error rate, and ALB 5xx rate.
• Notification: material incidents affecting customer data trigger email to the affected accounts within 72 hours, with details and remediation. Live operational issues are posted to /status in near-real-time.
• Postmortems: any incident with customer-data impact gets a public postmortem within 5 business days, linked from /status.

We are pursuing CASA Tier 2 assessment in 2026 (required by Google for restricted-scope verification of Gmail readonly access). SOC 2 Type I is on the roadmap once we reach 50 paying teams. We comply with GDPR rights of access, rectification, erasure, and portability — see our Data Processing Addendum for enterprise customers. The DPA includes Standard Contractual Clauses (SCCs) for EU → US data transfers.

Found a security issue? Email security@enrevia-taska.com. We acknowledge reports within 48 hours and will not pursue legal action against good-faith researchers. Please don't use real user data while testing — set up your own demo account on /demo for safe poking.