Aller au contenu

Ce que nous protégeons, comment, et ce qui manque encore.

Placer une passerelle devant votre trafic d'IA est une vraie décision de confiance, prise par quelqu'un à qui l'on a remis un questionnaire et une échéance. Cette page est écrite pour cette personne. Chaque contrôle ci-dessous nomme le mécanisme qui l'applique, chaque date est un engagement plutôt qu'une aspiration, et ce que nous n'avons pas est listé aussi clairement que ce que nous avons.

Les comptes INFRO sont en libre-service. Le catalogue, la documentation et le contrat d'API sont publics, la passerelle est déployée, et tout ce qui va au-delà de la v1 est marqué Plus tard. Offres et essai

Ce sont des engagements sur notre propre calendrier, et non des affirmations sur les conclusions d'un auditeur. Rien ici ne dit qu'INFRO est certifié, car il ne l'est pas — et là où une date n'est pas encore convenue avec le cabinet d'audit, cette page le dit plutôt que d'en estimer une.

Aucune date n'est encore engagée. Un cabinet d'audit est mandaté pour SOC 2. La période d'observation n'est pas planifiée, il n'y a donc rien à publier ici — et nous préférons le dire plutôt que d'annoncer un trimestre non convenu avec le cabinet. Une fois planifiées, les dates apparaîtront ici, plutôt que d'être envoyées à chaque évaluateur, pour que tout le monde nous tienne au même engagement. Si votre calendrier en dépend, dites-le-nous et nous vous dirons où en est réellement la planification — sales@infro.io.

SOC 2 Type I

Auditeur mandaté

L'avis d'un auditeur selon lequel les contrôles décrits sur cette page sont conçus de façon appropriée et étaient en place à une date précise. Il ne dit rien de leur fonctionnement dans la durée — c'est le rôle du type II.

L'observation commence
Pas encore publié
Rapport attendu
Pas encore publié

À l'issue, cette page nomme le cabinet d'audit, la date du rapport et les critères de services de confiance couverts, et le rapport lui-même est transmis sous NDA. Tant que le rapport n'existe pas, ni le cabinet ni le périmètre ne sont revendiqués ici.

SOC 2 Type II

Auditeur mandaté

L'avis d'un auditeur selon lequel ces contrôles ont fonctionné efficacement sur une fenêtre d'observation, soit le rapport que réclament le plus souvent les revues de sécurité.

La fenêtre d'observation commence
Pas encore publié
La fenêtre d'observation se termine
Pas encore publié
Rapport attendu
Pas encore publié

Une fenêtre de type II ne peut pas être comprimée : le rapport ne dure que le temps de la période observée. Si la fenêtre bouge, la date ici bouge avec elle et le changement est indiqué plutôt que corrigé en silence.

ISO 27001

En évaluation

Certification d'un système de management de la sécurité de l'information plutôt que d'un ensemble de contrôles. Les évaluateurs hors des États-Unis la demandent plus souvent que SOC 2.

À l'étude. Aucun auditeur n'est mandaté et aucune date n'est engagée — il n'y a donc pas de date sur cette page, et il n'y en aura pas tant qu'il n'y aura rien à engager. Si ISO est une exigence stricte pour vous, dites-le dans votre premier e-mail ; c'est un signal utile et il peut changer l'ordre dans lequel nous procédons.

Nous ne détenons aucune certification aujourd'hui, et rien ci-dessus ne dit le contraire. Quand un rapport existera, cette page nommera le cabinet d'audit, la date du rapport et les critères couverts, et le rapport sera transmis sous NDA. D'ici là, ce que nous pouvons offrir, ce sont les contrôles ci-dessous, les réponses au questionnaire et une réponse franche sur l'état réel de l'audit — et si votre processus exige un rapport avant signature, la bonne réponse est d'attendre plutôt que de négocier.

Chacun de ces contrôles est en place aujourd'hui, et chacun nomme le mécanisme plutôt que l'intention — un trigger de base de données, une liaison, un en-tête déployé. Quand un contrôle est une politique plutôt qu'un mécanisme, il le dit.

