### Six vérifications séquentielles (s'arrête au premier échec)

| # | Vérification | Bloc si |
|---|--------------|---------|
| 1 | Signature du reçu | Signature ECDSA P-256 invalide ou reçu falsifié |
| 2 | Révocation | Le reçu a été révoqué via `RevocationRegistry` |
| 3 | Fenêtre temporelle | Reçu expiré ou pas encore valide (oracle temporel du journal, pas l'horloge client) |
| 4 | Portée | Action non dans `ScopeSchema.allowedActions` ou échoue à la correspondance textuelle de portée |
| 5 | Instructions de l'opérateur | Les instructions actuelles ne correspondent pas au hachage verrouillé dans le reçu lors de l'émission |
| 6 | Hash du programme | Le `programHash` fourni ne correspond pas au hachage `executes` engagé (prévention de substitution de code) |

Chaque résultat de vérification — réussi ou échoué — est automatiquement enregistré dans un `ActionLog` immuable signé avec la propre clé du vérificateur.

### Intégrations middleware

Wrappers prêts à l'emploi pour les frameworks courants. Chaque wrapper protège chaque appel via `PreExecutionVerifier` avant que le code encapsulé ne s'exécute.

- **[LangChain](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/langchain.js)** — encapsule tout agent avec une méthode `invoke()`
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/express.js)** — middleware de requête pour tout framework compatible Express
- **[Wrapper de fonction générique](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/generic.js)** — encapsule toute fonction asynchrone```js
// LangChain
import { authproofMiddleware } from 'authproof-sdk/middleware/langchain'
const guardedAgent = authproofMiddleware(agent, { receiptHash, verifier })

// Express
import { authproofMiddleware } from 'authproof-sdk/middleware/express'
app.use(authproofMiddleware({ verifier, getReceiptHash: (req) => req.headers['x-receipt-hash'] }))

// Any function
import { guardFunction } from 'authproof-sdk/middleware/generic'
const guardedExecute = guardFunction(executeAction, { receiptHash, verifier, action })

L'utilisateur donne des instructions à l'opérateur. L'opérateur donne des instructions à l'agent. Mais aucun enregistrement cryptographique de l'intention originale de l'utilisateur n'existe au moment de la délégation. L'opérateur devient un tiers de confiance doté d'une autorité sans contrôle pour étendre, déformer ou omettre les instructions de l'utilisateur avant qu'elles n'atteignent l'agent.

Les conséquences :

- Les utilisateurs ne peuvent pas prouver ce qu'ils ont autorisé.
- Les régulateurs n'ont pas de piste d'audit.
- Les tribunaux n'ont pas de chaîne de preuves.
- Les agents ne peuvent pas distinguer les instructions légitimes de l'opérateur de celles compromises ou malveillantes.

AuthProof comble cette lacune.

---

## La primitive fondamentale : Reçu de Délégation

Un **Reçu de Délégation** est un Objet d'Autorisation signé ancré dans un journal décentralisé à ajout seul avant que toute action d'agent ne commence. Il contient quatre champs obligatoires :

### Périmètre

Une liste d'autorisation explicite des opérations permises. Tout ce qui n'est pas listé est refusé par défaut. Exprimé en format structuré — pas en langage naturel. Classes d'opérations :

| Classe | Description |
|---|---|
| `reads` | Accès en lecture aux ressources spécifiées |
| `writes` | Accès en écriture aux ressources spécifiées |
| `deletes` | Suppression des ressources spécifiées |
| `executes` | Exécution d'un programme spécifique, référencé par son **hash de signature de capacité statique** |

`executes` est la classe la plus dangereuse. Elle doit référencer le hash cryptographique du DAG de capacité statique d'un programme Safescript — pas un nom, URI ou description. Pas de correspondance de hash signifie pas d'exécution.

### Limites

Interdictions explicites qui ne peuvent être outrepassées par les instructions de l'opérateur en aucune circonstance. Limites strictes définies par l'utilisateur qui survivent à toute instruction ultérieure de l'opérateur.

### Fenêtre Temporelle

Période de validité de l'autorisation. L'**horodatage du journal** est l'oracle temporel — pas l'horloge du client. Les horloges des clients sont explicitement exclues de la validation temporelle.

### Hash des Instructions de l'Opérateur

Un hash cryptographique des instructions déclarées par l'opérateur au moment de la délégation. Si l'opérateur donne par la suite des instructions différentes à l'agent, l'écart est détectable à partir du journal sans aucune hypothèse de confiance supplémentaire.

L'utilisateur signe cet objet avec sa clé privée via **WebAuthn/FIDO2 en utilisant l'enclave sécurisée de l'appareil**. La signature est publiée dans le journal avant toute action de l'agent. Chaque action ultérieure de l'agent référence le hash du reçu. Les actions en dehors du périmètre sont cryptographiquement invalides.

---

## Architecture de la Pile de Confiance

Trois couches de protocole éliminent trois tiers de confiance :

### Couche 1 — Manifeste de Capacité Signé *(supprime la confiance dans le registre)*

Dans l'écosystème MCP actuel, il n'existe pas d'attestation cryptographique que les descriptions d'un serveur d'outils correspondent à ce qu'il fait réellement. Un opérateur peut présenter un schéma arbitraire.

La solution : les serveurs d'outils publient un **manifeste de capacité signé cryptographiquement** avant que toute autorisation utilisateur n'ait lieu. Le champ `scope` du Reçu de Délégation référence le **hash de ce manifeste** — pas le schéma auto-déclaré par l'opérateur. La divergence entre le comportement du serveur et le manifeste est détectable au niveau du journal.

### Couche 2 — Reçu de Délégation *(supprime la confiance dans l'opérateur)*

L'intention originale de l'utilisateur est enregistrée de manière immuable avant que les instructions de l'opérateur n'atteignent l'agent. La déviation de l'opérateur est prouvable.

### Couche 3 — Exécution Safescript *(supprime la confiance dans le code)*

[Safescript](https://github.com/safescript) est un langage sandboxé open-source pour l'exécution d'agents IA. Sa structure DAG statique signifie que la signature de capacité complète de chaque programme est calculable avant son exécution — pas de dispatch dynamique, pas d'expansion de capacité à l'exécution.

La classe de périmètre `executes` référence un hash de signature de capacité Safescript spécifique. Si le programme fourni par l'opérateur ne correspond pas au hash engagé, l'exécution est bloquée. L'agent ne peut pas être substitué par un programme différent après la délégation.

---

## Démarrage Rapide```js
import { AuthProof, Scope, KeyCustody } from 'authproof-sdk';

