L'attribution par IA, ou quand le texte ne suffit plus

Voici une petite expérience. Ouvre ton terminal et tape :

git commit --allow-empty -m "Fix critical security bug
Co-authored-by: Linus Torvalds <linus@kernel.org>"

Félicitations. Tu viens de cosigner un commit avec le créateur de Linux. Personne ne t'a demandé de preuve. Personne n'a vérifié si tu avais vraiment discuté avec Linus. Le maintainer du kernel te fait confiance, c'est bon ?

Bien sûr que non. Mais c'est exactement ce que des milliers d'organisations font chaque jour quand un agent de coding IA ajoute "Co-authored-by: Claude" ou "Co-authored-by: Copilot" et que quelqu'un en aval treat cette ligne comme une vraie attribution.

Le problème du théâtre de l'attribution

Voici la vérité qui dérange : ce petit "Co-authored-by" en bas de tes commits assistés par IA, ce n'est pas une attribution. C'est une chaîne de caractères. Elle est falsifiable par conception, ce qui est acceptable quand c'est cosmétique — mais ça devient problématique quand on s'en sert pour autre chose de plus conséquent.

Quand les agents de coding IA passent de l'écriture de documentation à la modification de code en production, de merge pipelines et d'infrastructure, la question "quel agent a produit ça ?" n'est plus de la curiosité. C'est une question de supply chain logicielle. Et quand des plateformes se servent de métadonnées d'attribution non vérifiées pour prendre des décisions de confiance — comme approuver automatiquement des PRs en fonction de leur auteur supposé — tu as une surface d'attaque en pleine vue.

La preuve de concept est proprement inquiétante. Des chercheurs ont démontré que des métadonnées d'auteur forgées peuvent tromper des workflows de review automatisés pour traiter des commits malveillants comme dignes de confiance. Deux-trois commandes git config, pas d'exploit nécessaire. L'agent voit un auteur "reconnu" et proceed. Le payload arrive.

Ce n'est pas un bug de git. Git a toujours permis de mettre l'auteur qu'on veut — c'est précisément pour ça qu'on a le signing GPG. Le bug, c'est l'hypothèse que le champ auteur signifie quelque chose qu'il ne signifie pas.

Pourquoi ça concerne ton stack

Si tu gères une startup, voici où ça devient concret : ton workflow de développement assisté par IA génère probablement des dizaines ou des centaines de commits par semaine. Ton CI/CD a sûrement de l'automatisation qui fait plus confiance à certains contributeurs qu'à d'autres. Peut-être que tu as configuré de la branch protection qui skip certains checks pour les auteurs "connus". Peut-être que ton agent de review IA pèse la réputation du contributeur.

Toute cette confiance repose sur un socle de chaînes falsifiables.

Le problème des métadonnées d'attribution devient particulièrement aigu quand tu考虑 les workflows multi-agents. Le développement moderne chain souvent des agents entre eux — un agent écrit le code, un autre le review, un troisième gère le déploiement. Chaque étape peut revendiquer une authorship. Sans vérification cryptographique, tu prends littéralement leur parole. Et les agents, comme tout logiciel, peuvent être prompt-injected, mal configurés ou manipulés.

Tu n'accepterais pas un bon de commande avec un petit "approuvé par le DAF" écrit à la main et pas de signature. Pourquoi est-ce que tu acceptes des commits générés par IA sans preuve d'identité ?

La pièce manquante : la provenance cryptographique

La solution n'est pas de supprimer l'attribution — c'est de la rendre significative. Ce dont l'écosystème a besoin, c'est d'une couche de production-attribution où les affirmations sur quel agent a produit un artefact sont backing par des preuves cryptographiques, pas juste du texte.

Cela signifie traiter les agents de coding IA comme ce qu'ils sont : des principals logiciels qui ont besoin de leur propre infrastructure d'identité. Chaque principal agent reçoit une clé de signing. Les commits sont signés avec cette clé. La vérification se fait contre la clé publique, pas le champ auteur. Le trailer git devient une affirmation ; la signature devient la preuve.

L'implémentation pratique a quelques couches :

L'attribution en texte brut reste importante parce que les humains doivent pouvoir la lire. La différence, c'est que cette couche devient une affirmation à vérifier, pas une affirmation à croire. Les trailers structurés — nom de l'agent, version du modèle, ID de session, provider — te donnent l'audit trail nécessaire. L'ID de session est particulièrement utile : il te permet de passer de "ce commit a été écrit par l'agent X" à "voici la conversation exacte et le contexte qui ont mené à ce code."