Identifiants et clés

Les identifiants de fournisseur sont chiffrés et liés à un seul locataire
Les clés de fournisseur que vous connectez sont chiffrées en AES-256-GCM avec une clé détenue comme secret du Worker, jamais dans la base de données. Les identifiants de l'organisation et de la connexion sont liés comme données authentifiées additionnelles : un identifiant chiffré copié dans la ligne d'un autre locataire — ou dans une autre ligne du même locataire — échoue en mode fermé au lieu de se déchiffrer. Les identifiants connectés pour le rapprochement des coûts sont chiffrés séparément, avec leur propre liaison.Lié à conn:<organization>:<connection> pour les identifiants d'inférence, et à billing:<organization>:<provider kind> pour les identifiants d'API de coûts. Une divulgation de la base de données seule n'ouvre rien.
Il n'y a d'affichage nulle part
Une fois un identifiant de fournisseur enregistré, aucune interface ne le renvoie — ni la console, ni l'API, ni la console interne des opérateurs. Ce que l'une ou l'autre partie peut voir, ce sont les quatre derniers caractères et les horodatages. Si vous perdez la clé, vous la renouvelez chez le fournisseur ; nous ne pouvons pas vous la montrer.Les requêtes de connexions de la console des opérateurs ne sélectionnent pas du tout la colonne chiffrée. Un bouton d'affichage est la fonctionnalité qui transforme une session compromise en l'ensemble des clés de fournisseurs de tous les clients.
Les clés API d'INFRO sont hachées au repos
Une clé de passerelle fait 32 octets issus d'une source aléatoire cryptographique. Ce que nous stockons, c'est son condensat SHA-256, un préfixe d'affichage et les quatre derniers caractères : une divulgation de la base de données ne divulgue donc aucun identifiant utilisable. La révocation écrit une pierre tombale au lieu de supprimer la ligne, pour qu'une entrée de cache périmée encore en propagation entre sites ne puisse pas la masquer.SHA-256 plutôt qu'un KDF de mot de passe est un choix délibéré : il n'y a pas de dictionnaire à attaquer sur 32 octets aléatoires, et un KDF ajouterait 50 à 200 ms de calcul facturé à chaque requête.
La clé de chiffrement peut être renouvelée sans votre intervention
Renouveler la clé qui chiffre les identifiants des clients rechiffre sur place chaque identifiant stocké. Cela ne demande à aucun client de ressaisir quoi que ce soit, et l'algorithme stocké porte une chaîne de version pour qu'un futur schéma puisse coexister avec l'actuel au lieu d'exiger un jour de bascule.Énoncé clairement : perdre cette clé sans sauvegarde est irrécupérable, et chaque client devrait reconnecter chaque fournisseur. La sauvegarde et la restauration sont consignées comme procédure opérationnelle.

Votre contenu

