seal_file

Vue d’ensemble

seal_file scelle un fichier déjà présent sur le disque en un seul appel MCP. Fonctionne pour tout type de fichier — PDF, images, archives binaires, ou texte. Le SHA-512 est calculé sur le buffer binaire du fichier (pas le décodage UTF-8), garantissant une empreinte fidèle pour les fichiers non-texte.

Le flux est : lecture binaire → SHA-512 → copie dans .seshat/sealed/ (ou ~/.seshat/vault/) → commit git (si repo) → insertion ledger → scellement IP Secure (si configuré).

Note

Pour sceller du contenu textuel sans fichier préalable, utilisez plutôt seal_content.

Paramètres

project string requis

ID du projet (lettres, chiffres, ., _, -).

file_path string requis

Chemin absolu vers le fichier à sceller (max 4096 chars).

{ "file_path": "/Users/julien/Desktop/article-recension.pdf" }

asset_types string[] requis

Type(s) d’actif IP. Voir Classification IP.

description string

Description (max 500 chars depuis v1.4.2 — #411). Apparaît sur le certificat eIDAS et est figée au moment du scellement.

Défaut : le nom du fichier. L’agent DOIT la rédiger quand il s’agit d’une publication, d’un livrable identifiable, etc. — pas se contenter du nom de fichier nu.

Attention

Pour les PDF d’au moins 10 pages, lire le contenu avant de rédiger la description est essentiel pour éviter de figer une description vague sur l’eIDAS (qui ne peut pas être ré-émis). Voir #411 et le retour Alberto 2026-05-26.

objective string

Objectif R&D pour traçabilité CIR (max 500 chars).

author string

Nom de l’auteur. Défaut : git config user.name.

dry_run boolean

Mode preview. Défaut : true si IP Secure est lié au projet.

force_secret_scan boolean défaut: false

Outrepasse le scan de secrets pré-scellement. Voir section sécurité ci-dessous.

Comportement de sécurité (depuis v1.4.2)

Le scan de secrets (#410) s’applique aux fichiers textuels uniquement. Heuristique : un fichier est considéré binaire si un octet NUL est trouvé dans les 8 premiers KB → le scan est skippé. PDF, images, archives, exécutables sont donc systématiquement passés à travers sans analyse.

Pour les fichiers texte (.txt, .md, .py, .js, .sql, etc.), les mêmes patterns que seal_content s’appliquent : clés AWS, tokens GitHub/Slack/Google, JWT, blocs PEM privés, chaînes de connexion DB, assignations password=….

Cas réel (Alberto, 2026-05-26) : un create_tbs.sql contenait connect system/PISE2024*@orcl en clair. Sans scan, le mot de passe Oracle aurait fini dans ~/.seshat/vault/ et sur le certificat eIDAS (immuable). Le scan refuse maintenant le scellement et propose à l’utilisateur de créer une copie expurgée (typiquement dans /tmp/seshat_redacted/), puis de re-seal_file depuis là.

Réponse

{
  "original_path": "/Users/julien/Desktop/article.pdf",
  "sealed_path": "/path/to/repo/.seshat/sealed/article.pdf",
  "filename": "article.pdf",
  "reference": "file:476b712a",
  "fingerprint": "476b712a...",
  "commit_sha": "abc1234567890",
  "timestamp": "2026-05-27T09:08:47.560Z",
  "ipsecure_contribution_id": "ClwTADX1NW",
  "ipsecure_certificate_url": null,
  "ipsecure_setup_hint": null,
  "project_auto_created": false,
  "dry_run": false
}

sealed_path string | null

Chemin de la copie sealed dans le vault SESHAT. C’est cette copie qui sert de référence pour seshat doctor — elle est byte-identique à l’original.

ipsecure_certificate_url string | null

Souvent null — Jinnove génère le certificat de manière asynchrone. Récupérer plus tard avec fetch_certificate(ledger_id).

Stockage

Cas	Emplacement
Projet avec repo_path	<repo_path>/.seshat/sealed/<filename> — commité
Projet sans repo_path	~/.seshat/vault/<project_id>/<filename> — pas de commit

La copie sealed est byte-identique à l’original (pas de réencodage, pas de normalisation). Re-hacher la copie sealed avec shasum -a 512 doit donner le fingerprint.

Idempotence

Si le même fichier (par SHA-512) est seal_file-é deux fois pour le même projet :

• Le doublon est détecté via fingerprintExists().
• Aucune nouvelle entrée ledger, aucune copie réécrite, aucune contribution IP Secure dupliquée.
• La réponse retourne fingerprint + reference mais sealed_path: null, commit_sha: null, ipsecure_contribution_id: null.

Workflow type

1. Préparer le fichier sur disque (chemin absolu)

2. Premier appel (dry_run par défaut si IP Secure lié)

   Scelle /Users/julien/Desktop/article.pdf pour mon projet, asset_types programme_rnd

3. Pour les PDF / documents structurés : LIRE le contenu avant

   L’agent ne devrait PAS rédiger une description “à l’aveugle” pour un fichier binaire. Pour PDF > 10 pages, voir les pré-requis poppler. Une fois le contenu lu, rédiger une description bibliographique précise (titre, auteurs, revue, DOI, etc.).

4. Présenter le preview à l’utilisateur, attendre confirmation explicite

5. Re-appel avec dry_run: false

6. Si IP Secure lié, récupérer le certificat plus tard

   Récupère le certificat pour l'entrée X (l'ID retourné par seal_file)

Vérification d’intégrité

Pour vérifier qu’une preuve scellée n’a pas été altérée :

# Hash le fichier original (s'il existe encore)
shasum -a 512 /Users/julien/Desktop/article.pdf

# Hash la copie vault
shasum -a 512 ~/.seshat/vault/mon-projet/article.pdf

# Hash stocké au ledger
sqlite3 ~/.seshat/seshat.db "SELECT fingerprint FROM ledger WHERE id = 42"

# Les trois doivent être identiques.

Le test de manipulation atomique d’Alberto (modifier 1 octet sur 4148 → 51,4 % de bits différents sur le SHA-512 — effet avalanche conforme au standard) confirme que toute altération d’octet est instantanément détectable.

Voir aussi

• seal_content — sceller du texte sans fichier
• seal — sceller un artefact git
• fetch_certificate — récupérer l’URL eIDAS asynchrone
• annotate — éditer la qualification après coup