C->>A: Authenticated OpenAI-compatible or Anthropic request
A->>W: Size, canonicalization, WAF, session, rate-limit
W-->>C: Fail-closed response + durable error evidence when rejected
W->>U: Forward only after admission
U-->>A: Complete response or bounded SSE events
A->>L: Non-stream: hash, sign, append, flush, fsync
L-->>A: Non-stream durable evidence status
A->>Q: Optional bounded response analysis
A-->>C: Non-stream response + portable MMR proof headers
A-->>C: Stream events through bounded queue
A->>L: Stream terminal summary, sign, append, flush, fsync
L-->>A: Terminal commit complete
A-->>C: Protocol terminal marker

Le cycle de vie strict est le suivant :

1. Authentifier l'appelant et attribuer un identifiant de requête.
2. Appliquer les limites de taille de requête et canonicaliser la représentation de la requête.
3. Appliquer les contrôles WAF, de comportement de session, de sortie et de limitation de débit.
4. Rejeter en cas d'échec d'un contrôle obligatoire au lieu d'affaiblir silencieusement le chemin de sécurité.
5. Transférer au fournisseur en amont configuré.
6. Pour les appels non diffusés en continu, capturer la réponse, calculer les hachages canoniques, signer la preuve, l'ajouter au WAL, vider le tampon et exécuter `fsync` avant de la renvoyer.
7. Pour les appels SSE, relayer les événements logiques sanitizés via une file d'attente bornée avec comptabilité d'octets. Hacher de manière incrémentale les octets exacts émis ; à la terminaison, valider un résumé terminal signé avant d'émettre le marqueur terminal du protocole. L'en-tête de diffusion initial est donc `X-Aegis-Evidence-Status: pending-terminal`, et non `durable`.
8. Exécuter l'enrichissement facultatif de la réponse via un chemin de travail borné après l'existence de l'enregistrement faisant autorité.

## Contrat principal

