Security & Data Protection

This page is written for the store owner or IT reviewer who wants to know exactly how we protect their data before trusting us with it. Every item describes a control that is built and running in the Platform today, not a roadmap. If something is not written here, assume it does not exist and ask us.

In short: the Platform is multi-tenant, every query is scoped to your organization and store, every stored secret is encrypted, every incoming webhook is signature-verified before it is processed, and every sensitive operation lands in an audit log. The details follow.

How we process data and where we act as processor or controller is set out in the Privacy Policy and the Data Processing Agreement.

• Vercel — application hosting, serverless compute, edge network, and the cron scheduler.
• Neon — managed PostgreSQL. There is a single production database on a single branch; there are no stray copies of your data in side environments.
• Cloudflare R2 — object storage: conversation attachments, uploads, and the nightly database backups.
• Upstash — Redis for rate limiting, locks, and short-lived cache, and QStash as the job queue for campaign sends and syncs. Queue messages carry ids only, never message bodies.
• GitHub Actions — runs the nightly backup job: a pg_dump every day at 03:30 UTC into an R2 bucket we own; backups are retained for 30 days and then pruned.

The full provider list with purpose and location is on the Subprocessors page. Providers are in the USA and the EU; we do not claim a specific data-centre city.

• In transit: all connections use TLS/HTTPS, with HSTS so a browser cannot fall back to an unencrypted connection even if it tries.
• At rest: every secret column — AI API keys, store-platform tokens, WhatsApp/Meta/X credentials, and two-factor secrets — is encrypted with AES-256-GCM before it reaches the database.
• Decrypted values are never written to a log and never sent to the browser, and they never appear in an account export (the export explicitly excludes encrypted credentials).
• Passwords: stored as a bcrypt hash. We cannot read your password; a reset happens only through a token link.
• Card data: never passes through us. Stripe holds it; we store only the subscription status, the last 4 digits, and the card brand.

The Platform is multi-tenant, and this is its most important control: your store's data never mixes with another store's.

• Every database query is scoped by your organization and store id. There is no "global" path that reads customers, conversations, or orders without that scope.
• The active store (the one you select in the dashboard) is re-verified on the server against your actual membership on every request. A cookie value on its own grants nothing.
• Authorization is never read from the client. Whatever the browser sends about your role or permissions is ignored; the server decides from the membership record.
• Every agent tool is store-scoped. The refund and cancellation tools verify that the order actually belongs to the customer asking, and abandoned-cart resumption works only on that customer's own cart.
• No cross-tenant learning: one merchant's data never influences another merchant's agent.

• Sign in with email and password (bcrypt), or with Google — in which case the Google account's email must be verified, and it links to the same account with us by email.
• Optional two-factor authentication (TOTP) with single-use backup codes, enabled from /dashboard/settings/security. Two-factor secrets are stored encrypted.
• Login attempts and two-factor code attempts are rate-limited; repeated guessing is blocked.
• Sessions are JWTs in a session cookie. Every cookie we use is strictly necessary and listed on the Cookies page.
• Password reset, email verification, and team invites all happen through token links.

• Permissions are RBAC in the form resource:action. Every sensitive route checks a specific permission, and if that permission is not explicitly granted the check fails closed — there is no default allow.
• The legacy tiers (owner, admin, member) map to permission sets, and you can give team members the least permission that is enough for their job.
• Membership must be ACTIVE. A suspended member cannot act even while their session is still valid.
• Invites are token links, and the organization owner controls who is inside.
• Every permission change is recorded in the audit log with the before and after values.

• A Content Security Policy is enforced, not report-only, and X-Frame-Options: DENY prevents the dashboard from being embedded in an iframe on any other site (clickjacking protection).
• Input validation: every API input is validated against a Zod schema before it reaches business logic.
• Uploads: checked against a MIME allowlist, the file extension, and the file's actual bytes. Allowed: jpeg/png/gif/webp images and PDF files.
• Webhook signatures: every incoming webhook from Salla, Zid, Shopify, Meta (WhatsApp, Instagram, Messenger), X, Stripe, and Resend is verified with HMAC-SHA256 using a timing-safe comparison. A request with no signature or a mismatched one is rejected before any processing.
• Job-queue messages (QStash) are signed and verified; nobody can inject a job from outside.
• Prompt-injection defense: any externally sourced text — a product description, a knowledge-base answer, a customer message — is stripped of injection markers, fenced as untrusted content, and the model is instructed to treat it as data, not instructions. On top of that, what the model is allowed to do is capped by the controls in the next section.
• We ran an internal dependency and pre-launch security audit. We do not claim an external penetration test or a certification.

The agent does not act with unrestricted freedom. You configure the controls that govern it, and they have a hard ceiling it cannot exceed:

• Autonomy levels from 0 (observe and take notes only) to 4 (autonomous). The default is level 2: any risky action goes to a human-approval queue.
• Hard caps (maximum automatic refund, maximum discount percentage) override the level: anything above the cap always goes to approval. Every tool that spends money, grants a discount, or changes an order passes through this guardrail.
• What is sent to the provider for each reply is limited: the system instructions, the last 12 messages of the conversation, and the minimum context the tools fetch — not the whole database. A reply is capped at 800 output tokens and at most 5 tool rounds.
• The model providers (Anthropic, OpenAI, Google) do not train on your inputs or outputs under their commercial terms. You can also use your own API key.
• The manager agent (Capi) talks only to you inside the dashboard and only proposes; any execution needs a person's approval. It never reaches your customers.

