You sell an AI agent. A serious buyer wants it. And then it reaches their security and risk committee, and the questionnaire arrives: How do you ensure the agent doesn't take unauthorised actions? What oversight exists? How would we audit what it did? You answer as best you can, and the deal goes quiet. This is where a large share of agent deals stall in 2026 — not on the product, on the risk sign-off.
This page is about what you send that actually moves that committee. Not how to pass a specific framework, and not a promise that you'll be approved — that is their call. It is about the shape of the thing that unblocks the review.
The question behind the question
"Prove it's safe" is not a question a risk team can actually check, and at some level they know it. No one can demonstrate that a system will never misbehave. What they are really asking is narrower and answerable: can we see what this agent actually does, and can we verify that ourselves without taking your word for it?
Once you hear the question that way, the reason your deal stalled becomes clear. You were answering "is it safe?" with reassurance. They were asking "can we see and verify?" and reassurance is exactly the thing a risk review exists to not rely on.
Why the usual answers don't move them
- A SOC 2 or ISO 27001 report. Genuinely useful — for your infrastructure. It says your servers, access, and processes are managed. It says nothing about what the agent did: which tools it called, whether it acted without approval, whether oversight was real. The committee's worry lives in exactly the gap those reports don't cover.
- A policy, a model card, an architecture diagram. These describe how the agent is supposed to behave. They are declarations. A risk reviewer's whole job is to not confuse a declaration with what happened — so a well-written policy, on its own, moves them very little.
- "Trust us — we've tested it extensively." This relocates the trust onto you. The reason a buyer runs a risk review is precisely so they don't have to extend that trust blind. Asking for it back is answering the wrong question.
None of these are worthless. They just don't answer can we see and verify what it did — which is the one that's blocking you.
What actually unblocks it
An evidence package: not a claim about the agent, but a reconstruction of what it did, built from its real execution — trajectories, tool calls, logs, CI runs, repository history — and handed over in a form the committee can inspect and re-check. Four properties are what make it land:
- It reconstructs behaviour, not intentions. What the agent actually did, in sequence, each fact carrying where it came from.
- Every fact is graded. A claim backed by an independent system is not presented as equal to something the agent merely asserted about itself. The reviewer can see how far each fact can be stood behind.
- What can't be shown is marked, not hidden. Where your traces carry no signal — say, whether a human genuinely reviewed an action — the package says not assessable, plainly, and names the exact event you'd need to emit to close it. It does not award a passing grade to a blind spot.
- It is independently verifiable. The file ships with a published SHA-256 manifest and an external RFC 3161 timestamp. The committee can confirm it hasn't changed since it was produced — without trusting you, and without trusting us.
You don't win a risk review by looking flawless. You win it by handing over something the reviewer can check — and finding it holds.
What you can establish — and what you can't
Being precise here is itself part of what makes you credible. From real execution records, an evidence package can typically establish what the agent did, whether declared controls actually operated — did an approval precede the action, was segregation respected, did a check run — and where the declared behaviour and the observed behaviour contradict each other.
It cannot establish that the agent is safe in the absolute, that it will behave next week, or anything your records simply never captured. Those land as not assessable — and counterintuitively, that page is often the most persuasive one in the file. It is the map of what you'd need to instrument next, and it proves you are not dressing up an unknown as a pass.
Why the honest version is the one that closes
There is a temptation to send the committee something that looks like a clean bill of health. It backfires. A reviewer who catches one inflated claim re-reads everything else hunting for the next — and now your whole package is suspect. A reviewer who sees you flag your own gaps extends credit to the parts you do stand behind. The package that closes the deal is the one that doesn't flatter the agent, because that is the only kind a professional risk team has any reason to believe.
When you don't need this
If your buyers aren't running a real security or risk review — smaller deals, low-stakes use, a customer who accepts a self-attestation — then you don't need an evidence package to close, and building one now is effort spent ahead of the need.
The moment it becomes worth it is the moment a deal is large enough, or the buyer regulated enough, that a committee stands between you and the signature. That is when "here is what it did, verify it yourself" beats "trust us" — and it is usually the deals worth the most that reach that gate.
See what one looks like
A complete evidence package from a real autonomous coding-agent run — where the declared patch contradicted the observed test outcome, and oversight was marked not assessable because the run was autonomous. It doesn't flatter the agent, and it ships with a SHA-256 manifest and an external timestamp you can verify with openssl. This is the raw material a risk-review answer is built from.
See the evidence package →
Get one for your agent →
Also read: What is AI evidence reconstruction? · How do you prove a control actually ran? · Reconstructing what an agent did when nothing was instrumented.
Vous vendez un agent IA. Un acheteur sérieux le veut. Puis cela arrive à son comité sécurité et risque, et le questionnaire tombe : Comment garantissez-vous que l'agent ne prend pas d'actions non autorisées ? Quelle supervision existe ? Comment auditerions-nous ce qu'il a fait ? Vous répondez de votre mieux, et le deal se tait. C'est là qu'une grande part des deals d'agents cale en 2026 — pas sur le produit, sur la validation risque.
Cette page parle de ce que vous envoyez qui fait vraiment bouger ce comité. Ni comment passer un référentiel précis, ni la promesse que vous serez approuvé — c'est leur décision. Elle parle de la forme de ce qui débloque la revue.
La question derrière la question
« Prouvez que c'est sûr » n'est pas une question qu'une équipe risque peut réellement vérifier, et au fond elle le sait. Personne ne peut démontrer qu'un système ne se comportera jamais mal. Ce qu'elle demande vraiment est plus étroit et répondable : pouvons-nous voir ce que cet agent fait réellement, et le vérifier nous-mêmes sans vous croire sur parole ?
Une fois la question entendue ainsi, la raison du blocage devient claire. Vous répondiez à « est-ce sûr ? » par de la réassurance. Ils demandaient « peut-on voir et vérifier ? » — et la réassurance est précisément ce sur quoi une revue risque existe pour ne pas s'appuyer.
Pourquoi les réponses habituelles ne les font pas bouger
- Un rapport SOC 2 ou ISO 27001. Vraiment utile — pour votre infrastructure. Il dit que vos serveurs, vos accès et vos processus sont gérés. Il ne dit rien de ce que l'agent a fait : quels outils il a appelés, s'il a agi sans approbation, si la supervision était réelle. L'inquiétude du comité vit exactement dans l'angle que ces rapports ne couvrent pas.
- Une politique, une model card, un schéma d'architecture. Ils décrivent comment l'agent est censé se comporter. Ce sont des déclarations. Tout le métier d'un relecteur risque est de ne pas confondre une déclaration avec ce qui s'est passé — une politique bien rédigée, seule, les fait donc très peu bouger.
- « Faites-nous confiance — on l'a beaucoup testé. » Cela déplace la confiance sur vous. Si un acheteur mène une revue risque, c'est précisément pour ne pas avoir à l'accorder à l'aveugle. La redemander, c'est répondre à côté.
Rien de tout cela n'est sans valeur. Simplement, aucun ne répond à peut-on voir et vérifier ce qu'il a fait — celle qui vous bloque.
Ce qui débloque vraiment
Un paquet de preuve : non pas une affirmation sur l'agent, mais une reconstitution de ce qu'il a fait, bâtie depuis son exécution réelle — trajectoires, appels d'outils, logs, runs CI, historique de dépôt — et remise sous une forme que le comité peut inspecter et re-vérifier. Quatre propriétés le font porter :
- Il reconstitue des comportements, pas des intentions. Ce que l'agent a réellement fait, en séquence, chaque fait portant son origine.
- Chaque fait est gradué. Une affirmation appuyée par un système indépendant n'est pas présentée comme équivalente à ce que l'agent a simplement déclaré sur lui-même. Le relecteur voit jusqu'où chaque fait peut être tenu.
- Ce qui ne peut pas être montré est marqué, pas caché. Là où vos traces ne portent aucun signal — par exemple, si un humain a vraiment revu une action — le paquet dit non évaluable, clairement, et nomme l'événement exact qu'il faudrait émettre pour combler le trou. Il n'accorde pas une note de passage à un angle mort.
- Il est vérifiable indépendamment. Le dossier est livré avec un manifeste SHA-256 publié et un horodatage RFC 3161 externe. Le comité peut confirmer qu'il n'a pas changé depuis sa production — sans vous croire, et sans nous croire.
On ne gagne pas une revue risque en paraissant irréprochable. On la gagne en remettant quelque chose que le relecteur peut vérifier — et qui tient.
Ce que vous pouvez établir — et ce que vous ne pouvez pas
Être précis ici fait partie de ce qui vous rend crédible. À partir d'enregistrements d'exécution réels, un paquet de preuve peut typiquement établir ce que l'agent a fait, si les contrôles déclarés ont réellement opéré — une approbation a-t-elle précédé l'action, la ségrégation a-t-elle été respectée, un contrôle a-t-il tourné — et là où le comportement déclaré et le comportement observé se contredisent.
Il ne peut pas établir que l'agent est sûr dans l'absolu, qu'il se comportera bien la semaine prochaine, ni rien que vos enregistrements n'ont tout simplement jamais capté. Cela tombe en non évaluable — et, contre-intuitivement, cette page est souvent la plus persuasive du dossier. C'est la carte de ce qu'il faudrait instrumenter ensuite, et elle prouve que vous ne déguisez pas un inconnu en réussite.
Pourquoi c'est la version honnête qui conclut
On est tenté d'envoyer au comité quelque chose qui ressemble à un certificat de bonne santé. Ça se retourne contre vous. Un relecteur qui attrape une affirmation gonflée relit tout le reste en cherchant la suivante — et voilà tout votre paquet suspect. Un relecteur qui vous voit signaler vos propres lacunes accorde du crédit à ce que vous soutenez. Le paquet qui conclut le deal est celui qui ne flatte pas l'agent, parce que c'est le seul type qu'une équipe risque sérieuse a une raison de croire.
Quand vous n'en avez pas besoin
Si vos acheteurs ne mènent pas de vraie revue sécurité ou risque — petits deals, usage à faible enjeu, un client qui accepte une auto-attestation — alors vous n'avez pas besoin d'un paquet de preuve pour conclure, et en construire un maintenant, c'est de l'effort dépensé avant le besoin.
Le moment où cela devient rentable, c'est celui où un deal est assez gros, ou l'acheteur assez régulé, qu'un comité se dresse entre vous et la signature. C'est là que « voici ce qu'il a fait, vérifiez-le vous-même » bat « faites-nous confiance » — et ce sont souvent les deals qui valent le plus qui atteignent ce point de passage.
Voyez à quoi ça ressemble
Un paquet de preuve complet depuis une vraie exécution d'agent de code autonome — où le patch déclaré contredisait le résultat de tests observé, et où la supervision était marquée non évaluable parce que l'exécution était autonome. Il ne flatte pas l'agent, et il est livré avec un manifeste SHA-256 et un horodatage externe vérifiables au openssl. C'est la matière première d'une réponse de revue risque.
Voir le paquet de preuve →
En obtenir un pour votre agent →
À lire aussi : Qu'est-ce que la reconstitution de preuve IA ? · Comment prouver qu'un contrôle a réellement tourné ? · Reconstituer ce qu'un agent a fait quand rien n'était instrumenté.