Sécurité et confiance
Admission sûre, auditable par conception
Le rôle du réseau est d'empêcher les agents d'appeler des éléments qu'ils ne devraient pas appeler. Cela ne fonctionne que si le réseau lui-même est tenu à une norme plus stricte.
Admission : non fiable par défaut
- Chaque capacité entre en tant que
discoveredet gagne son statut par la vérification — jamais par la popularité ni le paiement. - L'identité du fournisseur est vérifiée ; usurper l'identité d'un fournisseur connu entraîne un blocage permanent.
- Les manifestes doivent déclarer le risque par action (read_only / write / destructive). Sous-déclarer le risque constitue une barrière stricte, et non une pénalité.
- Les descriptions d'outils et de skills sont filtrées contre l'injection de prompt avant qu'un agent ne les voie.
Isolation de l'exécution
- Le code tiers ne s'exécute jamais dans le service API. Les installations et exécutions à blanc se déroulent dans des workers de bac à sable dédiés.
- Les bacs à sable s'exécutent sans secrets réels, sans montages en écriture, avec CPU/mémoire/temps bornés et le réseau désactivé par défaut.
- Les sondes et les canaris sont en lecture seule par conception : ils ne modifient jamais l'état, ne passent jamais de commande et ne dépensent jamais d'argent.
Politique des actions à haut risque
- Les actions destructrices ou transactionnelles ne sont jamais recommandées automatiquement, sauf si le niveau de preuve est E4 ou supérieur ET que l'action déclare requires_user_confirmation.
- Les actions à haut risque assorties de preuves plus faibles n'apparaissent, au plus, que comme des solutions de repli explicitement signalées.
- Une dérive de schéma sur un point de terminaison distant sans incrément de version retire la capacité de l'ensemble routable jusqu'à une nouvelle vérification.
Minimisation des données
- Nous ne collectons jamais de prompts, de fichiers utilisateur, de jetons, de cookies ni de variables d'environnement — qu'ils proviennent des agents ou des fournisseurs.
- Les rapports de résultats sont validés structurellement et rejetés s'ils sont signalés comme contenant du contenu utilisateur brut ou des données personnelles.
- Les journaux de requêtes occultent les en-têtes d'autorisation et les secrets par défaut.
- Les clés d'API sont stockées uniquement sous forme de hachages salés.
Responsabilité
- Chaque score comporte evidence_level, confidence, valid_until et reason_codes — auditables de bout en bout.
- Chaque conclusion remonte à ses sources : quel registre, quel dépôt, quelle sonde, quels résultats.
- Les capacités bloquées sont signalées avec leurs motifs, de sorte que le filtrage est inspectable plutôt que silencieux.
Il s'agit d'un service à un stade précoce. Nous ne revendiquons pas de certifications que nous ne détenons pas, et le Registry de démonstration contient des données d'exemple signalées comme telles. Pour les questions ou divulgations de sécurité : consultez la page de contact.