Nous n'entraînons pas de modèles sur vos données, et ne les vendons pas
INFRO n'utilise pas vos prompts, entrées ou sorties pour entraîner quoi que ce soit, et ne les vend pas. Les fournisseurs que vous connectez traitent vos données selon vos propres accords et réglages de compte chez eux — les contrôles de journalisation d'INFRO ne modifient pas ces réglages, et ne le peuvent pas.C'est le seul contrôle de cette page qui soit une politique plutôt qu'un mécanisme. Il est énoncé dans les conditions et le DPA, là où il est opposable.
La capture des prompts et des complétions est désactivée par défaut
Les métadonnées des requêtes — modèle, fournisseur, route, nombre de tokens, latence, coût estimé — sont toujours enregistrées, car la mesure, les budgets et la gouvernance sont ce qu'est le produit. Le contenu des prompts et des complétions ne l'est pas, sauf si une organisation active la capture. La colonne de base de données est désactivée par défaut ; il n'existe aucune offre sur laquelle elle serait activée par défaut.org_settings.prompt_logging_enabled, DEFAULT false NOT NULL depuis la première migration.
La durée de conservation est la vôtre, et le balayage de suppression est réel
Quand la capture est activée, vous choisissez la durée — 24 heures, 14, 30, 60 ou 90 jours, ou un an — et ce qui est stocké est la plus courte entre votre choix et le plafond de votre offre : une surface ne peut donc jamais proposer une durée que l'offre ignorerait en silence. Une tâche planifiée supprime les charges capturées une fois leur expiration passée, par lots bornés, pour qu'un arriéré ne devienne pas une longue transaction sur une table dans laquelle écrit le chemin de la requête.Chaque ligne de charge porte son propre expires_at ; la purge s'exécute sur le cron à la minute de la plateforme et son retard fait partie des conditions qui déclenchent une alerte opérateur. La suppression est un DELETE, pas un indicateur.
L'export des traces est une liste d'autorisation, pas une copie
Si vous envoyez des spans OpenTelemetry à votre propre collecteur, l'ensemble d'attributs est construit champ par champ et non en étalant une ligne de base de données : une colonne interne ajoutée plus tard ne peut donc pas fuiter par défaut vers votre backend d'observabilité. L'endpoint du collecteur doit être en HTTPS, imposé par une contrainte de base de données, et les en-têtes que vous configurez sont chiffrés comme n'importe quel autre identifiant.C'est le seul endroit où INFRO envoie délibérément vos données à un hôte tiers que vous avez choisi, et le seul où une fuite serait durable. Un test vérifie que les identifiants internes sont absents des octets encodés.

Accès et responsabilité

Le journal d'audit ne peut pas être réécrit
Chaque changement de politique, mise à jour d'identifiant, renouvellement de clé, attribution d'offre et changement d'appartenance est une nouvelle ligne portant un acteur et un horodatage. Ces lignes rejettent UPDATE, DELETE et TRUNCATE au niveau de la base de données — pas par convention, ni par du code applicatif qu'un script de support pourrait contourner. L'historique de votre organisation est un enregistrement et non une valeur.Imposé par un trigger de base de données. Ni un ingénieur d'INFRO devant un prompt psql ni une application compromise ne peut la modifier discrètement.
L'identité des clients et celle des opérateurs ne partagent rien
La console client et la console interne des opérateurs s'authentifient auprès de deux systèmes distincts : tables distinctes, noms de cookies distincts, secrets de signature distincts, listes d'origines autorisées distinctes. Une session client présentée à un endpoint d'opérateur y est anonyme et non simplement moins privilégiée — elle porte un nom que ce système ne cherche pas, signé avec une clé qu'il ne détient pas, face à une table qu'il ne lit pas.Le Worker refuse de démarrer si les deux secrets de signature sont égaux ou si les deux listes d'origines se recoupent. L'inscription des opérateurs est désactivée de façon permanente ; les comptes sont provisionnés, et la ligne d'un opérateur suspendu est conservée précisément pour qu'un contrôle d'existence ne puisse pas le laisser revenir.
Double authentification des opérateurs, et élévation sur les actions destructrices
L'authentification à deux facteurs TOTP est disponible pour chaque opérateur et désactivée par défaut — une décision délibérée, énoncée ici plutôt que sous-entendue. Lorsqu'elle est activée, chaque session d'opérateur doit présenter un code et un mot de passe ne le remplace jamais. Indépendamment de ce réglage, les actions qui changent l'argent, les identifiants ou l'accès d'un autre opérateur exigent un second facteur présenté dans les 15 dernières minutes ; lorsque l'authentification à deux facteurs est désactivée, cette élévation est le mot de passe. Dix échecs consécutifs verrouillent le compte pendant quinze minutes.La preuve est une ligne de facteur par session, écrite uniquement par le hook de vérification : une session créée dans un autre navigateur n'ouvre donc rien. Les codes sont à usage unique ; les codes de secours sont à usage unique et stockés chiffrés.
Double authentification, passkeys et sessions pour vos propres utilisateurs
Chaque compte peut activer l'authentification à deux facteurs avec une application d'authentification et dix codes de récupération à usage unique, et enregistrer des passkeys ou des clés de sécurité matérielles, qui connectent seules ou servent de second facteur après un mot de passe. Un propriétaire ou un administrateur peut exiger l'authentification à deux facteurs pour toute l'organisation : un membre qui ne l'a pas n'accède à rien dans cette organisation tant qu'il ne l'a pas configurée. L'authentification unique satisfait l'exigence, car votre fournisseur d'identité applique sa propre MFA. Chaque compte peut voir où il est connecté et mettre fin à n'importe quelle session.Les codes sont à usage unique et dix échecs verrouillent le compte pendant quinze minutes ; il n'y a pas de « se souvenir de cet appareil ». Retirer un facteur exige un second facteur présenté dans les dix dernières minutes, pas le seul mot de passe. Une passkey ne connecte seule que si l'appareil a vérifié l'utilisateur. Les codes envoyés par e-mail et par SMS ne sont pas proposés.
Votre organisation n'est jamais lue dans la requête
Les endpoints de la console et des opérateurs prennent l'organisation dans la session authentifiée et la transmettent comme argument explicite : un site d'appel ne peut donc pas l'omettre, et un paramètre de corps ou de requête nommant une organisation ne peut pas devenir une décision d'autorisation prise à partir d'une entrée contrôlée par l'attaquant.Un test structurel fait passer de vraies lignes dans les vraies projections de réponse avec une valeur sentinelle, et vérifie que les identifiants internes et les corps d'erreur amont n'atteignent jamais une réponse client.