Le signing cryptographique, c'est le mécanisme d'exécution. Avec SSH commit signing (maintenant supporté nativement par GitHub et GitLab), chaque principal agent a une paire de clés. La clé privée vit dans l'environnement d'exécution de l'agent. Quand il signe un commit, il prouve son identité cryptographiquement. N'importe qui peut vérifier : ce commit a vraiment été produit par cet agent, parce que seul cet agent détient la clé privée correspondante.

Les clés backed par hardware, c'est ce qui rend le tout robuste. Pour les systèmes en production, la clé de signing devrait vivre dans un hardware security module ou au minimum un enclave dédié. Ça empêche un runtime agent compromis de voler la clé et de signer des commits forgés. La clé ne quitte jamais l'environnement sécurisé ; l'agent l'appelle pour signer.

Construire des chaînes de confiance pour la sortie IA

Voici où ça devient intéressant pour les builders de plateformes. Quand tu as une provenance cryptographique pour les artefacts générés par IA, tu déverrouilles des capacités impossibles avec des métadonnées forgées.

Des audit trails qui ont de la substance. Tu peux répondre de façon définitive à "quel modèle a produit ce code ?" pour la conformité, le debugging ou la réponse à incident. La réponse est vérifiable par n'importe qui, pas juste acceptée par foi.

Du trust routing. Les systèmes futurs pourraient pondérer le retrieval-augmented generation par producteur vérifié. Du code venant d'un modèle avec un track record prouvé de qualité pourrait recevoir un traitement différent d'une output anonyme. Ça nécessite la couche de provenance, pas juste une assertion.

Des frontières de propriété intellectuelle. Pour les développeurs qui travaillent à la fois sur de l'open source et du code propriétaire (ou des développeurs employees utilisant des outils IA avec des termsambigus), l'attribution cryptographique distingue le travail humaine-authored de celui AI-assisted. Quand la clause IP de ton employeur dit "ne commit pas de code propriétaire sur des repos publics", une attribution vérifiable rend la conformité vérifiable.

De l'évaluation de modèle. Corréler les principaux signants avec les outcomes te permet de mesurer quels modèles, providers ou stratégies de prompting produisent réellement du meilleur code. Tu ne peux pas améliorer ce que tu ne peux pas mesurer, et tu ne peux pas mesurer l'attribution si elle est falsifiable.

Le tableau d'ensemble : les agents IA ont besoin d'infrastructure d'identité

Ce problème d'attribution est un symptôme d'un manque plus large : les agents de coding IA sont intégrés dans des infrastructures critiques avant même qu'on ait built l'infrastructure d'identité et de confiance pour les gérer en toute sécurité.

On a du PKI pour les humains. On a OAuth pour les services. On a des hardware tokens pour les opérations sensibles. Mais pour les agents IA qui touchent du code, modifient des tickets et déploient des changements ? On fait surtout confiance à une chaîne de caractères qui dit "je suis celui que je prétends être."

Ce n'est pas une critique des agents — ils font ce qu'on leur a demandé de faire. C'est un gap de design système. Quand les agents IA deviennent des acteurs de première classe dans ton workflow de développement, ils ont besoin d'une infrastructure d'identité de première classe.

Pour la communauté de développement, ça signifie commencer à considérer les principaux agents comme on considère les service accounts. Chacun a besoin de ses propres credentials, de permissions scopées, d'audit logging et de politiques de rotation. La signature de commit, c'est juste l'artefact visible de cette infrastructure.

Pour les plateformes et les tool builders, ça signifie intégrer la vérification dans le workflow de review. Ne fais pas confiance au champ auteur — vérifie la signature. Traite les métadonnées non vérifiées comme tu traites les inputs non vérifiés : sanitize-les, ou ignore-les.

La ligne "Co-authored-by" ne va pas disparaître. C'est des métadonnées utiles lisibles par les humains. Mais la traiter comme plus qu'une affirmation — surtout quand tu prends des décisions de confiance — c'est un risque que l'industrie ne peut plus se permettre d'ignorer.

Les outils existent. Les standards mûrissent. La seule question, c'est si on va build l'infrastructure avant que le premier incident majeur ne la rende urgente.

Spoiler : d'habitude, il faut un incident. Voyons si on peut prendre de l'avance sur celui-ci.

Le Vibe Hosting de NameOcean inclut des environnements de développement assistés par IA avec des workflows de signing intégrés pour les équipes qui livrent du code en production avec des agents IA. Parce que l'attribution cosmétique ne suffit pas quand les enjeux sont réels.