Les secrets et les données personnelles s'arrêtent à la passerelle

Les arguments avaient une validation de forme, les réponses un plafond de taille, et entre les deux les octets étaient opaques. Une réponse d'éditeur contenant l'adresse e-mail d'un client, ou une clé AWS que quelqu'un avait un jour collée dans un ticket, partait directement dans le contexte d'un modèle tiers et y restait.

Les deux sens ne sont volontairement pas symétriques, et cette asymétrie est toute la conception. Une réponse peut être masquée, car masquer ne fait que réduire ce qu'on dit au modèle : au pire la réponse est moins utile, au mieux un secret n'est jamais sorti du périmètre. Un argument, lui, n'est jamais réécrit. Remplacer un e-mail dans un appel de mise à jour enverrait à l'éditeur une instruction différente de celle de l'appelant : l'écriture atterrirait silencieusement sur le mauvais enregistrement, et l'audit afficherait un succès. Un argument est donc compté, et refusé net dans le mode le plus strict, mais jamais altéré.

La fonction est désactivée par défaut, serveur par serveur. Elle se place sur le chemin critique de chaque appel : un tenant qui ne l'active pas n'est donc pas affecté du tout. Là où elle est active, c'est toute la charge utile qui est analysée et non un échantillon : le plafond d'analyse est calé sur la limite de taille déjà imposée sur le réseau, pour qu'il n'y ait aucun écart entre ce qui peut arriver et ce qui est examiné.