La surface de la plateforme

En-têtes de sécurité sur les trois surfaces
infro.io, la console client et la console des opérateurs envoient chacun une Content-Security-Policy, HSTS, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, une Referrer-Policy, une Permissions-Policy et Cross-Origin-Opener-Policy. La console des opérateurs ajoute une politique de ressources et une directive no-index, et sa page de connexion porte une politique à nonce par réponse qui n'autorise aucun script en ligne.Vérifiable de l'extérieur avec curl -I sur l'un quelconque des trois noms d'hôte. Un script versionné parcourt chaque route avec la politique appliquée et échoue à la moindre violation : une origine tierce ajoutée ne peut donc pas passer inaperçue.
Les webhooks sortants sont signés et se renouvellent sans interruption
Chaque webhook que nous envoyons porte une signature HMAC-SHA256 sur l'horodatage et le corps brut exact : vous pouvez ainsi vérifier à la fois l'authenticité et que la charge n'a pas été altérée en transit. Pendant une rotation de secret, une livraison est signée avec l'ancien et le nouveau secret, pour que vous puissiez adopter le nouveau sans perdre de livraison.Format d'en-tête INFRO-Signature: t=<unix>,v1=<hex>, documenté avec du code de vérification. La signature et l'horodatage sont la raison pour laquelle un webhook est traité comme une notification à confirmer, jamais comme une autorité sur laquelle agir.
Une seule surface d'erreurs documentée
Chaque refus de la passerelle fait partie d'un ensemble publié de types et de codes, y compris ceux qui sont de notre fait. La taille des requêtes est limitée avant toute analyse, avec un 413 documenté plutôt qu'un dépassement de délai, et les surfaces d'authentification, de connexion et de prospects sont limitées en débit selon l'adresse réseau de l'appelant.Publié en entier sur /docs/api/errors avant que vous n'écriviez une ligne de code. Les en-têtes de limite de débit indiquent lesquels sont exacts et lesquels sont une borne supérieure.
Une liste nommée de sous-traitants, avec préavis
Les fournisseurs auxquels INFRO a recours sont nommés sur /subprocessors, avec ce que chacun peut réellement voir et où il s'exécute, et un préavis de 30 jours avant qu'un nouveau ne commence à traiter des données. Les fournisseurs d'IA qui servent vos requêtes sont ceux que vous avez choisis et avec lesquels vous contractez directement — ils ne sont pas des sous-traitants d'INFRO, et la page explique pourquoi cette distinction est réelle plutôt que commode.Deux fournisseurs d'infrastructure nommés aujourd'hui. La base de données s'exécute à Francfort et la passerelle à côté ; les requêtes entrent dans le réseau de Cloudflare là où se trouve l'appelant, et la page le dit plutôt que de suggérer une région.