| Contrôle | Comportement implémenté | Preuve et limite |
|---|---|---|
| Durabilité des preuves | Pour les appels gouvernés non diffusés en continu, le proxy principal valide les preuves de requête/réponse avant de renvoyer et émet `X-Aegis-Evidence-Status: durable`. Le SSE diffusé commence par `pending-terminal` ; un résumé terminal signé est validé avant le marqueur terminal du protocole, et la preuve est récupérée après la terminaison. | `tests/test_p0_release_gates.py`, `tests/test_proxy_streaming.py`, tests de chemins de défaillance du proxy et tests d'intégrité du WAL. Le système de fichiers cible et le fournisseur de stockage nécessitent encore une validation de déploiement. |
| Erreurs terminales durables | Les réponses non-2xx en amont, les chemins de circuit ouvert et les pannes réseau utilisent le chemin de preuve d'erreur durable lorsque la limite de preuve est disponible. | `tests/test_enterprise_durable_evidence.py` et preuves de la version v3.1.0. Une défaillance de stockage après admission est un incident opérationnel à échec fermé, et non une réponse réussie. |
| Intégrité de la chaîne | Les nœuds d'audit lient le prédécesseur, le hachage de requête, le hachage de réponse, la racine de Merkle, la signature et les métadonnées de schéma. | `aegis/core/crypto_audit.py` et `verify_integrity()`. La détection de falsification n'est pas équivalente à un stockage externe immuable. |
| Signature forte | Les registres stricts rejettent le repli éphémère Ed25519. HMAC-SHA256, PKCS#11 configuré ou la signature native configurée doivent satisfaire la politique sélectionnée ; l'ancienne interface HSM échoue désormais en mode fermé au lieu de dériver une clé logicielle. | Tests de signataire et portes de démarrage strictes. Les tests PKCS#11 simulés ne sont que des preuves d'adaptateur, HMAC est symétrique, et aucune interopérabilité HSM, non-exportabilité de clé, validation FIPS ou non-répudiation tierce n'est établie. |
| Rotation des clés | Le signataire d'entreprise prend en charge un trousseau de clés HMAC versionné et atomique avec une clé active, des clés de vérification historiques, une expiration explicite et des métadonnées `key_id` non secrètes. | `aegis_server/crypto/keyring.py`, `tests/test_keyring_rotation.py`. Une preuve de déploiement à trois réplicas reste requise pour une revendication de production. |
| Limitation de débit | La limitation distribuée basée sur Redis échoue en mode fermé lorsque le backend est indisponible ; la limitation en mémoire de développement n'est pas un substitut de production. | Tests de limitation de débit et configuration de déploiement. Le comportement Redis/TLS/HA dépend du déploiement. |
| Identité d'entreprise et liaison de locataire | Le candidat non publié dérive des principaux immuables à partir de mappages de clés API configurés, de revendications OIDC strictes ou de certificats mTLS explicitement épinglés. Les en-têtes de locataire/session ne sélectionnent pas le locataire de preuve ou la clé de quota. | `aegis/auth/`, `aegis/proxy/dependencies.py` et tests d'intégration d'authentification. L'IdP, le terminateur TLS, le cycle de vie des certificats et l'acceptation Redis restent dépendants du déploiement ; la source mTLS actuelle est en mode d'épingle de feuille, et non une validation PKI universelle. |
| Archivage des segments finalisés | Les segments WAL JSONL rotatés reçoivent des manifestes versionnés et peuvent être téléchargés via l'adaptateur facultatif S3 Object Lock avec vérification SHA-256, version, mode de verrouillage et rétention. L'acceptation facultative RFC 3161 nécessite une vérification OpenSSL contre un fichier CA explicite. | `aegis/storage/`, `aegis/anchoring/` et tests ciblés. Cela ne constitue pas un WORM réglementaire, une garantie d'admissibilité légale ou de temps externe sans acceptation cible. |
| Télémétrie respectueuse de la vie privée | Les événements de sécurité à schéma fermé omettent le texte des invites/réponses/jetons, les embeddings, les identifiants bruts de locataire/session, les noms de signataires et les chaînes d'exception ; un spool SQLite borné facultatif exporte vers les encodages SIEM pris en charge. | `aegis/telemetry/` et tests sentinelles de confidentialité. La livraison en aval, la rétention, le contrôle d'accès et les SLO opérationnels sont externes. |
| Rapport de capacités | `aegis.crypto` expose un inventaire lisible par machine qui distingue les états implémenté, runtime facultatif, stub et validation externe requise. | `aegis/crypto/capabilities.py` et tests ciblés. L'API ZK actuelle est un stub de test non réel, les preuves MMR portables croissent en O(log n), et aucune validation FIPS n'est revendiquée. |
| Limite d'attestation TEE | Les nœuds de périphérique TEE sont signalés comme découverte uniquement. Les rapports hérités rédigés par l'appelant sont rejetés ; un vérificateur injecté peut fournir des revendications normalisées authentifiées pour l'évaluation de la politique de mesure exacte, de signataire, de nonce, de fraîcheur, de débogage, de TCB et de données de rapport. | `aegis/core/tee_manager.py` et tests de modules matériels. Le dépôt n'implémente pas de chargeur d'enclave, d'analyse de citations de fournisseur, de validation de certificats/collatéraux, de confidentialité de racine hôte ou d'acceptation d'attestation cible. |
| Limite de confidentialité différentielle | Une primitive interne de comptage de Laplace utilise une sensibilité de un et un CSPRNG système pour une seule publication sous adjacence d'ajout/suppression d'un enregistrement. | `aegis/core/dp_analytics.py` et tests déterministes. Aucun point de terminaison HTTP DP n'est publié ; les publications répétées nécessitent un comptable durable, une identité stable de jeu de données/requête, une mémorisation et des limites de contribution examinées qui ne sont pas implémentées ici. |
| Limite de capacité de fuzzing | Le fuzzing n'est disponible que lorsque `cargo`, `cargo-fuzz`, un espace de travail privé, un manifeste analysable borné et tous les fichiers cibles réguliers confinés exacts existent ; l'état d'exécution distingue propre, artefact de crash, erreur d'outil, délai d'attente et indisponible. | `aegis/core/fuzzing_harness.py` et tests ciblés. L'arborescence actuelle n'a pas d'espace de travail cargo-fuzz ni de harnais Kani, la couverture mesurée reste indisponible et les tests bornés ne sont pas une preuve exhaustive. |
| Contexte IA consultatif | `AGENTS.md`, `llms.txt` et `.aegis_ai_context/` fournissent la navigation du dépôt et les limites de revendication pour les assistants de codage. | Ces fichiers sont des données consultatives : ils ne peuvent pas remplacer l'autorisation, établir un comportement d'exécution ou transformer le code source fusionné en une version. |
| Limites de requête | Les corps surdimensionnés sont rejetés avant le traitement normal de l'application. | Tests de version P0/P1. Les limites doivent être dimensionnées pour le fournisseur déployé et la politique de diffusion. |
| WAF | La normalisation NFKC, le retrait des caractères de largeur nulle, les blocs de motifs critiques, la garde de profondeur structurelle et l'analyse locale pondérée s'exécutent à la limite de l'application. | `tests/data/waf_corpus_v1.json` et `tools/security/run_waf_corpus.py`. L'analyse HTTP/2 d'entrée est en dehors de la limite de l'application. |
| Sortie | Les listes d'autorisation canoniques rejettent les schémas, les userinfo, les ports malformés, les formes non prises en charge et les points de terminaison non approuvés. | `aegis/proxy/egress_guard.py` et tests. Cela ne remplace pas le pare-feu, l'espace de noms, la NetworkPolicy ou les contrôles de sortie cloud. |
| Contrôles du noyau | Le démarrage strict peut exiger les capacités Seccomp et LSM/AppArmor/SELinux et rejette l'application manquante en dehors du mode sandbox explicite. | `aegis/core/seccomp_guard.py`, `aegis/core/lsm_guard.py`, tests de déploiement. Le noyau cible nécessite encore des tests d'acceptation. |
| Enrichissement de réponse | L'analyse est bornée, observable et sérialisée par session lorsque requis. Elle est facultative et ne peut pas affaiblir le contrat de preuve durable. | Tests d'analyseurs et de files d'attente. Le comportement de la file d'attente sous saturation réelle d'E/S est décrit dans le runbook de backpressure. |
| Preuve d'inclusion portable | Chaque nouvel enregistrement de registre stocke une preuve autonome `aegis-mmr-inclusion-v1`, un digest de feuille, des pics ordonnés et une racine. Les réponses non diffusées renvoient ces éléments sous forme d'en-têtes `X-Aegis-MMR-*` ; les appels diffusés exposent un lien de preuve post-terminal authentifié. | Vecteurs dorés multilingues et tests de relecture/falsification du WAL. Une preuve valide établit l'inclusion dans la racine MMR déclarée ; elle n'établit pas en soi l'horodatage externe, la rétention ou l'admissibilité légale. |

