You did the work. You have a SOC 2 Type II, or ISO 27001, or both. And yet the enterprise buyer's risk team keeps asking questions about your AI agent that your report doesn't seem to answer — and you're not sure whether that's a deficiency to fix or a misunderstanding to correct.
It's the second. Your report is doing its job. It's just answering a different question from the one the risk team is now asking. Understanding the difference is what lets you respond without either over-promising or sounding defensive.
What SOC 2 actually attests
A SOC 2 report is an attestation, by an independent auditor, that your organisation operates a set of controls over a system, assessed against the Trust Services Criteria — security, availability, confidentiality, processing integrity, privacy — over a defined period. It says: your access is managed, your change process is followed, your environment is monitored, your incidents are handled. It is real assurance, and it is valuable.
Notice the unit of analysis. SOC 2 is about your control environment — the organisation and the system as a whole, over a period. It is not about a single execution of an agent, and it was never designed to be.
The layer it doesn't reach
An AI agent doesn't just run — it acts. It calls tools, takes decisions, and on any given run it may do something no control diagram anticipated. The risk team's worry lives there, at the level of the individual run, and it takes the form of questions SOC 2 structurally does not answer:
- On this run, did the agent take an action it wasn't authorised to take?
- When your policy says a human approves high-risk actions — did a human actually approve this one, or did the approval arrive faster than anyone could have read it?
- If something went wrong last Tuesday, can you reconstruct what the agent did, step by step, from records you can stand behind?
- Where the agent's behaviour and your stated controls disagree, which one actually happened?
Processing integrity — the closest Trust Services criterion — comes nearest, but it asks whether a system's processing is complete, valid, accurate and authorised at the level of the control environment. A SOC 2 auditor does not reconstruct individual agent trajectories and grade what each one demonstrates. That is simply not the instrument.
SOC 2 tells a buyer your house is in order. It doesn't tell them what one particular guest did while they were inside.
Why the gap is widening, not closing
The certification frameworks buyers trust were built for a risk model where the danger is a breach, an outage, a mishandled record — things you prevent with controls over a system. Agents introduce a different danger: the system does exactly what it was allowed to do, autonomously, and the allowed set turns out to include something no one wanted. That risk is behavioural, it lives in the run, and it's growing faster than the frameworks are adapting. This is why more of your buyers' security questionnaires now have a section your SOC 2 doesn't cleanly satisfy.
What sits on the layer SOC 2 doesn't
An evidence package over the agent's actual execution. Not a second certificate — a reconstruction of what the agent did on real runs, built from its trajectories, tool calls, logs and repository history, and handed over in a form the risk team can inspect and re-verify. It answers the run-level questions directly: what the agent did, whether the declared controls operated, where behaviour and claim contradict, and — stated plainly — what the records cannot establish. It ships with a published SHA-256 manifest and an external timestamp, so the committee can confirm it independently.
The relationship is complementary, and worth saying out loud to the buyer: SOC 2 attests your control environment; the evidence package shows what the agent did inside it. One is about your organisation over a period; the other is about behaviour on a run. A mature answer to a risk committee brings both.
Where the honesty has to be
Two boundaries, so this doesn't read as a pitch. First, an evidence package is not a clean bill of health any more than SOC 2 is — it reports states, not scores, and where your traces carry no signal it says not assessable rather than inventing a pass. Second, sometimes SOC 2 genuinely is enough: if the buyer's concern is really about your infrastructure and data handling, the report answers it, and reaching for more is answering a question no one asked. The skill is knowing which layer the committee is actually worried about — and not sending a control-environment answer to a behavioural question, or vice versa.
See the layer SOC 2 doesn't reach
A complete evidence package from a real autonomous coding-agent run — what it did, graded by provenance, with the declared patch shown contradicting the observed test outcome and oversight marked not assessable. Published with a SHA-256 manifest and an external timestamp you can verify with openssl. This is what run-level evidence looks like.
See the evidence package →
Get one for your agent →
Also read: How do you prove your AI agent is safe to a customer's risk team? · AI observability vs AI evidence · How do you prove a control actually ran?.
Vous avez fait le travail. Vous avez un SOC 2 Type II, ou une ISO 27001, ou les deux. Et pourtant l'équipe risque de l'acheteur entreprise continue de poser, sur votre agent IA, des questions auxquelles votre rapport ne semble pas répondre — et vous ne savez pas si c'est un défaut à corriger ou un malentendu à dissiper.
C'est le second. Votre rapport fait son travail. Il répond simplement à une autre question que celle que pose maintenant l'équipe risque. Comprendre la différence est ce qui vous permet de répondre sans sur-promettre ni paraître sur la défensive.
Ce que SOC 2 atteste réellement
Un rapport SOC 2 est une attestation, par un auditeur indépendant, que votre organisation opère un ensemble de contrôles sur un système, évalués selon les Trust Services Criteria — sécurité, disponibilité, confidentialité, intégrité de traitement, vie privée — sur une période donnée. Il dit : vos accès sont gérés, votre processus de changement est suivi, votre environnement est surveillé, vos incidents sont traités. C'est une vraie assurance, et elle a de la valeur.
Remarquez l'unité d'analyse. SOC 2 porte sur votre environnement de contrôle — l'organisation et le système dans leur ensemble, sur une période. Il ne porte pas sur une exécution unique d'un agent, et n'a jamais été conçu pour.
La couche qu'il n'atteint pas
Un agent IA ne fait pas que tourner — il agit. Il appelle des outils, prend des décisions, et sur une exécution donnée il peut faire quelque chose qu'aucun schéma de contrôle n'avait anticipé. L'inquiétude de l'équipe risque vit là, au niveau de l'exécution individuelle, et prend la forme de questions auxquelles SOC 2 ne répond structurellement pas :
- Sur cette exécution, l'agent a-t-il pris une action qu'il n'était pas autorisé à prendre ?
- Quand votre politique dit qu'un humain approuve les actions à haut risque — un humain a-t-il vraiment approuvé celle-ci, ou l'approbation est-elle arrivée plus vite que quiconque n'aurait pu la lire ?
- Si quelque chose a mal tourné mardi dernier, pouvez-vous reconstituer ce que l'agent a fait, étape par étape, depuis des enregistrements que vous pouvez tenir ?
- Là où le comportement de l'agent et vos contrôles déclarés divergent, lequel s'est réellement produit ?
L'intégrité de traitement — le critère Trust Services le plus proche — s'en rapproche le plus, mais il demande si le traitement d'un système est complet, valide, exact et autorisé au niveau de l'environnement de contrôle. Un auditeur SOC 2 ne reconstitue pas les trajectoires individuelles d'un agent pour graduer ce que chacune démontre. Ce n'est tout simplement pas l'instrument.
SOC 2 dit à un acheteur que votre maison est en ordre. Il ne lui dit pas ce qu'un invité en particulier a fait pendant qu'il était à l'intérieur.
Pourquoi l'écart se creuse, au lieu de se combler
Les référentiels de certification auxquels les acheteurs se fient ont été bâtis pour un modèle de risque où le danger est une brèche, une panne, un enregistrement mal traité — des choses qu'on prévient par des contrôles sur un système. Les agents introduisent un autre danger : le système fait exactement ce qu'il avait le droit de faire, de façon autonome, et l'ensemble autorisé se révèle inclure quelque chose que personne ne voulait. Ce risque est comportemental, il vit dans l'exécution, et il croît plus vite que les référentiels ne s'adaptent. C'est pourquoi de plus en plus de questionnaires sécurité de vos acheteurs ont désormais une section que votre SOC 2 ne satisfait pas proprement.
Ce qui se trouve sur la couche que SOC 2 n'atteint pas
Un paquet de preuve sur l'exécution réelle de l'agent. Pas un second certificat — une reconstitution de ce que l'agent a fait sur de vraies exécutions, bâtie depuis ses trajectoires, appels d'outils, logs et historique de dépôt, et remise sous une forme que l'équipe risque peut inspecter et re-vérifier. Il répond directement aux questions au niveau de l'exécution : ce que l'agent a fait, si les contrôles déclarés ont opéré, là où comportement et affirmation se contredisent, et — dit clairement — ce que les enregistrements ne peuvent pas établir. Il est livré avec un manifeste SHA-256 publié et un horodatage externe, pour que le comité le confirme indépendamment.
La relation est complémentaire, et vaut la peine d'être dite à l'acheteur : SOC 2 atteste votre environnement de contrôle ; le paquet de preuve montre ce que l'agent a fait à l'intérieur. L'un porte sur votre organisation sur une période ; l'autre sur le comportement sur une exécution. Une réponse mûre à un comité risque apporte les deux.
Où l'honnêteté doit se trouver
Deux limites, pour que ceci ne se lise pas comme un argumentaire. D'abord, un paquet de preuve n'est pas plus un certificat de bonne santé que SOC 2 — il rapporte des états, pas des scores, et là où vos traces ne portent aucun signal, il dit non évaluable au lieu d'inventer une réussite. Ensuite, parfois SOC 2 suffit vraiment : si l'inquiétude de l'acheteur porte réellement sur votre infrastructure et votre traitement des données, le rapport y répond, et en chercher davantage, c'est répondre à une question que personne n'a posée. L'habileté, c'est de savoir quelle couche préoccupe réellement le comité — et de ne pas envoyer une réponse d'environnement de contrôle à une question comportementale, ni l'inverse.
Voyez la couche que SOC 2 n'atteint pas
Un paquet de preuve complet depuis une vraie exécution d'agent de code autonome — ce qu'il a fait, gradué par provenance, avec le patch déclaré montré en contradiction avec le résultat de tests observé et la supervision marquée non évaluable. Publié avec un manifeste SHA-256 et un horodatage externe vérifiables au openssl. Voilà à quoi ressemble une preuve au niveau de l'exécution.
Voir le paquet de preuve →
En obtenir un pour votre agent →
À lire aussi : Comment prouver que votre agent IA est sûr à l'équipe risque du client ? · Observabilité IA vs preuve IA · Comment prouver qu'un contrôle a réellement tourné ?.