Cette liste existe parce que le reste de la page vaut moins sans elle. Si l'un de ces points bloque un achat, c'est une conversation que nous préférons avoir dès votre premier e-mail plutôt qu'en quatrième semaine d'évaluation.

Ni SOC 2 ni ISO 27001 aujourd'hui
Aucune n'est détenue. Un audit exige un historique d'exploitation à examiner et le nôtre est court. La feuille de route ci-dessus est ce à quoi nous nous sommes engagés à la place ; si votre processus ne peut pas avancer sans rapport en main, c'est une raison d'attendre plutôt qu'une raison de négocier.
Pas de test d'intrusion indépendant
Rien sur cette page n'a été relu par quelqu'un en dehors de l'équipe qui l'a écrite. Nous tenons une revue de sécurité interne permanente organisée par actif, et c'est une auto-évaluation — ce qui fait la différence entre avoir réfléchi à quelque chose et avoir fait essayer quelqu'un.
Pas de traitement exclusivement dans l'UE ni régional
Les requêtes entrent dans le réseau de Cloudflare à l'endroit le plus proche de l'appelant, où TLS est terminé, et la passerelle elle-même s'exécute à Francfort, à côté de la base de données. Ce placement raccourcit les allers-retours vers la base ; ce n'est pas un contrôle de résidence des données, et un traitement limité à une région exige des droits d'infrastructure que nous n'avons pas achetés. Un nom d'hôte d'allure européenne qui ne limite pas réellement le traitement est une affirmation que vous pourriez réfuter en une seule requête : nous n'en proposons donc pas.
Le service hébergé est multi-locataire
Sur chaque offre en libre-service, les organisations partagent le service hébergé et l'isolation entre elles est logique et non physique. Si votre exigence est que notre logiciel s'exécute dans votre propre infrastructure, il s'agit d'un déploiement auto-hébergé ou hybride dans le cadre d'un accord Enterprise, défini et convenu contrat par contrat ; aucune offre en libre-service n'en inclut un.
Pas de SLA de disponibilité publié sur les offres en libre-service
Un service sans historique d'exploitation ne peut pas honnêtement publier d'engagement de disponibilité : nous n'en publions donc aucun. Un accord Enterprise peut porter un SLA contractuel avec recours, convenu contrat par contrat. L'état de la passerelle se vérifie depuis votre propre navigateur sur /status.
Le SSO et SCIM sont récents
Le SSO SAML et OIDC et le provisionnement SCIM 2.0 sont implémentés et inclus à partir de l'offre Business, conditionnés à un domaine vérifié par DNS. Ils n'ont pas encore tourné en production avec chaque fournisseur d'identité : nous configurons donc la première connexion avec chaque client plutôt que de la qualifier de libre-service.
Les garde-fous fonctionnent par motifs ; il n'y a pas de garde-fous par classificateur
Les garde-fous pour les complétions de chat, inclus à partir de l'offre Business, vérifient les prompts et les réponses par rapport à des motifs fixes — adresses e-mail, numéros de téléphone, numéros de carte, IBAN, numéros de sécurité sociale américains, adresses IP, clés API et termes que vous listez — et bloquent, masquent ou signalent ce qui correspond. La recherche par motifs manque tout ce qui sort de ces formats. Rien ne détecte l'injection de prompt, les jailbreaks, la toxicité ni les demandes hors sujet, et les images, l'audio et les endpoints autres que les complétions de chat ne sont pas inspectés. Si votre revue exige un classificateur de contenu sur le chemin de la requête, INFRO n'en fournit pas.
Pas de plafond de coût par requête
Les budgets plafonnent le total qu'une organisation, un projet, un membre ou une clé peut atteindre, et les limites de débit plafonnent le volume de requêtes. Ce qui n'existe pas encore, c'est un contrôle qui refuse une requête isolée anormalement coûteuse. Un gros prompt légitime et un prompt abusif se ressemblent pour la passerelle, et un client s'attendrait raisonnablement à ce contrôle.
Les limites de débit sont appliquées par site
Les limites sont comptées par le service de limitation de débit de Cloudflare à l'endroit où la passerelle s'exécute, et non par un compteur global unique. La passerelle est placée à Francfort : l'essentiel du trafic y est donc compté, mais le placement est une préférence de routage et non une garantie, et le trafic traité ailleurs est compté séparément — une clé peut donc brièvement dépasser sa limite nominale. C'est un compromis délibéré — l'alternative du compteur global ferait plafonner le plus gros client par notre architecture plutôt que par sa limite — et la documentation de l'API indique quels en-têtes de limite de débit sont exacts et lesquels sont une borne supérieure.

