la partie qu'ils sautent
Le problème que personne ne veut prendre en charge
Les frameworks vous aident à construire un agent. Ce qu'ils n'aident pas à faire, c'est la partie qui compte dès qu'il touche le monde réel : le faire tourner pour d'autres personnes, dépenser leur argent, toucher à leurs données, prendre des actions lourdes de conséquences, sans fuite de données entre clients et sans commettre d'erreur irréversible.
les quatre fronts
Tenants
L'agent d'un client ne peut pas atteindre les données d'un autre, même via un outil partagé.
Autonomie
Laisser un agent agir, pas seulement discuter, y compris un agent qui agit de sa propre initiative, avec un moyen de l'empêcher de faire quelque chose de catastrophique.
Gouvernance
Chaque action lourde de conséquences passe par une barrière d'autorisation. L'argent et les réservations attendent toujours une personne ; tout le reste ne s'exécute que si la politique fixe de l'assistant l'autorise, et sinon attend.
Économie
Les dépenses de chaque tenant sont plafonnées, et de la valeur peut circuler entre tenants de façon atomique : le compteur est un régulateur et une couche de règlement, pas seulement une facture.
de un à six
Les problèmes difficiles qu'il résout
01 Une isolation qui résiste à la composition
Un outil appartenant au tenant A, appelé par le tenant B, s'exécute sous le périmètre de B, jamais celui de A. Prouvé : A ne peut pas lire B, même via un outil dont A n'est pas propriétaire.
02 Des actions à conséquences, en toute sécurité
Enveloppes de capacités, une file d'approbation (autoriser puis agir), un kill switch, un lancement progressif qui ne passe à l'autonomie qu'une fois la confiance établie, et un protocole de crise, branchés à chaque point d'entrée.
03 Composer sans mélanger les niveaux de confiance
Interne = registre en processus (rapide, limité au tenant). Externe = MCP, dans les deux sens, via un transport protégé contre le SSRF. MCP n'est jamais le bus interne.
04 Un résultat dont le fonctionnement est prouvé
Un contrôle qualité : générer → vérifier → réparer → livrer. Le modèle propose ; le backend impose le schéma.
05 Plateforme, pas produit
Une nouvelle verticale consiste à composer ce qui existe déjà, pas à le reconstruire. Des résidents sans rapport entre eux reposent sur une même colonne vertébrale, et le lint de pureté le prouve à chaque commit.
06 L'économie comme primitive de sécurité
Les crédits sont décrémentés de façon atomique ; un tour redirigé vers des ressources de crise est remboursé. On ne facture pas quelqu'un en détresse. La même primitive transfère de la valeur entre tenants : un appel inter-tenants payant débite l'appelant et paie le fournisseur en une seule étape atomique, à l'épreuve du découvert.
Ce qui se passe quand vous envoyez un message.
Chaque réponse dans le carnet de la page d'accueil affiche les vérifications qu'elle a passées. Chacune est une garantie, et chacune échoue en mode sûr.
SET LOCAL app.current_tenant lie RLS pour le tourpas de contexte tenant ⇒ zéro ligneDes propriétés de sécurité que vous pouvez lire, pas des politiques auxquelles vous devez faire confiance, UPDATE … SET credits = credits - :n WHERE credits >= :n, un book_if_free protégé par verrou consultatif. Regardez-en deux tenir, en direct →
parlons-en
Personne ne veut prendre ce problème en charge. Moi, si.
Si l'isolation des tenants, la gouvernance et la mesure de consommation sont ce qui sépare vos agents de la production, cette partie est déjà construite. Parlons-en.
Demandez ce qui tourne mal quand une IA peut agir, et ce que PANTHEON fait pour y remédier.
- Qu'est-ce qui tourne mal quand une IA peut agir ?
- Qu'est-ce qui l'empêche de divulguer des données ?
- Qu'est-ce qui nécessite encore une personne ?