// Initialize with hardware-backed key custody (recommended)
const authproof = new AuthProof({
  custody: KeyCustody.HARDWARE, // WebAuthn/FIDO2 via device secure enclave
  log: 'https://log.authproof.dev',
});

// Define permitted operations — explicit allowlist, deny-by-default
const scope = new Scope()
  .allow('reads',  ['resource://calendar/events', 'resource://email/inbox'])
  .allow('writes', ['resource://calendar/events'])
  .deny('deletes', '*')
  .execute('sha256:a3f1c9d8...', { program: 'scheduler-v1.sg' }); // Safescript hash

// Hard limits that survive any operator instruction
const boundaries = {
  never: ['external-network', 'credential-store', 'payment-methods'],
};

// Issue the Delegation Receipt — anchored to log before any agent action
const receipt = await authproof.delegate({
  scope,
  boundaries,
  window: { duration: '8h' },           // validated against log timestamp
  operatorInstructions: instructionText, // hashed and committed
});

// receipt.id    — unique receipt identifier
// receipt.hash  — reference in every agent action
// receipt.log   — append-only log anchor

// Agent-side: validate an action against the receipt
const check = await authproof.validate({
  receiptHash: receipt.hash,
  action: { class: 'writes', resource: 'resource://calendar/events' },
});

if (!check.authorized) {
  // Out-of-scope action: surface a micro-receipt request to the user
  const microReceipt = await authproof.requestMicroReceipt({
    action: check.requestedAction,
    parent: receipt.hash,
  });
}

### API du journal d'actions

| Méthode | Description |
|---|---|
| `new ActionLog()` | Crée une nouvelle instance de journal. L'état est en mémoire. |
| `log.init({ privateKey, publicJwk })` | Initialise avec la clé ECDSA P-256 de l'agent. Requis avant `record()`. |
| `log.registerReceipt(receiptHash, receipt)` | Enregistre un reçu pour la comparaison de portée. Requis avant `diff()`. |
| `log.record(receiptHash, action)` | Ajoute une entrée signée et chaînée. Renvoie l'entrée scellée. |
| `log.verify(entryId)` | Vérifie la signature et la position dans la chaîne d'une entrée. Renvoie `{ valid, reason }`. |
| `log.getEntries(receiptHash)` | Toutes les entrées d'un reçu dans l'ordre chronologique. |
| `log.diff(receiptHash)` | Compare toutes les entrées avec la portée du reçu. Renvoie `{ compliant, violations, clean }`. |

### Avertissement pour la production

