Loading…
Open source · Apache-2.0 · indépendant du modèle
Sachez ce que votre agent IA a fait — et stoppez les actions risquées avant qu'elles ne surviennent.
Nous ne vous disons pas ce qui s'est passé ; nous vous montrons ce que les preuves établissent.
Chaque action qui transite par Noa donne lieu à un reçu signé dont toute altération est détectable — une preuve que vous vérifiez vous-même, hors ligne, sans compte Noa. Installez le proxy MCP ou le SDK core depuis npm dès aujourd'hui ; suspendre les actions risquées pour votre validation est disponible dès maintenant dans le proxy MCP. Indépendant du modèle — fonctionne dès aujourd'hui avec tout hôte MCP ou application Node.
sûr → auto-autorisé risqué → votre approbation interdit → bloqué
reçu émis · action de l'agent scellée
Le moment d'approbation que Noa permet — disponible dès aujourd'hui dans le proxy MCP. L'application mobile à un geste est en cours d'examen sur l'App Store.
Soumis à l'App Store et à Google Play le 2026-08-11 — en attente de validation des boutiques
En clair
Les assistants IA que vous utilisez déjà commencent à agir au lieu de seulement répondre.
Noa est le frein de sécurité qui empêche votre IA d'envoyer de l'argent par erreur, de supprimer les mauvais fichiers ou de faire quelque chose d'important sans vérification.
Voyez cela comme la seconde validation avant un gros virement bancaire — mais pour les agents IA.
En bref
Quatre questions, quatre réponses claires.
Qu'est-ce que c'est ?
Une couche de sécurité entre votre assistant IA et le monde réel. Avant qu'il ne fasse quelque chose qui compte vraiment, Noa le vérifie d'abord.
Comment ça marche ?
Les actions sûres passent directement. Les actions risquées s'interrompent pour votre approbation. Les interdites sont bloquées. Chaque action qui transite par Noa laisse un reçu dont toute altération est détectable, que vous pouvez vérifier vous-même.
Pourquoi en avez-vous besoin ?
L'IA commet des erreurs, et les assistants IA commencent à faire des choses réelles — payer, envoyer des e-mails, supprimer, modifier des systèmes en production. Une fois qu'une mauvaise action s'exécute, c'est fait. Noa l'arrête avant qu'elle ne s'exécute.
Ce que vous obtenez
La confiance nécessaire pour enfin laisser l'IA faire un vrai travail. Un reçu vérifiable, dont toute altération est détectable, pour chaque action. C'est vous qui décidez de ce qui nécessite votre approbation. Compatible dès aujourd'hui avec vos agents — proxy MCP ou SDK Node. Open source — lisez et vérifiez tout.
Le problème
Les agents IA commencent à agir — payer, rembourser, envoyer des e-mails, supprimer, déployer. Et l'IA commet des erreurs.
Une fois qu'une mauvaise action s'exécute, c'est fait. C'est pourquoi les équipes maintiennent leurs agents en lecture seule — trop effrayées pour leur donner un vrai pouvoir.
Après coup
Les journaux vous disent ce qui s'est passé.
Le temps que ce soit dans le journal, le paiement est envoyé et les lignes sont supprimées. Un rétroviseur ne peut pas empêcher l'accident.
Avant l'exécution
Noa décide de ce qui doit se produire — avant l'exécution.
L'action risquée attend une vérification ou une approbation. L'hallucination n'atteint jamais l'étape irréversible.
Comment ça marche
Trois étapes, de l'intention de l'agent à un reçu que vous pouvez vérifier.
- 01
L'agent propose une action
Votre agent appelle un outil — rembourser un paiement, envoyer un e-mail, supprimer une table. Une fois intégré, Noa intercepte la requête avant son exécution.
agent → propose( payment.refund ) - 02
Noa la contrôle
Les actions sûres sont auto-autorisées en moins d'une milliseconde. Les risquées nécessitent une approbation humaine. Les interdites sont bloquées d'emblée — par la politique que vous avez écrite.
auto-autoriser les sûresapprouver les risquéesbloquer les interdites - 03
Un reçu dont toute altération est détectable est émis
Chaque verdict est scellé dans un reçu chaîné par hachage — qui, quoi, quelle règle, ce qui s'est passé. Pour les actions réversibles, une intégration peut associer un chemin de retour en arrière vérifié — et Noa délivre un reçu de ce retour en arrière lorsqu'il survient.
receipt rcpt_… · hash sha256:… · prevHash ↩
Chaque reçu est lié au précédent. Modifiez n'importe quel reçu passé et la chaîne se rompt au hachage suivant.
La démo
Un agent en pleine hallucination tente de rembourser 1 000 000 $.
Noa ne fait pas que bloquer — pour un appel risqué, il peut s'interrompre pour votre approbation, puis exécuter et sceller un reçu. Encapsulez un outil avec le SDK core, disponible sur npm dès aujourd'hui ; la pause d'approbation ci-dessous est disponible dès aujourd'hui dans mcp-proxy 0.3.2.
agent.tsdisponible sur npm
Encapsulez n'importe quel outil avec le preCheck de noa-mcp-adapter-core — indépendant du modèle — et Noa contrôle chaque appel : auto-autorisation des sûres, blocage des interdites, avant l'exécution. L'étape de pause pour approbation dans la chronologie à droite est disponible dès aujourd'hui dans mcp-proxy 0.3.2.
Le SDK core (noa-mcp-adapter-core) et le proxy MCP (noa-mcp-proxy) sont disponibles sur npm dès aujourd'hui — la pause pour approbation dans la chronologie est disponible dès aujourd'hui dans mcp-proxy 0.3.2. Vérifiez un reçu vous-même, dès aujourd'hui : npx noa-receipt verify (à droite).
noa · disponible
approuvé + exécuté + reçu émis
noa · action interdite
bloqué — jamais exécuté
vérifiez-le vous-même
$ npx noa-receipt verify receipt.json --keyring keys.json
✓ altération détectable · chaîne intacte · 3/3 reçus valides
Inspectez aussi l’artefact de paquet publié : npm pack noa-receipt@0.8.0 → node dist/src/cli.js verify …
Hors ligne. Sans compte Noa. Le vérificateur recalcule chaque hachage et contrôle chaque prevHash lien — si quelqu'un a modifié un reçu passé, la vérification échoue exactement à cette séquence.
Ou vérifiez une chaîne dès maintenant, dans votre navigateurPourquoi l'open source
Une couche de confiance que vous devez croire aveuglément n'est pas une couche de confiance.
Les règles de politique et le format de reçu de Noa — l'organe de gouvernance/reçu — sont open source (Apache-2.0). Vous lisez les règles. Vous vérifiez les reçus. Hors ligne. Aucun compte Noa requis.
$npx noa-receipt verify receipt.json --keyring keys.json→ ✓ altération détectable
Le nom
Pourquoi Copenhague ?
Copenhague, c'est le nom que nous donnons à une seule règle, et cette règle est une restriction : un vérificateur n'affirme jamais ce qui s'est passé. Il affirme ce que les preuves fournies étayent — et consigne ce qu'il n'affirme pas. Tout ce dont le code ne se porte pas garant est écrit noir sur blanc, plutôt que laissé à vos suppositions.
Vous pouvez voir la règle à l'œuvre. Vérifiez une chaîne de reçus sans trousseau de clés et la réponse n'est pas une validation : le statut revient UNVERIFIED, et le résultat nomme ce qui n'a pas été contrôlé — les signatures n'ont jamais été authentifiées et, sans point de contrôle fourni, la suppression des reçus les plus récents ne peut pas être détectée hors ligne. Une validation se mérite ; les lacunes, elles, s'affichent dans tous les cas.
$npx noa-receipt verify receipts.json→ UNVERIFIED · signatures non authentifiées (sans trousseau)
Le nom fait écho à l'interprétation de Copenhague en physique, et à la phrase qui l'accompagne : la physique ne porte pas sur ce qu'est la nature, mais sur ce que nous pouvons dire de la nature. Cette phrase est attribuée à Niels Bohr, via Aage Petersen, 1963 — elle ne figure pas dans les écrits de Bohr lui-même, et nous le disons plutôt que de la signer de son nom. Une discipline qui consiste à n'affirmer que ce que l'on peut étayer doit commencer par ses propres sources.
Pour les sceptiques
Surcharge
Une vérification de politique sur le chemin sûr est une comparaison en mémoire, sans aller-retour réseau. Les actions que la porte auto-autorise passent directement ; seules celles que votre politique, ou une règle des deux personnes, retient pour approbation s'interrompent.
Mode d'échec
Fermeture sécurisée par défaut (configurable). Si Noa ne peut pas décider, l'action risquée attend — elle ne passe pas au travers.
Ce que stockent les reçus
Les paramètres bruts ne sont jamais stockés dans un reçu — seulement leurs hachages — et l'approbateur apparaît comme un id opaque, pas comme un nom. Aucune donnée brute, information client ou secret.
FAQ
Des réponses franches, y compris celles qui dérangent.
Cela dépend de votre politique, pas de Noa. Une vérification de politique sur le chemin sûr est une comparaison en mémoire, sans aller-retour réseau, de sorte que la vérification elle-même ne retarde pas une action que la porte auto-autorise. Les appels qui attendent sont ceux retenus pour approbation — ceux que votre politique marque comme risqués, plus ceux qu'exigent vos règles des deux personnes. La console hébergée fait davantage autour de cette vérification (elle lit votre organisation, votre politique et vos règles), ce n'est donc pas une promesse sur la latence de bout en bout ; c'est une affirmation sur ce que la vérification du chemin sûr fait et ne fait pas.
Pour les développeurs
Quatre points d'entrée. Choisissez celui qui convient à votre stack.
La CLI de vérification, le proxy MCP et le SDK core de contrôle d'outils sont tous disponibles sur npm dès aujourd'hui. La validation humaine à l'exécution — suspendre une action risquée pour votre approbation — est disponible dès aujourd'hui sur npm (mcp-proxy 0.3.2 --approval-rules).
Proxy MCPzéro code · disponible sur npm
Placez le proxy devant n'importe quel hôte MCP — chaque appel d'outil est gouverné dès aujourd'hui : auto-autorisation des sûres, blocage des interdites, sans réécriture.
$ npx noa-mcp-proxy -- node your-server.mjs
→ every tools/call gated: ALLOW → forwarded + receipted
DENY → blocked + receiptedpreCheckSession()un seul appel de fonction · disponible sur npm
Contrôlez un seul appel d'outil dans CrewAI, LangChain ou votre propre exécuteur — un seul appel de fonction, n'importe quel framework.
$ npm install noa-mcp-adapter-core
const { decision, receipt } = preCheckSession(toolCall, opts);
if (decision === 'ALLOW') await run(toolCall);
// receipt is signed + hash-chained either wayNoa Receiptspécification ouverte
Un petit format JSON chaîné par hachage qui stocke des hachages de paramètres, jamais de valeurs brutes. JSON-Schema + suite de conformité.
{
"spec": "noa.receipt/0.1",
"governance": { "verdict": "EXECUTED" },
"chain": { "seq": 42, "hash": "sha256:…" }
}npx noa-receipt verifyvérification · disponible sur npm
Recalculez chaque hachage, vérifiez chaque lien prevHash. Hors ligne, sans service.
$ npx noa-receipt verify receipts.json --keyring keys.json
→ ✓ VALID · signatures + chain intact
(or) ✗ TAMPERED at seq=37Donnez à vos agents un vrai pouvoir — en toute sécurité.
Noa est open source et disponible dès maintenant — pas de liste d'attente, pas d'inscription. Installez les paquets, exécutez-les dans votre propre environnement et vérifiez chaque reçu vous-même, hors ligne. Un service de porte hébergé que nous exploitons pour vous est prévu dans notre feuille de route.
$npm install noa-receipt
Soumis à l'App Store et à Google Play le 2026-08-11 — en attente de validation des boutiques
Pas de liste d'attente pour le cœur open source : il est utilisable dès aujourd'hui depuis npm ou les sources. La console d'entreprise hébergée est en production en bêta ; l'inscription en libre-service est en préparation, et l'accès est aujourd'hui accordé sur demande. Un relais hébergé et un service de porte que nous exploitons pour vous restent dans notre feuille de route.