Security at Aidelly

Hosting and infrastructure

Aidelly runs on established cloud infrastructure in the United States. The application runs on Vercel (AWS us-east-1, N. Virginia) and data is stored with Supabase on AWS us-east-2 (Ohio). All customer data is processed and stored in the United States. Both providers maintain their own compliance programs, including SOC 2, and publish their certifications independently; those certifications belong to them, not to us.

Encryption

• All traffic is encrypted in transit with TLS. Both domains enforce HTTPS with HSTS (two-year max-age, includeSubDomains, preload).
• Data is encrypted at rest by our database provider (Supabase on AWS).
• Social platform access tokens get an additional layer: they are encrypted at the application level with AES-256-GCM (a fresh IV per record and an authenticated tag verified on every decrypt) before they ever reach the database. No plaintext token column exists.
• API keys are never stored. We keep only a SHA-256 hash and a short display prefix; keys are verified by hash and can be revoked at any time.

Access control and isolation

• Workspaces are the isolation boundary. Connected social accounts, content, analytics, and team access are scoped per workspace, and database row-level security policies enforce that scoping across our tables.
• Role-based access control with distinct owner, admin, member, and client roles, plus granular per-role permissions inside a workspace.
• Clients can connect their social accounts through secure connect links without ever receiving platform logins.
• Every workspace has an append-only audit log, visible to the workspace, recording who did what and when, including IP and user agent. Entries cannot be edited or deleted. API access is separately audit logged for 365 days.
• Session cookies are httpOnly and marked secure in production. Passwords are handled by Supabase Auth, which stores them using bcrypt; we never handle or store password material in our own code.
• Internal access to customer data is limited to a small team and used for support and operations only.

Application security

• The app ships a Content Security Policy with a default-src of self, generated per request with nonce support, alongside X-Frame-Options, nosniff, and a strict referrer policy.
• Sensitive endpoints are rate limited, and OAuth flows use per-attempt state secrets with server-side verification.
• Disconnecting a social account deletes its stored tokens along with related grants and sync state.

Your data, your control

• Your content and your clients' data belong to you. You can export content and analytics through our public API at any time.
• Deleting a workspace permanently removes its data, which supports deletion requests under regulations such as GDPR and PDPA.
• We document retention windows for operational data as policy; details are available on request at privacy@aidelly.com.

Sub-processors

We use a small set of established vendors to deliver the product, including Vercel and Supabase (hosting and data), Stripe (payments), and AI model providers for content generation. A full, current sub-processor list is available on request at privacy@aidelly.com.

What we do not have yet

We would rather be precise than impressive. Aidelly does not yet hold formal certifications such as SOC 2 or ISO 27001 of its own, and two-factor authentication for user logins is on our roadmap but not yet available. If your assessment requires specifics beyond this page, write to security@aidelly.com and we will answer directly.

Reporting a vulnerability

If you believe you have found a security issue in Aidelly, email security@aidelly.com with the details. We read every report, respond as quickly as we can, and will never take action against good-faith research.