Posture de sécurité

Prêt pour l'article 28 du RGPD · Prestataire de services CCPA · SOC 2 Type I en cours

Ataski exploite une base de données Postgres unique multi-locataire avec une Sécurité au niveau des lignes (Row Level Security) appliquée au niveau de la base de données ; un journal d’audit en ajout seul pour chaque action ; et des garde-fous de coûts par locataire pour contenir les dommages liés à la compromission d’un seul identifiant. Cette page constitue le résumé prêt pour les achats — pour la surface contraignante du contrat, consultez le Contrat de traitement des données.

Multi-location

Chaque table de données client comporte une colonne tenant_id et une politique de Sécurité au niveau des lignes Postgres qui filtre chaque lecture et chaque écriture selon la variable de session du locataire lié. L’application définit la variable à partir du principal authentifié au début de chaque requête ; la base de données rejette toute requête qui tente de lire ou d’écrire en dehors du locataire lié, indépendamment de l’exactitude de la couche applicative.

Défense en profondeur pour les surfaces situées hors de Postgres : le cache LiteLLM cloisonne chaque invite par un sel propre à chaque locataire afin que les correspondances de cache ne puissent pas franchir les locataires ; les charges utiles des workflows durables sont chiffrées avec des clés propres à chaque locataire à la frontière du workflow ; et le stockage d’objets R2 cloisonne chaque clé sous tenants/<uuid>/… de sorte qu’une URL divulguée ne puisse pas énumérer d’autres locataires.

Journal d'audit

Chaque appel LLM, chaque appel d’API externe et chaque modification de données est inscrit dans une table unique audit_log en ajout seul, indexée sur (tenant_id, correlation_id). La table est verrouillée au niveau de la base de données (REVOKE UPDATE, DELETE sur le rôle applicatif) — le seul moyen de modifier l’historique d’audit est un accès administratif direct par les opérations d’Ataski, qui produit lui-même des lignes d’audit sous un marqueur distinct actor_type="ops".

Chiffrement

• Au repos. Chaque identifiant client (jeton de rafraîchissement OAuth, clé d’API, secret de webhook) est enveloppé avec Fernet (AES-128 en mode CBC avec authentification HMAC-SHA-256) avant d’être conservé sous forme de BYTEA. Des clés de chiffrement des données propres à chaque locataire sont à la feuille de route ; le chiffrement au niveau du stockage (AES-256) est aujourd’hui fourni par Neon pour Postgres et par Cloudflare R2 pour le stockage d’objets.
• En transit. TLS 1.3 est le minimum sur chaque point de terminaison public et chaque appel sortant vers un sous-traitant ultérieur.

Contrôles d'accès

L’authentification est déléguée à WorkOS (SSO, SAML, sans mot de passe). L’autorisation est restreinte par rôle au niveau de la route : les actions à fort enjeu (approbation du dossier de conseil d’administration, envoi de la mise à jour mensuelle des investisseurs, lancement de campagne sortante) requièrent un rôle nommé (founder ou finance_lead) sur l’espace de travail.

Portées des connecteurs

Chaque système connectable par l'opérateur fonctionne avec un ensemble documenté de portées côté fournisseur. La liste ci-dessous est générée à partir de notre manifeste de portées interne — ce que vous voyez correspond à ce que le client OAuth (ou l'identifiant équivalent) demande réellement.

