Manque d'attribution et de forensique

Quand quelque chose tourne mal avec un agent, la première question est toujours la même : qu’a-t-il réellement fait, et qui a changé la politique qui le lui a permis ? Sans piste, vous ne pouvez répondre à aucune des deux. Vous ne pouvez pas montrer à un auditeur qu’un contrôle était en vigueur le jour en question, vous ne pouvez pas distinguer une vraie attaque d’un faux positif bruyant, et vous ne pouvez pas reconstruire l’exécution qui a laissé fuir la ligne. OrcaRouter enregistre la réponse au fil de l’eau. Chaque prompt filtré, chaque appel d’outil, chaque approbation, et chaque édition de politique atterrit dans un enregistrement interrogeable à portée d’espace de travail — corrélé à l’exécution et à la session de l’agent qui l’a produit. Cette page montre comment utiliser cet enregistrement comme une piste d’audit d’agent ia : d’une seule exécution suspecte à un rapport signé que vous remettez à un auditeur.

​

1. Les quatre enregistrements derrière une piste d’audit d’agent ia

L’attribution vient de quatre flux indépendants, chacun corrélé à la même exécution et session de sorte que vous puissiez pivoter entre eux : Le tissu conjonctif est l’id d’exécution d’agent et de session. Une correspondance de guardrail et un événement firewall de la même conversation portent la même lignée d’exécution, de sorte que « cette exécution a masqué un e-mail, puis a tenté un fetch que nous avons refusé, puis a été approuvée pour une écriture » se lit comme une seule histoire au lieu de trois journaux déconnectés.

​

2. Matches de guardrail — ce qui a été filtré (Member)

Chaque fois qu’une règle de guardrail se déclenche, la passerelle écrit une correspondance. Le flux vit sur la page Guardrails (onglet Matches) et est lisible par tout membre d’espace de travail. Chaque correspondance enregistre le type de règle, l’action prise (block / mask / flag / annotate / spotlight), la surface (input / output), une chaîne de détail, et la lignée d’exécution de la requête qui l’a déclenchée. Listez-la, groupez-la par guardrail ou type de règle, filtrez par action, plongez dans une correspondance, ou exportez le flux en CSV. Une règle bruyante fait partie de la piste aussi. Marquez une correspondance comme un faux positif avec POST /api/guardrail/match/:id/mark-fp (Admin) de sorte que votre signal reste propre et que vos rapports ne sur-comptent pas.

​

3. Events & Runs de firewall — ce que l’agent a fait (Developer+)

Là où les Matches couvrent le texte, les Events de firewall couvrent les actions. Chaque évaluation d’appel d’outil est journalisée avec son verdict, sa surface, son nom d’outil, et — de manière critique — l’exécution et la session d’agent auxquelles il appartient. Les lectures sur Events, le rollup Runs/sessions, et la trace par exécution requièrent Developer+ ; les flux plus légers Discovered-tools et anomalies sont ouverts à tout Member. La vue Runs & sessions est la bête de somme forensique : elle condense les événements par exécution d’agent en une répartition des verdicts, les outils et modèles distincts que l’exécution a touchés, et les timestamps de première/dernière apparition — la réponse « qu’a réellement fait cet agent » en un seul écran. Au-delà des verdicts statiques, le flux anomalie signale les écarts par rapport à la baseline heure-de-la-semaine apprise de chaque espace de travail (une moyenne glissante sur 14 jours) — pics de débit et de coût, retry_loop, et transitions novel_path — de sorte qu’un motif autorisé-mais-anormal fasse tout de même surface dans l’enregistrement.

​

4. Décisions d’approbation — qui a dit oui (action d’audit)

Quand une règle se résout en pending_approval, l’appel mis en attente devient une revue hors-bande (voir le flux HITL du Firewall). La décision fait partie de la piste : approuver ou rejeter écrit une ligne d’audit d’espace de travail — firewall_approval_approve ou firewall_approval_reject — nommant l’acteur. Les décisions sont first-writer-wins et idempotentes, et si la règle sous-jacente a changé après la mise en attente, l’enrichissement note que le contexte a changé. Ainsi un appel d’outil mis en attente puis approuvé est entièrement attribuable de bout en bout : l’événement firewall montre la mise en attente, la ligne d’audit montre qui l’a relâché, et les deux corrèlent à la même exécution.

​

5. Audit des changements de politique — qui a changé les règles

Une piste de comportement d’agent n’est digne de confiance que si vous pouvez aussi prouver quelle était la politique à l’époque — et qui l’a changée. Les Guardrails gardent un historique de versions complet. Chaque création, mise à jour, et suppression écrit une ligne d’historique versionnée dans la même transaction que le changement. Ouvrez History sur un guardrail pour voir chaque version avec auteur et timestamp, diff entre deux, et revert vers une plus ancienne (le revert est enregistré comme une nouvelle version — l’historique n’est jamais muté). Les changements de politique, de règle, et de réglages du Firewall écrivent chacun une ligne d’audit d’espace de travail après le commit du changement — firewall_policy_update, firewall_rule_create, firewall_settings_update, et ainsi de suite — et les changements de niveau d’autonomie (firewall_autonomy_applied / firewall_autonomy_undone) capturent le snapshot de l’état antérieur qui alimente l’annulation en un clic. Les secrets et les blobs de règles ne sont jamais journalisés.

​

6. Un exemple travaillé : tracer une exécution suspecte

Supposez qu’une exécution soit signalée pour un appel sortant inattendu. Depuis la console, avec une session Developer+ : Une exécution, quatre enregistrements corrélés, aucune archéologie de log-grep. Pour les défenses d’exfiltration elles-mêmes, voir Exfiltration de données et Appels d’outils dangereux.

​

7. Rapports de conformité signés — une piste qu’un auditeur peut vérifier

Pour une preuve externe, la surface Conformité transforme cette piste en un seul artefact. Parcourir le catalogue de frameworks, les packs, et la préparation est ouvert à tout Member et gratuit ; installer un pack, générer un rapport, passer en production, et définir la résidence des données sont des actions d’Admin d’espace de travail sur un plan payant (server-gated). Un rapport de conformité est signé Ed25519 avec un hash de contenu SHA256 et est publiquement vérifiable — le destinataire le vérifie sans compte OrcaRouter : Les rapports s’exportent en CSV / JSON / PDF. Les frameworks incluent soc2, hipaa, gdpr, iso_27001, iso_42001, nist_ai_rmf, pci_dss, l’EU AI Act (eu_ai_act), et l’OWASP Top 10 for LLM Applications (owasp_llm), entre autres — installer un pack matérialise les guardrails et politiques firewall correspondants de sorte que les contrôles sur lesquels vous rapportez soient les contrôles réellement appliqués.

​

8. Rétention et le droit à l’effacement

Un enregistrement forensique est borné, pas éternel. Les journaux de requêtes ont par défaut 30 jours de rétention et sont serrés côté serveur à un maximum dur de 180 jours. Quand un utilisateur se supprime lui-même, une fenêtre de grâce de 30 jours s’applique, après quoi sa PII est nettoyée et la cascade purge ses correspondances de guardrail, ses journaux de requêtes, et ses événements firewall — satisfaisant les obligations de droit à l’effacement / DSAR tout en gardant l’historique d’audit agrégé intact.

​

9. Où aller ensuite