Nous indiquons ce qui n'est pas en place aussi clairement que ce qui l'est. Si une ligne de ce tableau bloque un achat, nous préférons en parler maintenant plutôt qu'après un contrat.

Aucun entraînement sur vos donnéesEngagé
INFRO n'entraîne pas de modèles sur vos prompts, entrées ou sorties et ne les vend pas. L'utilisation des données par les fournisseurs d'IA que vous connectez suit vos accords et réglages avec eux.
Journalisation du contenu désactivée par défautEngagé
Les métadonnées d'usage servent au comptage de la plateforme, aux estimations de coûts et à la gouvernance. Les journaux facultatifs de prompts et de réponses sont désactivés par défaut, stockés à part et limités par la durée de conservation de votre offre.
Clés hachées au reposEngagé
Les clés API sont stockées sous forme de condensats SHA-256 de 32 octets issus d'un CSPRNG. Une divulgation de la base de données ne divulgue aucun identifiant utilisable, et la révocation écrit une pierre tombale pour qu'une entrée de cache périmée ne puisse pas la masquer.
Journal d'audit en ajout seulEngagé
Les lignes d'audit ne peuvent être ni modifiées ni supprimées — la base de données elle-même s'y oppose. Chaque changement de politique, mise à jour d'identifiant, renouvellement de clé et changement d'appartenance est une nouvelle ligne portant un acteur : l'historique de votre organisation ne peut donc pas être réécrit en douce.
Liste des sous-traitants publiéeEngagé
Les fournisseurs d'infrastructure sont nommés sur /subprocessors, avec un préavis de 30 jours avant qu'un nouveau ne commence à traiter des données, sous réserve de l'exception d'urgence qui y est décrite. Vous choisissez et contractez directement avec les fournisseurs d'IA que vous connectez.
SOC 2 / ISO 27001Pas encore
Non détenue, et non revendiquée. Une certification exige un historique d'exploitation à auditer, et celui de la passerelle est court. Ce qui est publié à la place, c'est la feuille de route sur /trust : un cabinet d'audit est mandaté pour SOC 2 sans fenêtre d'observation encore programmée, ISO 27001 est à l'étude sans auditeur ni date, et aucune des deux n'est présentée autrement. Les dates y apparaissent quand le cabinet les arrête, pas avant.
DPA avec clauses contractuelles typesEngagé
Publié intégralement sur /dpa, intégrant les CCT avec l'avenant britannique. La signature se fait par e-mail et non depuis la console — il n'existe pas de circuit de contre-signature, et la page le dit plutôt que de suggérer un bouton.
Résidence des données dans l'UEPas encore
Nécessite des droits d'infrastructure que nous n'avons pas achetés. Un nom d'hôte qui a seulement l'air européen est une affirmation qu'un client peut démentir en une seule requête : nous n'en servirons donc pas tant que le traitement n'est pas réellement restreint.

Nos réponses aux questions que pose réellement une revue de sécurité — traitement des données, chiffrement, gestion des clés, contrôle d'accès, supervision, conformité — publiées sous forme de document texte que vous pouvez lire, comparer et coller dans vos propres outils.

Télécharger les réponsesLire dans le navigateur

C'est du Markdown plutôt qu'un tableur CAIQ, volontairement. La valeur du CAIQ tient à la numérotation de ses questions, et un CAIQ partiellement rempli laisse croire à une inscription dans un registre où nous ne figurons pas — ce document couvre donc le même terrain dans l'ordre où un évaluateur le lit, dans un format que vos outils comme les nôtres peuvent comparer. Il est généré à partir des mêmes données que cette page : les deux ne peuvent pas se contredire.