• Anthropic (Bring Your Own Key). Routes every Anthropic worker + supervisor LLM call through your own Anthropic API key (sk-ant-*). Ataski stores the key Fernet-encrypted at rest and reads it only through the LiteLLM gateway proxy at call time; no copy lives anywhere else. Anthropic invoices you directly; Ataski's invoice excludes LLM cost for any traffic routed through this key. Rotate or deactivate from /app/llm-keys at any time.
• HubSpot. Reads deals, contacts, and companies. Cannot create or modify any HubSpot record.
• NetSuite. Reads GL transactions, AR aging, AP aging, accrual snapshots, and subsidiary roster via NetSuite Token-Based Authentication (TBA) — an OAuth 1.0a-flavoured credential the customer generates inside their NetSuite UI (Setup → Users/Roles → Access Tokens). NetSuite does not offer OAuth 2.0 for SuiteTalk REST; the customer creates the Integration record + Access Token bound to a read-only NetSuite role of their choice, and Ataski only issues read queries against it. Cannot post journal entries, modify records, or close accounting periods.
• OpenAI (Bring Your Own Key). Routes every OpenAI supervisor + embedding call through your own OpenAI API key (sk-*). Ataski stores the key Fernet-encrypted at rest and reads it only through the LiteLLM gateway proxy at call time; no copy lives anywhere else. OpenAI invoices you directly; Ataski's invoice excludes LLM cost for any traffic routed through this key. Rotate or deactivate from /app/llm-keys at any time.
• QuickBooks Online. Reads chart of accounts, P&L, balance sheet, cash flow, invoices, customers, and vendors. Cannot write or modify any QuickBooks data.
• Recall.ai. Creates bots that join scheduled meetings and reads back their transcripts and engagement metadata. Write surface is limited to dispatching the bot; cannot mutate any calendar, video-conference, or meeting-host data.
• Sage Intacct. Reads GL accounts, journal entries, AR/AP, and trial balance via a customer-provisioned read-only Web Services user. Sage Intacct does not offer OAuth; the customer creates the WS user inside their Sage Intacct admin and supplies its credentials. Cannot post journal entries or modify any Sage Intacct data.
• Stripe. Reads subscriptions, invoices, customers, refunds, and payment intents via a customer-provided Restricted API key. Cannot create, modify, or refund charges.
• Xero. Reads the P&L, reports, invoices, and organisation settings via OAuth. Cannot create or modify any Xero data.

Traitement des données personnelles

Ataski agit en qualité de Prestataire de services au sens du CCPA (Cal. Civ. Code §1798.140(ag)), et non en tant que courtier en données. Les fiches de contact restent dans le périmètre RLS propre à chaque locataire et ne sont jamais agrégées entre locataires ; les données firmographiques non personnelles (nom d’entreprise, secteur, registres d’activité publics) peuvent être mises en cache entre locataires à des fins de performance. Nous ne dépendons pas de fournisseurs courtiers en données de recherche d’e-mails (Hunter, Apollo, Findymail, ZoomInfo, Coresignal) ; la découverte de contacts utilise des schémas de composition à partir de sources publiques. Suppression par destinataire dans les 45 jours suivant la demande via /privacy/optout.

Sous-traitants ultérieurs

La liste canonique des sous-traitants ultérieurs est publiée à l’adresse /legal/subprocessors et comprend actuellement 18 fournisseurs. Les modifications des sous-traitants ultérieurs sont accompagnées d'un préavis de 30 jours par bannière intégrée à l'application et par e-mail à l'administrateur de l'espace de travail ; le Client peut s'y opposer pour des motifs raisonnables pendant cette période.

Contrat de traitement des données

Le DPA principal couvre les obligations de l’article 28 du RGPD, du RGPD britannique et du Prestataire de services CCPA : consultez-le à l’adresse /legal/dpa. La version authentifiée à /app/legal/dpa remplit les champs du Responsable du traitement à partir de l’espace de travail et prend en charge la signature électronique par le fondateur ou le responsable financier de l’espace de travail.

Réponse aux incidents

Les erreurs et exceptions sont capturées dans Bugsink (équivalent hébergé de Sentry) ; l'astreinte examine la gravité des incidents dans l'heure suivant le premier signal. L'état des points de terminaison opérationnels est publié sur la page de statut publique. Pour tout incident impliquant des Données client, nous notifions le Responsable du traitement concerné sans retard injustifié et dans un délai de 72 heures, conformément à l'article 33 du RGPD.

Posture de conformité

• Prêt pour l’article 28 du RGPD. DPA principal disponible au téléchargement et à la signature électronique ; liste des sous-traitants ultérieurs publiée et empreintée.
• Prestataire de services CCPA. Posture Cal. Civ. Code §1798.140(ag) — aucune activité de courtage de données, périmètre propre à chaque locataire sur toutes les données de contact, point de terminaison de suppression publié.
• SOC 2 Type I en cours. Cadrage de l’audit terminé ; la période d’observation commence au T3 2026. Le rapport sera disponible sous accord de confidentialité une fois émis.