## Démarrage rapide pour l'évaluation locale

Le chemin local est destiné au développement, aux tests et à la relecture des preuves. Il ne s'agit pas d'un profil de déploiement de production.```bash
git clone https://github.com/JuanLunaIA/aegis-latent-core.git
cd aegis-latent-core
python3 -m venv .venv
. .venv/bin/activate
python -m pip install --require-hashes -r requirements.lock
python -m pip install --no-deps -e .
python -m compileall -q aegis aegis_server
pytest -q

`development` est le seul mode non strict accepté dans le modèle de configuration actuel ; l'ancienne valeur `permissive` et la commande `uvicorn aegis.main:app` sont obsolètes. Ne placez jamais de clés de fournisseur, de jetons porteurs, de secrets de signature, d'enregistrements WAL ou de charges utiles clientes dans le contrôle de source.

## SDK à source fusionnée

La distribution Python à source fusionnée dans [`sdk/python`](https://github.com/juanlunaia/aegis-latent-core/blob/HEAD/sdk/python) est une intégration prête à l'emploi qui sous-classe les clients officiels OpenAI et Anthropic. Les types de modèles de requête/réponse existants et les API de ressources synchrones/asynchrones sont préservés tandis que les en-têtes de locataire, de session et d'authentification porteur Aegis sont injectés à la construction. L'entrée native `/v1/messages` d'Anthropic nécessite `AEGIS_PROVIDER=anthropic` ; elle préserve la forme de réponse Anthropic Messages au lieu de la traduire en objets OpenAI.

Le package TypeScript à source fusionnée compatible edge dans [`sdk/typescript`](https://github.com/juanlunaia/aegis-latent-core/blob/HEAD/sdk/typescript) vérifie les preuves `aegis-mmr-inclusion-v1` avec Web Crypto et fournit des wrappers natifs au fournisseur et des options de constructeur plutôt que de redéclarer les charges utiles du fournisseur. Les packages officiels OpenAI et Anthropic sont des dépendances de pairs, donc leurs ressources natives, paramètres de requête, modèles de réponse, itérateurs de streaming, nouvelles tentatives et types d'erreur restent faisant autorité. Les deux SDK consomment les mêmes vecteurs de preuve figés sous `sdk/shared/`.

Le candidat SDK Python non publié inclut également des adaptateurs de rappel LangChain et LlamaIndex minimisant la confidentialité. Les flux de publication sont désactivés à moins que les prérequis externes d'éditeur de confiance, d'environnement, de tag signé et de variable de dépôt ne soient configurés. Voir [`docs/DEVELOPER_INTEGRATIONS_GUIDE.md`](https://github.com/juanlunaia/aegis-latent-core/blob/HEAD/docs/DEVELOPER_INTEGRATIONS_GUIDE.md).```python
from aegis_sdk.openai import OpenAI

client = OpenAI(
    aegis_api_key="gateway-token",
    gateway_url="https://aegis.internal",
    tenant_id="tenant-42",
)
response = client.chat.completions.create(
    model="gpt-4.1-mini",
    messages=[{"role": "user", "content": "hello"}],
)

`AEGIS_DASHBOARD_API_KEY` est réservé au serveur et n'est jamais sérialisé dans les bundles du navigateur. Le point de terminaison d'exportation exige le périmètre `audit:export` lorsque des périmètres par clé sont configurés. Chaque ZIP borné contient un `manifest.json` JCS RFC 8785, un `ledger_slice.cbor` DAG-CBOR canonique identifié par CIDv1, un `merkle_proof.json`, un `audit_certificate.pdf` et un `VERIFY.sh`. Le certificat est un rapport d'intégrité technique, et non une certification ou une conclusion d'admissibilité juridique.

