Intramedial est en bêta restreinte. À l’inscription ou à la connexion, vous devez fournir le mot de passe de bêta-testeur que vous avez reçu ou en demander un à preview@intramedial.com. Merci.
Chargement…
Trust Center
Vérifiable
Une confiance à vérifier, pas à lire.
Intramedial décide de ce que les agents peuvent faire et tient le registre. Cette page expose comment cela fonctionne, ce qui est fixé et où, et ce que nous n’avons pas encore publié. Elle ne revendique aucune certification. Chaque affirmation renvoie au document ou à la source qui la fonde.
Les agents agissent quand le plan dit oui, et le registre dit pourquoi.
Faites passer actions d’agents, hash de contenu, contrôles d’API, requêtes DNS, webhooks, appels LLM et commits git par Intramedial. Obtenez un reçu signé vérifiable par tous – sans nous croire.
Chaque appel suit le même chemin. Les identifiants sont vérifiés à la porte d’entrée, le travail est fait et stocké dans la région propre au workspace, et la signature vient d’un module matériel de sécurité qui ne livre jamais sa clé.
Authentifier
La passerelle rattache l’identifiant à un seul workspace avant tout code d’outil. Les secrets sont stockés et comparés en hash SHA-256, en temps constant.
Relayer
Workspace et droits vont au service régional dans des en-têtes signés par nos propres services. Sans signature valide, le service refuse la requête.
Observer, consigner
Le service régional fait la requête des outils de relais et de veille, via le filtre sortant, ou consigne les faits que vous déclarez. Corps hachés, non stockés.
Signer
L’enveloppe est canonisée selon RFC 8785 et signée dans AWS KMS avec la clé Ed25519 de la région. Sans clé, le service refuse plutôt que d’en prendre une autre.
Vérifier partout
Le reçu porte l’id de sa clé dans les octets signés. Avec le reçu et la clé publique, chacun le vérifie sans nous, tant que la clé reste publiée.
02
Portée réelle
Ce que prouve un reçu et ce qu’il ne prouve pas.
Un reçu est un énoncé précis et étroit. Lisez les deux colonnes avant de vous y fier, et avant de demander à autrui de le faire.
Une signature valide prouve
Origine : le détenteur d’une clé de signature de bundle a signé exactement ces octets.
L’intégrité : rien dans l’enveloppe n’a changé depuis, pas un chiffre.
Une plage scellée : la racine de Merkle s’engage sur les enregistrements qu’elle contient.
Il ne prouve pas
Qu’un fait que vous déclarez est vrai. Certains outils signent des faits fournis, d’autres ce que nous observons ; la page de chaque outil précise lequel.
Qui a rédigé ou approuvé le contenu. Le reçu consigne un workspace, pas une personne.
L’heure réelle d’un événement. Il n’y a pas d’autorité d’horodatage tierce.
Que rien n’a eu lieu là où il n’y a pas de reçu.
Que nous sommes neutres au-delà de notre parole. Un journal public atteste les racines des lots horaires de hashes de reçus, mais aucun tiers ne contrôle ce que dit un reçu. Cette inscription publique est activée par défaut ; le propriétaire ou un administrateur du workspace peut la désactiver pour les reçus qui ne sont pas encore dans un lot.
Où il faut encore nous croire
La vérification est indépendante. La confiance se réduit à une liste nommée.
Vous croyez
Raison
En cas d’échec
La clé publique de vérification est la nôtre
Une signature prouve qui détient une clé, pas à qui elle est.
Une clé substituée fait passer des faux. Épinglez l’id de clé hors bande.
Nos clés de signature ne servent qu’au service de reçus
Le service signe ce que son code décide de signer.
Une clé détournée signerait des faits jamais survenus.
Nous observons honnêtement pour les outils observés
Les lignes du registre disent que le plan a vu ceci.
Un plan compromis pourrait écrire une fausse ligne de registre.
Sept clés Ed25519, une par juridiction de signature, servent à tous les workspaces. Leurs moitiés publiques sont publiées ; les privées sont créées et gardées par AWS Key Management Service.
Garde
Les clés sont générées dans des modules matériels de sécurité AWS KMS, validés FIPS 140-3 niveau 3 selon AWS.
Le service de reçus envoie des octets canoniques à KMS et reçoit une signature. Son identifiant ne peut que signer, jamais exporter une clé.
Aucune route API ne renvoie de clé privée. Les routes publiques : champs publics seuls.
Sans clé pour une région, le service répond 503 signing_unprovisioned ; si KMS est injoignable, 503 signer_unavailable. Il ne bascule jamais sur une autre clé et n’émet jamais de reçu non signé.
Rotation : cérémonie manuelle, sans calendrier. Une clé retirée reste publiée pour que les vieux reçus se vérifient.
Il n’existe à ce jour ni liste de révocation ni journal de transparence des clés. Une compromission serait annoncée par avis et par un changement du jeu publié.
La garde HSM empêche de copier une clé. Elle n’empêche pas qui peut déployer le service de lui faire signer : d’où la séparation des faits observés et déclarés.
Le jeu JWK lui-même, en cache une heure, ouvert à toute origine
/api/v1/ledger-bundles/anchors
Chaque clé publiée et son indicateur actif
/api/v1/ledger-bundles/snapshot
Une clé publique par son kid
Charger le jeu de clés et recalculer un id
curl -sSL https://ledger-bundles.api.intramedial.com/.well-known/ledger-bundles-keys.json -o keys.json
jq -r '.keys[] | [.kid, .jurisdiction] | @tsv' keys.json
// kid = 16 premiers octets du SHA-256 de la clé brute, base64url
Pour la meilleure garantie, chargez la clé une fois, stockez son kid et sa valeur x dans votre dépôt, et vérifiez contre cette copie. /docs/ledger-bundles-snapshot
04
Isolation
Contrôle d’accès et isolation
Chaque requête porte un identifiant que la passerelle rattache à un workspace avant tout outil. Voici comment identifiants, locataires et requêtes sortantes sont traités aujourd’hui.
01
Identifiants hachés
Clés API, jetons d’accès personnels et jetons de session sont stockés en hash SHA-256, affichés une fois, comparés en temps constant. Les clés expirent après 30 jours, 90 jours, un an ou jamais, et tournent avec 0 à 60 minutes de grâce.
02
Connexion et sessions
La connexion passe par Avonao ID. La durée de session, le délai d’inactivité et les réglages des cookies ne sont pas encore publiés ici, donc non indiqués. Ne comptez sur rien au-delà de ce que montre la page de connexion.
03
Scopes et rôles
Scopes lecture, écriture et gestion, limitables à des outils nommés. Émettre un reçu exige la permission tools.attest ; un rôle d’auditeur ne peut pas en créer. Échec = refus.
04
Locataires
La passerelle, pas l’appelant, fixe le workspace. Chaque lecture et écriture porte l’id du workspace ; un corps nommant un autre workspace est refusé. Séparation logique, en base régionale.
05
Requêtes sortantes
Cibles en localhost, noms internes et plages privées ou réservées sont refusés, à la soumission et avant chaque contrôle planifié. Pas de redirection suivie ; durée et taille bornées.
06
Limites de débit, abus
600 requêtes par minute par IP et 1 200 par compte à la passerelle. Sur agent.call, la détection signale scans ou credential stuffing à un humain ; elle ne suspend jamais seule.
Limites déclarées : le filtre sortant lit l’URL comme du texte et ne résout pas les noms d’hôte ; la seconde couche est que le service tourne sur le réseau Cloudflare, sans route vers l’espace privé. Les listes d’IP autorisées s’ouvrent si illisibles, pour qu’une panne de base ne bloque pas les clients.
05
Peu de données
Données protégées
Le service est conçu pour garder le moins possible. Pour l’attestation, il reçoit un hash, jamais le document ; pour les appels relayés, il hache les corps sans les garder.
Hash d’abord
Vous calculez un SHA-256 et l’envoyez. Nous ne recevons jamais document, prompt ni réponse.
Relais sans rétention
Corps et en-têtes relayés transitent et sont hachés. Les réponses ne sont gardées que si vous activez la rétention.
Reçus en ajout seul
Des triggers rejettent toute modif, et un hash de chaque reçu est en plus archivé dans un stockage à écriture unique (S3 Object Lock) pendant la période du forfait. Seules des routes auditées masquent ou suppriment, avec un événement d’audit.
Lisible veut dire lisible
URL, libellés et auteurs de commit sont en clair dans un reçu. N’y mettez rien que son lecteur ne doit pas voir.
Les régions
Reçus, veilles, compteurs de quota, traitement des requêtes relayées et signature tournent dans la région choisie à la création du workspace. Tableau de bord, site, connexion, facturation et compte sont servis depuis les États-Unis (US West) dans tous les cas.
Région
Code
Clé de signature AWS KMS
Stockage
US Ouest
wnam
us-west.
Lieu indicatif
Europe Centre
weur
eu.
Juridiction UE (imposée)
Asie-Pacifique
apac
asia.
Lieu indicatif
Océanie
oc
oc.
Lieu indicatif
Une région dit où les données sont stockées et traitées. Un workspace ne migre jamais ; une région injoignable fait échouer l’appel, sans repli sur une autre.
Chiffrement
Les données transitent en TLS entre vous et le service, et sont stockées chez notre hébergeur, Cloudflare, selon ses conditions de sécurité. Les reçus étant signés, toute modification de preuve stockée est détectable par qui la vérifie.
Suppression, effacement
La suppression du compte prend effet après 30 jours de grâce, pour exporter et restaurer. La tâche de suppression ne retire pas les reçus : ils expirent selon le forfait, ou vous les supprimez, ou vous nous le demandez. Un reçu déjà remis à autrui reste vérifiable par lui quoi que nous fassions.
Conservation
Reçus
Fenêtre du forfait : Free 7 jours, Starter 30, Pro 90, Pro+ 180, Team 365, Scale 730, Enterprise sur mesure.
Données compte et connexion
Jusqu’à suppression du compte, puis effacés après 30 jours de grâce.
Journaux techniques et compteurs de débit
30 jours au plus.
Audit de sécurité
Pendant la vie du workspace et après, la personne remplacée si l’effacement l’exige.
Pièces comptables
Selon les exigences fiscales, jusqu’à 7 ans.
Cache de rejeu idempotent
24 heures, avec le statut et l’id du reçu, jamais le corps.
Le statut est mesuré, pas écrit à la main. Les niveaux de service sont contractuels pour Enterprise, et la vérification ne dépend jamais de notre disponibilité.
La page de statut
Sondés chaque minute : la passerelle API dans chacune des sept régions de données, le serveur MCP, la découverte OAuth, les clés de signature publiées, le document did:web du signataire et la vérification des reçus. L’émission de reçus (un reçu de test signé avec la clé de production puis stocké) s’y ajoute dès que son workspace de sonde dédié est configuré ; d’ici là, elle n’est pas mesurée.
Un contrôle en échec ou de plus de 8 secondes vaut panne ; au-delà de 3 secondes, dégradé. Une sonde périmée affiche « pas de données », jamais vert.
Les incidents sont publiés avec mises à jour, par e-mail, flux Atom et JSON.
La page de statut n’est ni signée ni un accord de niveau de service.
Pour les forfaits Enterprise avec bon de commande signé, le SLA Enterprise fixe les conditions. Le support est assuré pendant les heures ouvrées et accuse réception des demandes Enterprise sous 1 heure ouvrée, 4 heures ouvrées ou 1 jour ouvré selon la gravité. Les forfaits en libre-service n’offrent ni engagement de disponibilité ni crédits de service ; leurs objectifs de réponse du support figurent sur la page des tarifs.
Service couvert indisponible, ou reçus impossibles à émettre, en production.
1 heure ouvrée
Gravité 2
Fonction majeure altérée ou dégradée, avec contournement.
4 heures ouvrées
Gravité 3
Problème mineur, question ou demande.
1 jour ouvré
Si la disponibilité passe sous 99,0 % trois mois de suite, ou quatre mois sur douze, le client peut résilier la commande visée avec remboursement au prorata.
Vérifier un reçu ne demande que le reçu et une clé publique. Cela marche même quand notre service est en panne.
07
Divulgation
Réponse aux incidents et divulgation des failles
Nos engagements si quelque chose tourne mal, et comment nous signaler une faiblesse avant qu’un autre la trouve.
72h
Violations de données
Nous avertissons le titulaire du compte par e-mail sans retard indu, et au plus tard 72 heures après avoir pris connaissance d’une violation touchant des données personnelles client, avec ce que l’on sait : nature, personnes et enregistrements touchés, conséquences probables, mesures prises. L’avis est complété au fur et à mesure.
Les incidents sont publiés sur la page de statut, avec une chronologie d’Investigating à Resolved. Lors d’un incident de gravité 1, les clients Enterprise reçoivent un avis initial puis des mises à jour.
Signalez via le formulaire, avec vos coordonnées ou anonymement, ou par e-mail. La recherche de bonne foi conforme à la politique est autorisée et ne donnera lieu à aucune action contre vous.
Étape
Délai
Nous accusons réception
Sous 3 jours ouvrés
Première analyse et sa gravité
Sous 10 jours ouvrés
Points tant que c’est ouvert
Au plus 14 jours d’écart
Correctif, gravité critique/haute
Objectif : 30 jours
Correctif, gravité basse
Objectif : 90 jours
Des objectifs, pas des garanties. Nous demandons 90 jours avant divulgation publique. Pas de prime en argent ; chercheurs cités par leur nom sur demande.
Pas de récompense en argent. Chercheurs cités sur demande.
09
Politiques
Textes juridiques
Chaque document qui régit le service, avec la date de sa version actuelle. Tout changement important des CGU, de la politique de confidentialité, du DPA et de l’AUP est annoncé aux titulaires au moins 30 jours avant.
Points de contact pour les autorités et les utilisateurs de l’UE, notre représentant légal dans l’UE, signalements de contenus illicites et exposés des motifs.
Comment le règlement européen sur l’IA s’applique à Intramedial et à ses packs de preuves, tel que le document l’énonce. Les packs associent des contrôles et ne certifient jamais.
Vous menez une revue fournisseur ? Dites-nous ce qu’il vous faut. Nous répondons aux questionnaires par écrit et disons clairement lorsqu’une information n’est pas encore publiée.