Configure it at /dashboard/ai-agent, and handle approvals at /dashboard/ai-agent/actions. Full details are on the AI Policy page.

• Audit log: sensitive operations — exports, permission changes, campaign sends, approvals of agent actions, and settings changes — are recorded with the value before and after. Credentials are never logged. The log is retained for 12 months.
• Error monitoring through Sentry with default PII sending turned off: only the error kind and ids are sent, never message bodies or request payloads.
• A system-health screen shows us the state of queues, syncs, and integrations so we notice a fault before a complaint reaches us.
• Background jobs: every run is recorded (kept for 30 days). Anything that still fails after retries goes to a dead-letter queue that we review; resolved entries are kept for 90 days.
• Incoming webhook events are kept for 30 days for tracing and troubleshooting.

• The rate limiter runs on Redis, with Postgres as a fallback when Redis is unavailable. If it cannot reach either, it denies instead of allowing — it never fails open. Hit records are kept for 7 days.
• Distributed locks prevent duplicate sends and parallel syncs on the same store.
• Plan limits are enforced server-side, and AI usage is metered per store with a spend ceiling.
• Meta's quality rating for your WhatsApp number is monitored every 6 hours; if it drops, sending is throttled or deferred to protect your number.
• Every marketing send passes a consent gate (subscribed and not blocked), with opt-out keyword detection in Arabic and English and unsubscribe links in email.

• A full database backup runs every night at 03:30 UTC into an R2 bucket we own, retained for 30 days and then pruned. That means anything you delete leaves the backups within 30 days at most.
• Provider failover chain for AI: if a provider is down, the next one you configured is tried. If all of them fail, the conversation is handed to a human — it is never left silent.
• Retry queues: sends and syncs go through QStash with retries, and a dead-letter queue catches whatever fails permanently. A send held back by a limit is deferred, not dropped.
• We do not offer a contractual availability guarantee (SLA) on standard plans; see the Terms.

• Our team does not open your store's data routinely. Access happens only at your request (a support ticket) or to investigate an incident, and it is logged.
• Least privilege: production credentials are held by the smallest possible number of people and kept as environment variables and CI secrets — never in tracked files in the code repository.
• Because decrypted secrets never surface in logs or in the interface, even a staff member with access cannot see your API keys or tokens.

If you find a security vulnerability, email security@capiagent.com. Please include:

• The affected URL or endpoint and the steps to reproduce.
• The expected impact (what an attacker could do).
• Your name if you would like to be credited. Do not attach other users' data — if you reach data that is not yours by accident, stop and tell us.

What we commit to: we acknowledge your report within 5 business days at most, and we keep you informed until the issue is resolved.

Safe harbour: we will not pursue legal action against any researcher acting in good faith within these rules: do not degrade the service, do not access or modify data that is not yours beyond what is needed to demonstrate the issue, no social engineering, no messages through the Platform to real people, and give us reasonable time before any public disclosure.

There is no paid bounty program at this time. We will credit you publicly if you wish.

1. Triage: we establish the scope of the incident quickly from logs, the audit log, and error monitoring — who is affected, and which data.
2. Containment: rotating the affected credentials, revoking sessions, blocking the source, and pausing the affected job or channel until the cause is fixed.
3. Notification: if a personal-data breach is confirmed, we notify the affected merchants without undue delay and no later than 72 hours after confirmation, by the account email and a dashboard notice, with the facts known at that time: what happened, which data, what we did, and what you need to do. We add information as we learn more.
4. Post-incident: a written report of the root cause and the corrective actions for those affected. Since you are the controller of your customers' data, we assist you if you need to notify your regulator or your customers, as set out in the Data Processing Agreement.

We secure the Platform, the infrastructure, and the code. Part of your account's security is in your hands, and this is what we expect from you:

• Enable two-factor authentication for every member of your team, not only the owner account.
• Assign roles on a least-privilege basis, and remove leavers immediately.
• Keep your own API keys and your store-platform and Meta credentials secret; if a key leaks, rotate it right away.
• Configure the autonomy caps (maximum discount, maximum refund) and escalation rules before running the agent on a live channel, and review the approvals page regularly.
• Obtain explicit consent before any marketing send and honour opt-outs; see the Acceptable Use Policy and the Channel Policies.
• Review the audit log periodically, and tell us immediately at security@capiagent.com if you suspect unauthorized access.

Our practices are built to align with the Saudi Personal Data Protection Law (PDPL), the Turkish Personal Data Protection Law (KVKK), and the EU GDPR. The contractual commitments — roles, subprocessors, international transfers with safeguards such as Standard Contractual Clauses, and assistance with data-subject requests — are documented in the Data Processing Agreement.

Honestly: we hold no external certification at this time (no SOC 2, no ISO 27001). The audits we have done are internal. If your procurement process needs a security questionnaire, send it to security@capiagent.com and we will answer it with the same facts written here.

Related documents: Privacy, Subprocessors, Data Deletion, all legal documents.

• Vulnerabilities and security incidents: security@capiagent.com
• Privacy and data-subject rights: privacy@capiagent.com
• Contracts and processing agreements: legal@capiagent.com
• Or via the contact page. We reply within 5 business days at most.