## Chemin de déploiement strict

Le mode strict est la posture de production prévue. Il exige une authentification, des preuves durables, une signature forte, des corps de requête bornés, un backend de limitation de débit distribué, un stockage durable et les contrôles du noyau configurés. Utilisez un gestionnaire de secrets et montez le WAL sur un chemin durable et lisible par le propriétaire.```bash
export AEGIS_SECURITY_ENFORCEMENT_MODE=strict
export AEGIS_API_KEYS='replace-with-a-secret-manager-reference'
export AEGIS_SIGNING_KEY='at-least-32-bytes-of-secret-material'
export AEGIS_RATE_LIMIT_BACKEND=redis
export AEGIS_REDIS_URL='rediss://redis.internal:6380/0'
export AEGIS_REQUIRE_DISTRIBUTED_LIMITER=true
export AEGIS_REQUIRE_DURABLE_EVIDENCE=true
export AEGIS_REQUIRE_LSM=true
export AEGIS_REQUIRE_SECCOMP=true
export AEGIS_MAX_REQUEST_BODY_BYTES=1048576
export AEGIS_BACKEND_URL='https://llm.internal.example/v1'
export AEGIS_WAL_PATH='/var/lib/aegis/aegis.wal.jsonl'

Le protocole du trousseau de clés, la fenêtre de chevauchement, l'expiration, la révocation et les critères d'acceptation à trois répliques sont dans [`docs/operations/KEY_ROTATION_RUNBOOK.md`](https://github.com/juanlunaia/aegis-latent-core/blob/HEAD/docs/operations/KEY_ROTATION_RUNBOOK.md). Un chemin de trousseau de clés n'est pas un gestionnaire de secrets ; le déploiement doit néanmoins établir la garde, le contrôle d'accès, la livraison atomique, la sauvegarde, la destruction et l'auditabilité.

## Modèle de preuve et de signature

Le registre local est un WAL JSONL en ajout seul avec une chaîne bornée en mémoire et des segments archivés facultatifs. Chaque enregistrement contient les hachages de requête et de réponse, la liaison de chaîne, une racine de Merkle, les métadonnées de signature et l'identifiant de requête. Le WAL est vidé et synchronisé avant que le chemin de réponse durable ne soit terminé.

Les choix de signature pris en charge dépendent du déploiement :

| Signataire | Limite appropriée | Limitation importante |
|---|---|---|
| HMAC-SHA256 | Déploiements auto-hébergés à nœud unique ou à secret partagé | Clé symétrique ; chaque vérificateur détenant la clé peut également signer. HMAC est classique, non résistant aux ordinateurs quantiques. |
| Signataire adossé à un HSM/Vault | Déploiements d'entreprise nécessitant une isolation des clés ou une garde à distance | La disponibilité, la politique, TLS/mTLS, la rotation et la vérification hors ligne nécessitent les propres preuves du déploiement cible. |
| Signataire natif ML-DSA-65 | Environnements qui compilent et chargent le véritable backend Rust | L'artefact candidat conservé de 1 M d'échantillons n'a trouvé aucune différence de temporisation significative pour `sign` (`p=0.8521504207157158`) mais n'a pas atteint le seuil pour `verify` (`p=0.0`) ; aucune revendication de temps constant n'est approuvée. Voir [`docs/security/PQC_CONSTANT_TIME.md`](https://github.com/juanlunaia/aegis-latent-core/blob/HEAD/docs/security/PQC_CONSTANT_TIME.md). |

Aegis ne fabrique pas de signatures ML-DSA lorsque le backend natif est indisponible. Il signale le backend comme indisponible et exige une politique de repli réelle explicite. Un résultat de temporisation avec `p > 0.05` signifierait uniquement qu'aucune fuite statistiquement significative n'a été détectée dans le cadre de l'expérience nommée ; cela ne prouverait pas une exécution à temps constant.

## Sémantique de contre-pression et de défaillance

La preuve durable est un invariant du chemin critique. En cas de blocage du stockage ou de `fsync`, le chemin de requête peut bloquer ou rejeter selon les limites configurées ; il ne doit pas abandonner silencieusement des preuves faisant autorité. La file d'enrichissement peut rejeter un travail facultatif, mais une politique de file ne peut pas transformer une réponse acceptée et régie en réponse non enregistrée.

Le harnais d'injection de fautes déterministe est :```bash
PYTHONPATH=. .venv/bin/python tools/benchmarks/run_backpressure_stall.py \
  --duration-s 0.25 --offered-rps 10000 --fsync-delay-ms 2 --max-workers 64 \
  --output evidence/backpressure_stall_report.json