afka utilise des cookies d'analyse pour voir comment les visiteurs utilisent le site, et un service qui peut identifier l'entreprise pour laquelle travaille un visiteur. Nous ne vendons pas vos données. Refusez et rien ne se charge.
afka exécute des agents qui se connectent à vos outils et agissent en votre nom, c'est pourquoi la sécurité et le contrôle sont intégrés au produit. Cette page résume comment nous protégeons vos données et comment vous restez maître de ce que vos agents peuvent faire.
afka donne à une entreprise des collègues IA qui reçoivent du travail dans un canal de chat, le planifient, agissent dans ses outils connectés et font un rapport. La réponse à la confiance que cela exige est une architecture dans laquelle la chose dangereuse est difficile à faire par construction. Trois propriétés portent la majorité de ce poids.
Le modèle ne voit jamais une credential. Quand un agent agit dans un outil connecté, il ne détient ni ne voit jamais le jeton qui autorise l'action. Il appelle l'outil par son nom, et une passerelle backend injecte la credential au moment de l'exécution, sur le serveur, en dehors du contexte du modèle. Une credential que le modèle n'a jamais vue ne peut pas être divulguée ou redirigée par lui : la protection est structurelle, non comportementale.
L'argent et les dommages irréversibles demandent toujours une personne nommée. Chaque agent a un paramètre d'autonomie que le client choisit, et au-dessus se trouvent deux étages indépendants qu'il ne peut pas abaisser. L'argent quittant le compte du client, et les décisions qui causent à une personne un dommage irréversible, s'arrêtent toujours et demandent d'abord à une personne nommée, quel que soit le paramètre.
Tout est écrit là où il ne peut pas être modifié ou supprimé. Chaque action, par un agent ou une personne, est écrite dans un journal d'audit en ajout seul dans l'espace de travail du client. Le journal d'audit ne peut pas être modifié ou supprimé, y compris par afka.
Conforme signifie que l'exigence est en vigueur maintenant et qu'afka la respecte. En cours signifie que le travail a commencé et n'est pas terminé. Prévu signifie que le travail est programmé et n'a pas commencé.
| Norme | État | Ce que cela signifie | Documentation disponible aujourd'hui |
|---|---|---|---|
| SOC 2 Type I | En cours | Les travaux en vue de l'examen sont en cours. Aucun rapport n'existe encore, et afka n'en revendique aucun. | Cette page ; Annexe II de l'accord de traitement des données ; un questionnaire sur demande. |
| SOC 2 Type II | En cours | Un rapport Type II couvre les contrôles sur une période d'observation. Les travaux sont en cours et aucun rapport n'existe encore. | Aucune. |
| ISO/IEC 27001 | Prévu | afka ne détient aucun certificat et aucun processus de certification n'est en cours. | Un mappage de contrôle par rapport aux exigences nommées par l'acheteur. |
| ISO/IEC 42001 | Prévu | afka ne détient aucun certificat pour un système de gestion de l'IA et ce travail n'a pas commencé. | Sections 6 et 7 ; les entrées correspondantes de l'Annexe II. |
| RGPD (Règlement (UE) 2016/679) | Conforme | afka est responsable du traitement, le client est responsable du traitement. L'accord de traitement des données est publié selon des conditions standard, porte les obligations de l'article 28 en intégralité, et incorpore les clauses contractuelles types de 2021. Une position juridique, non une certification. | L'accord de traitement des données et ses annexes ; la politique de confidentialité, qui publie la liste des sous-traitants. |
| RGPD du Royaume-Uni et loi de 2018 sur la protection des données | Conforme | L'accord de traitement des données couvre le Royaume-Uni expressément et incorpore l'addendum de transfert international de données (version B1.0). | L'accord de traitement des données, y compris ses élections d'addendum. |
| CCPA et lois sur la confidentialité des États américains | Conforme | afka agit en tant que prestataire de services et ne vend ni ne partage d'informations personnelles. Des conditions équivalentes couvrent les lois des États du Delaware, de Virginie, du Colorado, du Connecticut, du Texas et de l'Oregon. | L'accord de traitement des données (conditions de prestataire de services) ; la politique de confidentialité. |
| Politique relative aux données utilisateur des services Google API, y compris l'utilisation limitée | Conforme | Uniquement des portées de connexion pour le client Google propre à afka, plus la portée de l'application Google Chat. Aucune portée de lecture de boîte de réception n'est demandée. | Section 2.6 de l'accord de traitement des données, énonçant les portées et les engagements d'utilisation limitée. |
afka ne détient pas aujourd'hui de rapport SOC 2 d'aucun type, et ne détient pas de certificat ISO/IEC 27001 ou ISO/IEC 42001. Il n'y a aucune attestation et aucun rapport disponible en vertu d'un accord de non-divulgation.
Ce qu'un acheteur peut avoir aujourd'hui : les descriptions de contrôle sur cette page ; Annexe II de l'accord de traitement des données, qui indique où une mesure est fournie par un prestataire de plateforme sous-jacent ; un mappage de ces contrôles au cadre nommé par l'acheteur ; l'accord de traitement des données, signé ; et un questionnaire de sécurité complété. Écrivez à support@afka.ai.
Les espaces de travail sont isolés dans la base de données, non dans le code applicatif. Chaque table de locataire porte une sécurité au niveau des lignes basée sur une revendication d'identifiant commercial qu'un hook de jeton d'accès personnalisé injecte dans le jeton d'accès à la connexion. Une requête effectuée avec le jeton d'un espace de travail ne peut pas retourner les lignes d'un autre, donc un bogue applicatif ne devient pas une exposition entre locataires : la limite n'est pas appliquée par la couche qui a le bogue.
Sur les tables principales, la sécurité au niveau des lignes est définie sur FORCE, supprimant l'exemption qu'une politique ordinaire accorde au propriétaire de la table. Ces tables sont les tâches, les exécutions, les approbations, les artefacts, le journal d'audit, le grand livre de crédits, les connecteurs, les compétences de l'espace de travail, les données de surveillance des agents et les cartes proactives.
L'isolation des locataires est vérifiée automatiquement avant toute modification publiée.
En tant que défense en profondeur, les fonctions côté serveur ne font jamais confiance à un identifiant d'espace de travail fourni par le client : elles re-résolvent le locataire à partir du jeton vérifié.
Les références de connexion pour les comptes connectés sont conservées dans le coffre-fort de secrets de la plateforme de base de données gérée : jamais dans les fichiers d'environnement, jamais dans le bundle frontend, jamais dans une variable de build qui atteint le navigateur.
Pour un connecteur géré par la plateforme de connecteur, l'octroi OAuth lui-même est détenu par cette plateforme ; afka ne détient qu'une référence à celui-ci. La déconnexion révoque donc le compte à la source, par un appel API à la plateforme, et afka écrit une ligne d'audit l'enregistrant.
Les clés API sont stockées sous forme de hachage SHA-256, affichées une seule fois à la création et jamais récupérables ; seul un préfixe et les quatre derniers caractères sont conservés, pour l'affichage. Les portées sont réintersectées avec les capacités en direct du créateur à chaque appel d'authentification, de sorte qu'une clé ne peut pas survivre aux permissions du créateur, et la portée de gestion des clés ne peut pas être accordée à une clé.
Le modèle ne reçoit jamais d'identifiant brut ; la passerelle d'outil backend l'injecte au moment de l'exécution. Lorsqu'un agent agit au nom du membre qui a lié un outil, le jeton de ce membre est lu du coffre-fort par livraison et le connecteur publie sous le nom de ce membre.
Le code écrit par un modèle de langage n'est pas fiable dès son existence. Il s'exécute dans une microVM isolée avec un noyau invité par tâche, détruite après l'exécution et jamais réutilisée entre les espaces de travail. Chaque exécution obtient des jetons à courte durée de vie et à portée limitée plutôt que des secrets à longue durée de vie.
L'accès réseau sortant du sandbox est refusé par défaut.
Chaque exécution est limitée par des plafonds de CPU, de mémoire, de temps écoulé et de crédits.
Chaque agent a un niveau d'autonomie que le client définit et peut modifier. À Suggest, il propose du travail et n'agit pas tant qu'on ne lui dit pas de le faire. À Review, il prépare une action et la retient en attente d'approbation. À Auto, il peut exécuter des actions dans les classes de risque que le client lui a autorisées, sous réserve des planchers ci-dessous.
Le travail ordinaire ne porte aucune classification de risque et ne demande jamais : lire, rechercher, rédiger, mettre à jour l'état interne. Au-dessus se trouvent les quatre classes de risque que le cadran gouverne : money, dépenser ou déplacer de l'argent ; send, communiquer en dehors de l'espace de travail ; record, créer ou modifier des enregistrements dans un outil connecté ; account, modifier les paramètres du compte ou de l'espace de travail.
Au-dessus du cadran se trouve un ensemble de catégories que le cadran ne peut pas libérer. L'argent quittant le compte du client, et les décisions qui causent un préjudice irréversible à une personne, demandent toujours d'abord l'approbation d'une personne nommée. Les catégories verrouillées sont les remboursements, les paiements, les versements et les décisions défavorables concernant une personne, avec une liste d'actions nommées : traiter une annulation, modifier un abonnement, une action de départ, un changement de compte, dépenser de l'argent. Une deuxième règle indépendante couvre le même domaine : un ensemble money (remboursements, crédits, réductions, allocations de fidélité, dépenses, paiement, frais de paiement et capture, modifications d'abonnement, réallocation publicitaire) et un ensemble people (offres envoyées ou acheminées, recommandations d'embauche, départ, tout ce qui est marqué comme défavorable).
Le mécanisme est un plancher plutôt qu'une interdiction. Une action verrouillée est forcée au niveau Review, de sorte qu'une personne nommée doit l'approuver avant qu'elle ne s'exécute, et l'approbateur, l'action et la cible sont écrits dans le journal d'audit. Si personne n'approuve, elle ne s'exécute pas. Une action que le système ne peut pas classer avec confiance est traitée comme verrouillée.
L'assouplissement de l'autonomie est réservé au propriétaire de l'espace de travail, de sorte qu'un changement de posture de risque est attribuable à une personne nommée. Les approbations en attente expirent sur une durée de vie et sont supprimées. Les plafonds de dépenses sont additionnés sur une action divisée en étapes, de sorte que la décomposition ne passe pas sous un plafond. Tout agent en cours d'exécution peut être arrêté depuis l'application.
Chaque action entreprise par un agent ou une personne est enregistrée dans un journal d'audit en ajout seul dans l'espace de travail du client. Le journal ne peut pas être modifié ou supprimé, y compris par afka : une tentative de modification ou de suppression d'une entrée est rejetée.
Une ligne contient l'acteur, l'action, la cible, l'horodatage, le coût en crédits, l'identifiant d'exécution, une référence à l'approbation autorisant le cas échéant, et si l'initiateur était une personne ou un agent.
Les clients exportent le journal eux-mêmes. Une fonction côté serveur vérifie le jeton de l'appelant, résout le locataire sur le serveur et vérifie une capacité d'export nommée : les propriétaires et les administrateurs la possèdent toujours, un membre seulement s'il en a reçu l'autorisation. Les formats sont CSV et NDJSON, ce dernier pour un système de gestion des informations et des événements de sécurité. L'export écrit sa propre ligne dans le journal.
L'export n'est pas signé cryptographiquement ou certifié, et un client ne doit pas présenter un export à un tribunal, un régulateur ou une contrepartie comme étant inviolable.
Lorsque la fonctionnalité de réunion est activée, un assistant nommé rejoint l'appel en tant que participant visible et s'annonce à son arrivée. afka ne rejoint pas un appel de manière couverte et n'offre aucun mode dans lequel il le ferait.
afka transcrit ; afka n'enregistre pas la vidéo. Il n'y a pas d'enregistrement vidéo et pas de bibliothèque d'enregistrements. Ce qui est conservé est une transcription et les résultats dérivés : résumés, actions et travaux de suivi.
Les transcriptions de réunion et les échantillons bruts de reconnaissance vocale sont supprimés selon une fenêtre glissante de trente (30) jours par un balayage automatique quotidien. Sur la même fenêtre, l'invite stockée d'une tâche et le contexte stocké d'une approbation sont vidés tandis que les enregistrements eux-mêmes sont conservés. Les échantillons vocaux se trouvent dans une table que ni le rôle de base de données anonyme ni le rôle authentifié ne peuvent lire.
Le journal d'audit ne contient aucun contenu vocal ou message.
Une jointure programmée peut être annulée avant l'appel ; l'assistant peut être supprimé pendant un appel, ce qui met fin à la transcription ; et un appel avec sa transcription peut être supprimé après, une suppression que le produit refuse jusqu'à ce que l'assistant ait été supprimé. Le consentement est la responsabilité du client : certaines juridictions exigent le consentement de chaque participant. Le participant qui s'auto-annonce n'est pas un substitut à ce processus, comme l'énoncent les Conditions d'utilisation.
afka stocke et traite régulièrement les données des clients aux États-Unis. Le calcul des applications, c'est-à-dire l'hébergement des applications, le worker en arrière-plan et l'entrée vocale, s'exécutent aux États-Unis, dans la région déclarée comme Oregon. Le cache chaud, la limitation de débit et l'analyse des produits s'exécutent également dans des régions des États-Unis.
La base de données gérée principale est située aux États-Unis, dans la région East US (Virginie du Nord).
afka n'offre pas de résidence des données dans l'Union européenne. Pour les transferts en dehors de l'Espace économique européen, du Royaume-Uni et de la Suisse, l'accord de traitement des données intègre les clauses contractuelles types et l'addendum du Royaume-Uni.
Tout le trafic vers afka est acheminé via TLS. Le chiffrement au repos est fourni par les fournisseurs de base de données gérée, de stockage et d'hébergement sous-jacents. Les réponses orientées vers le navigateur comportent ces en-têtes :
Une politique de sécurité du contenu est appliquée. Parallèlement à celle-ci, une politique plus stricte s'exécute en mode rapport uniquement, signalant les violations à un point de terminaison dédié, de sorte que les règles plus strictes sont mesurées par rapport au trafic réel avant l'application ; ces rapports sont supprimés après trente (30) jours. Les formulaires publics sont protégés par un défi de détection de bot géré à la périphérie.
L'accès aux plateformes de production est accordé selon le principe du moindre privilège, authentifié auprès de chaque fournisseur, et révoqué quand il n'est plus nécessaire. Il n'y a pas d'accès systématique au contenu client : un membre du personnel d'afka ne lit pas le contenu des messages client dans le cours normal de l'exploitation du service. L'accès au support est limité à ce que la question soulevée exige. Chaque personne autorisée à traiter les données client est soumise à une obligation de confidentialité écrite qui survit à la fin de son engagement.
La clé de la base de données administrative est utilisée côté serveur uniquement et n'est jamais exposée au navigateur ou à un sandbox.
L'authentification unique SAML 2.0 est fournie, construite sur la plateforme d'authentification gérée, et fonctionne avec n'importe quel fournisseur d'identité SAML 2.0. Elle est liée à un domaine d'entreprise qui doit être vérifié avant utilisation, un domaine par espace de travail.
L'application, c'est-à-dire désactiver la connexion par mot de passe pour le domaine vérifié, est fournie désactivée et ne peut pas être activée tant qu'une authentification unique réussie n'a pas été effectuée, de sorte que l'application ne peut pas verrouiller un administrateur hors d'un espace de travail dans lequel elle n'a jamais fonctionné. L'authentification unique est disponible sur le plan libre-service le plus élevé et sur les plans d'entreprise, pas sur les plans inférieurs.
La synchronisation d'annuaire SCIM n'est pas intégrée. Il n'y a pas d'approvisionnement ou de déprovision automatisés pilotés par l'annuaire. La suppression d'une personne se fait dans l'application ou, lorsque l'application est activée, chez le fournisseur d'identité.
afka n'utilise pas les données des clients pour former des modèles d'IA à usage général. afka ne vend pas les données des clients et ne les utilise pas pour la publicité ou le profilage comportemental entre contextes.
Les engagements d'afka concernant le comportement de ses fournisseurs d'IA reflètent les arrangements contractuels en vigueur avec chacun d'eux, et un fournisseur peut modifier ses conditions unilatéralement. Si afka devient consciente qu'un tel changement réduirait matériellement la protection applicable aux données des clients, elle donnera un préavis par le processus de changement de sous-traitant dans le DPA, qui comporte un délai de préavis de trente (30) jours, un droit d'objection et une voie pour résilier la partie affectée du service. Le DPA lie également afka à exiger que ses fournisseurs d'IA n'utilisent pas les données personnelles des clients pour former des modèles à usage général.
afka utilise un petit nombre de fournisseurs de modèles d'IA sous contrat : Anthropic pour les modèles de langage principaux, utilisés chaque fois qu'un agent s'exécute ; Moonshot comme niveau de secours en direct pour ces modèles ; OpenAI pour la reconnaissance vocale uniquement ; Voyage AI pour les embeddings utilisés pour indexer et récupérer les connaissances de l'espace de travail ; et Tavily pour l'étape de recherche web. Ces fournisseurs sont nommés dans la liste des sous-traitants publiée dans la Politique de confidentialité, qui fait partie du DPA, et un changement à cette liste est notifié à l'avance par le processus décrit ci-dessus.
Si vous avez découvert un problème de sécurité dans afka, veuillez nous le signaler. Écrivez à support@afka.ai avec suffisamment de détails pour le reproduire, et afka reconnaîtra le rapport et vous tiendra informé pendant qu'il est enquêté et corrigé. afka ne poursuivra pas un chercheur qui signale de bonne foi, évite d'accéder ou de détruire les données d'autres personnes, et donne à afka une occasion raisonnable de corriger le problème en premier.
afka ne gère pas un programme de prime aux bogues rémunéré. Ce qu'afka offre est un accusé de réception rapide, un vrai correctif, et un crédit public si vous le souhaitez.
Écrivez à support@afka.ai et afka enverra, sans appel et sans processus de qualification : le DPA selon les conditions standard, prêt à signer, avec l'Annexe II comme inventaire de contrôle détaillé ; un mappage des contrôles d'afka à n'importe quel cadre que vous nommez ; votre propre questionnaire de sécurité complété ; et une réponse directe sur n'importe quel contrôle de cette page.
Consultez également les Conditions d'utilisation, qui régissent l'autonomie, les approbations et la responsabilité des actions d'un agent, et la Politique de confidentialité. Lorsque cette page et le DPA diffèrent, le DPA prévaut.