Les horodatages dans la v1 utilisent l'horloge du client. Pour les contextes de conformité ou juridiques où les horodatages doivent être vérifiables indépendamment, remplacez-les par une autorité d'horodatage de confiance RFC 3161 avant le déploiement en production.

### Important

Définissez toujours la portée à l'aide de tableaux `allowedActions` explicites. La correspondance de portée textuelle est disponible uniquement pour le développement et ne convient pas à la production ou aux contextes de conformité.

---

## Déploiement confidentiel

Exécutez les agents AuthProof dans des environnements d'exécution de confiance (TEE) attestés par le matériel. La classe `ConfidentialRuntime` lie les reçus de délégation aux mesures de l'enclave, de sorte que toute substitution des poids du modèle, du code du vérificateur ou de la plateforme est détectable avant l'exécution.

### Configuration matérielle requise

- **Intel TDX** — Intel Ice Lake Xeon ou plus récent (4e génération Xeon Scalable). Azure DCdsv3-series, GCP C3 Confidential VMs.
- **AMD SEV-SNP** — AMD EPYC 3e génération (Milan) ou plus récent. Azure DCasv5-series, AWS m6a avec Nitro Enclaves.

### Créer un reçu avec liaison de mesure TEE```javascript
import { AuthProofClient } from 'authproof-sdk';

const client = new AuthProofClient();
const { receipt } = await client.delegate({
  scope: 'Summarize calendar events',
  operatorInstructions: 'Stay within scope.',
  expiresIn: '2h',
  privateKey,
  publicJwk,
  teeConfig: {
    platform:     'intel-tdx',
    verifierHash: verifierCodeHash,   // SHA-256 of your verifier binary
    modelHash:    modelWeightsHash,   // SHA-256 of model weights
  },
});
// receipt.teeMeasurement.expectedMrenclave is now bound to the receipt

Exigences de SKU Azure : `Standard_DC4ds_v3` ou supérieur de la série DCdsv3. Activez le chiffrement confidentiel du disque du système d'exploitation. Utilisez le point de terminaison partagé Microsoft Azure Attestation (MAA) pour la vérification des devis.

### Déployer sur les enclaves AWS Nitro```javascript
const config = ConfidentialRuntime.awsNitroConfig({
  receiptHash,
  verifierHash,
  modelHash,
  region: 'us-east-1',
});
// config.instanceType === 'c6a.xlarge'
// config.enclaveOptions.enabled === true
// config.pcr0 is the combined receipt+verifier+model measurement

Apply with `kubectl apply -f` after serializing to YAML. The node selector `intel.feature.node.kubernetes.io/tdx: "true"` requires the Intel Device Plugin for Kubernetes.

### Module noyau eBPF — aide recherchée

La couche d'application TEE est complète côté espace utilisateur (`ConfidentialRuntime`, `TokenPreparer`). La dernière étape d'application — valider le jeton de capacité signé sur chaque appel système via un hook eBPF LSM — nécessite un module noyau ouvert aux contributions.

Les ingénieurs ayant une expérience en eBPF LSM (Isovalent, Red Canary, ou similaire) sont particulièrement les bienvenus. Ouvrez un issue ou une PR sur https://github.com/Commonguy25/authproof-sdk/issues

---

## Exemples

Deux exemples exécutables se trouvent dans le répertoire `examples/`.

**[`examples/langchain-example.js`](https://github.com/commonguy25/authproof-sdk/blob/main/examples/langchain-example.js)** — Montre le chemin complet d'intégration LangChain : générer une paire de clés, émettre un reçu de délégation, initialiser `PreExecutionVerifier`, et envelopper n'importe quel agent avec `authproofMiddleware` afin que chaque appel `invoke()` soit contrôlé avant que le runtime de l'agent prenne la main. Inclut un agent simulé que vous pouvez exécuter immédiatement et le modèle de code exact pour un vrai `AgentExecutor`. Exécutez avec `npm run example:langchain`.

**[`examples/webauthn-example.html`](https://github.com/commonguy25/authproof-sdk/blob/main/examples/webauthn-example.html)** — Une démo navigateur autonome en trois cartes du flux complet de délégation. La carte 1 vous permet de définir la portée, les limites et les instructions de l'opérateur, puis signe un reçu avec une clé locale (remplacez par `navigator.credentials` pour un vrai WebAuthn). La carte 2 affiche l'ID du reçu, la date d'expiration, le prompt système et le JSON brut. La carte 3 vous permet de taper n'importe quelle action proposée et de la vérifier par rapport au reçu en temps réel, affichant chaque résultat de vérification. Ouvrir directement dans un navigateur — aucune étape de build nécessaire.

---

## Installation```bash
npm install authproof-sdk