Sûre, sécurisée et privée.

L’isolation entre locataires est appliquée par une séparation physique des processus, et non par de simples indicateurs logiciels. Chaque session d’agent s’exécute à l’intérieur d’un conteneur Cloudflare Sandbox éphémère, provisionné par locataire et par dossier. L’exécution d’outils non fiables, l’évaluation de code Python et l’analyse de fichiers se déroulent entièrement à l’intérieur de ces environnements d’exécution à confiance zéro, via des contrats HTTP en TLS mutuel. Les blocs-notes d’agents, les assemblages de contexte dynamique et les répertoires de travail sont effacés à la fermeture du conteneur. Au repos, la persistance est partitionnée logiquement et cryptographiquement via Postgres sur Neon, avec application de la sécurité au niveau des lignes (RLS) et des clés de chiffrement KMS propres à chaque locataire. Aucun agent ne dispose d’une mémoire ambiante, inter-locataires ou globale au cabinet.

Les modèles de raisonnement et les boucles d’agents autonomes ne reçoivent, n’inspectent ni ne détiennent jamais de jetons API de production, de secrets d’actualisation OAuth ou d’identifiants bancaires. Tous les secrets tiers pour les registres en amont, comme QuickBooks Online, et les rails bancaires sont isolés dans des passerelles d’action dédiées et sécurisées au niveau matériel. Les agents résolvent les tâches du domaine en émettant des enveloppes de commande strictement typées et validées par schéma, par exemple PostJournalBatch ou PrepareFilingReceipt. La passerelle d’action authentifie l’origine de l’appelant, valide l’intégrité du schéma et signe les transactions API sortantes à l’aide d’identifiants à courte durée de vie. L’agent décide du résultat opérationnel visé ; la passerelle détermine si ce résultat est autorisé à s’exécuter.

Nimble & Cross exploite une topologie de supervision à double agent asynchrone. Les agents opérationnels n’ont structurellement pas le droit d’évaluer ou d’approuver leurs propres limites d’exécution. Chaque enveloppe de commande générée par un agent de travail doit passer par un Sentinel Gatekeeper indépendant avant exécution. Le Sentinel analyse le trafic entrant et sortant selon des règles déterministes : limites de transaction, listes de contreparties autorisées, bornes d’anomalie et paramètres de correspondance du plan comptable. Toute action à haut risque, irréversible ou hors politique, comme une écriture sur un compte non cartographié, la transmission d’une déclaration fiscale ou un décaissement, déclenche immédiatement une mise en attente d’exécution. Le flux Restate sous-jacent se met en pause, et un écart structuré est acheminé vers du personnel humain autorisé pour approbation explicite. Un modèle non déterministe ne peut ni s’accorder d’autorité ni contourner les contrôles du Sentinel.

La minimisation des données est un protocole structurel appliqué au périmètre de la passerelle. Lorsqu’une opération exige un transit externe, comme la transmission de factures, un appel à des partenaires bancaires ou le dépôt de déclarations réglementaires, le proxy sortant retire tout contexte superflu. Les charges utiles sortantes ne contiennent que les champs strictement exigés par le schéma de destination. Le graphe opérationnel du dossier, l’historique du registre inter-entités, les transcriptions de conversations internes et les identifiants de clients adjacents demeurent confinés à notre noyau chiffré. Les fournisseurs en aval reçoivent des données transactionnelles sans accès au contexte client plus large.

La vérification opérationnelle est continue et rétrospective. Pendant les fenêtres de maintenance planifiées et les cycles d’exécution inactifs, des démons de surveillance automatisés exécutent des passes de rapprochement en arrière-plan sur tous les comptes clients actifs. Ces boucles réflexives vérifient les actions passées des agents par rapport aux preuves sources, valident les équilibres mathématiques entre sous-registres et détectent les dérives de configuration ou les incohérences de correspondance. Lorsqu’une incohérence est détectée, le démon signale le lot, met en quarantaine la tranche du registre concernée et alerte les contrôleurs internes. Les corrections sont appliquées exclusivement par des écritures de journal correctrices, garantissant que les registres d’audit historiques demeurent immuables.

Les modèles de langage traitent l’interprétation non structurée, mais les registres financiers faisant autorité sont gouvernés par des machines à états déterministes en base de données. Le grand livre central de Nimble & Cross s’exécute sur Postgres sur Neon, coordonné par les moteurs d’exécution durable de Restate. Le registre applique les règles de la partie double au niveau du moteur de base de données via des déclencheurs de contrainte stricts : chaque lot d’écritures doit s’équilibrer à zéro dans la devise de référence sur l’ensemble des débits et crédits avant validation, les lignes et lots d’écritures comptabilisés deviennent immuables et en ajout seul et rejettent toute mise à jour ou suppression SQL, et les périodes comptables closes appliquent des déclencheurs de verrouillage de période explicites qui bloquent les écritures rétroactives. Si un agent émet une proposition de lot déséquilibrée ou mal formée, la transaction Postgres est annulée automatiquement. Un modèle génératif ne peut pas outrepasser ces contraintes de base de données.

Les données client ne sont jamais utilisées pour entraîner, évaluer ou ajuster des modèles de base publics ou propriétaires. Nous fonctionnons sous des accords stricts de rétention zéro des données (ZDR) de niveau entreprise auprès de tous nos points d’inférence. Les invites, les charges utiles de documents et les fenêtres de contexte résident exclusivement en mémoire volatile pendant la durée de l’appel d’inférence et sont immédiatement effacées. Tous les actifs persistants, factures, reçus, dépôts d’entreprise et livrables générés, sont stockés de façon immuable dans un stockage d’objets adressé par contenu, vérifié par des empreintes cryptographiques SHA-256.