Envoyez aussi votre propre questionnaire, sous la forme qu'il prend. Nous répondons à chaque question, y compris celles dont la réponse est non, et précisons lesquelles ont une date. Écrivez à sales@infro.io.

Lisez-les avant de nous poser la question. Aucun n'exige d'appel, de NDA ni de conversation commerciale pour être consulté.

Accord de traitement des données
Le texte complet, intégrant les clauses contractuelles types avec l'addendum britannique, y compris l'obligation de notification des violations et le calendrier de rétention. La signature se fait par e-mail — la console ne propose pas de circuit de contre-signature, et la page le dit plutôt que de suggérer un bouton.
Sous-traitants
Chaque prestataire auquel INFRO fait appel, ce que chacun peut réellement voir, où il s'exécute, et un préavis de 30 jours avant qu'un nouveau ne commence à traiter des données. Il explique aussi pourquoi les fournisseurs d'IA que vous connectez ne sont pas des sous-traitants d'INFRO.
Politique de confidentialité
Ce qui est collecté, les bases légales, la durée de conservation de chaque catégorie, et les droits dont dispose une personne concernée. En accord avec les fenêtres de rétention de cette page, sans les contredire.
Politique d'utilisation acceptable
Ce qui ne peut pas être construit sur la plateforme, y compris les catégories sans voie d'approbation, et ce qui se passe quand nous le découvrons. Rédigé dans le vocabulaire des réseaux de cartes, car ce sont eux qui le demandent.
Politique de divulgation des vulnérabilités
Ce qui est dans le périmètre, comment tester sans nuire à un autre client, ce à quoi nous nous engageons quand vous signalez, et la protection juridique de la recherche de bonne foi. Également publié sous /.well-known/security.txt.
Conditions d'utilisation
Le contrat commercial, l'entité exploitante et sa juridiction, et ce qu'il advient d'un compte à son terme.
La taxonomie des erreurs
Chaque refus que la passerelle peut émettre, publié avant que vous n'écriviez une ligne de code — y compris ceux qui sont de notre fait plutôt que du vôtre.
Traitement des données, dans la référence de l'API
Champ par champ : ce qui est enregistré sur chaque requête, ce que la capture ajoute quand une organisation l'active, et comment la fenêtre de rétention est appliquée. La version pour ingénieurs du contrôle de rétention décrit plus haut.
Clés et authentification
Comment les clés de passerelle sont émises, limitées à un projet et un environnement, restreintes par rôle et révoquées — écrit pour la personne qui doit décider qui, dans votre organisation, en reçoit une.
Sécurité des clés API d'IA
Où se trouvent les clés fournisseurs avec et sans passerelle, les quatre contrôles que passe chaque clé de passerelle avant l'appel à un fournisseur, et que faire dans la première heure après la fuite d'une clé.

Vous avez trouvé quelque chose ?

Envoyez-le à security@infro.io. Cette boîte est lue par les personnes qui peuvent corriger le problème, et elle est réservée aux signalements de vulnérabilités, pas au support.

Le périmètre, les règles de test et la protection juridique complète : la politique de divulgation des vulnérabilités.

  • Nous accusons réception sous un jour ouvré et vous tenons informé pendant notre enquête, y compris quand la réponse est que nous le savions déjà.
  • La recherche de bonne foi est protégée ici. Nous n'engagerons pas de poursuites pour des tests qui évitent les atteintes à la vie privée, la dégradation du service, et la destruction ou l'exfiltration de données qui ne sont pas les vôtres.
  • Il n'existe pas de programme de bug bounty ni de rémunération. Nous le disons d'emblée, car le découvrir après le travail est pire que le savoir avant.
  • Les questions commerciales et d'achats vont ailleurs — sales@infro.io pour une revue de sécurité ou un questionnaire, support@infro.io pour un compte que vous avez déjà.