Rapport public de due diligence : Secura

Secura se présente publiquement comme une API de “secure execution” pour agents autonomes, en bêta privée (v0.9.1-beta). Le positionnement est cohérent et directement lisible : limiter les permissions des agents, intercepter les décisions risquées, maintenir une exécution tolérante aux pannes et produire des journaux d'audit immuables. Les pages publiques confirment un socle narratif fort autour de quatre primitives — permissions, intervention, résilience, audit — et une documentation d'accès par clés de test expirant après 72 heures. [S1][S2]

Le niveau de preuve public reste toutefois insuffisant pour une adoption de production dans un contexte sensible. Les pages légales, sécurité et statut affichées en pied de page retournent une page 404 lors de l'observation ; aucune politique de confidentialité, condition d'utilisation, DPA, SLA, page de statut, attestation SOC 2 ou documentation de responsabilité n'a été trouvée sur les surfaces consultées. Les métriques “live telemetry” affichées dans le rendu public montrent 0/100, 0.00% et 0.0%, tandis que la balise meta description annonce un trust score de 97/100 et une reliability de 99.93%. [S1][S3][S4][S5][S6]

Constat public

L'identité opérationnelle observée est Secura, avec le titre de page “Secura — Secure Execution API for Autonomous Agents”. La homepage présente le produit comme une “structured safety layer for autonomous agents”, en bêta privée, et affiche v0.9.1-beta. Le copyright de pied de page indique © 2025. [S1]

L'identité légale n'est pas établie par les surfaces publiques consultées. Les liens de pied de page intitulés Privacy, Terms, Security, Status et GitHub sont visibles dans le rendu public, mais les routes testées pour privacy, terms, security et statusretournent une page 404. Aucun nom d'entité légale, adresse, pays de constitution, numéro d'immatriculation, responsable du traitement, DPO, équipe dirigeante ou contact support n'a été identifié sur la homepage ou la documentation. [S1][S3][S4][S5][S6]

Lecture diligence

Pour un fournisseur qui vend une couche de sécurité d'exécution, l'absence de mentions légales publiques est un déficit de confiance substantiel. Elle ne prouve pas que ces éléments n'existent pas en interne, mais elle empêche un acheteur, investisseur ou partenaire de vérifier rapidement qui contracte, qui opère le service, dans quelle juridiction les engagements s'appliquent, et quel régime de responsabilité encadre l'usage. [S1][S3][S4][S5][S6]

Points à clarifier avant intégration

• Entité contractante, adresse légale, juridiction applicable et contact opérationnel.
• Conditions d'utilisation, politique de confidentialité, DPA éventuel, liste des sous-traitants et mécanisme de notification d'incident.
• Statut exact de la bêta privée : disponibilité commerciale, restrictions d'usage, niveaux de support et politique de résiliation.

Surfaces observées

La surface publique principale est https://secura.nanocorp.app/, complétée par https://secura.nanocorp.app/docs. La homepage expose une architecture produit déclarative autour de quatre primitives : Scoped Permissions, Intervention Handlers, Fault Tolerance et Audit Trails. Elle affirme une intégration en quelques lignes, une compatibilité avec LangChain, CrewAI et agents personnalisés, un modèle webhook-first pour l'outillage d'audit, et des exports de traces compatibles OpenTelemetry. [S1]

La documentation publique décrit des routes d'API : POST /api/keys/trial, POST /api/keys/validate, GET /api/free-period-key et POST /api/v1/execute. Les exemples montrent des champs userId, email, metadata, apiKey, task et permissions. L'observation passive n'a pas soumis de requête POST et n'a pas demandé de clé ; un GET simple sur /api/keys/trial retourne 405, comportement cohérent avec une route POST documentée. [S2][S11]

Le site public est servi avec des en-têtes indiquant un hébergement derrière Cloudflare/NanoCorp/Vercel, avec strict-transport-security, x-vercel-cache, x-matched-path, x-nextjs-prerender sur les pages applicables et x-proxy: nanocorp-worker. La page inclut aussi un script d'analytics NanoCorp côté client. Ces éléments renseignent l'architecture de livraison web, mais ne permettent pas de conclure sur l'architecture backend de l'API Secura. [S1][S2]

Éléments non vérifiés

Le code d'exemple installe @secura/sdk, mais la requête publique au registre npm pour @secura/sdk a retourné 404 Not foundau moment de l'observation. Cela peut s'expliquer par un package privé, non publié, renommé ou non indexé ; en l'état, la disponibilité publique du SDK n'est pas confirmée. [S1][S10]

Le checkout de production est un lien Stripe public (buy.stripe.com) accessible en consultation passive. Aucun achat, formulaire ou donnée de paiement n'a été soumis. [S9]

3.1 Données clients et données d'exécution

Secura décrit un service placé au cœur de l'exécution des agents. Les exemples publics impliquent au minimum la collecte ou le transit d'un identifiant utilisateur (userId), d'un email, de métadonnées, d'une clé API, d'une tâche en langage naturel et d'une liste de permissions. La homepage indique également des journaux d'audit immuables de chaque action, décision et transition d'état, avec capacité de replay pour debugging et forensic analysis. [S1][S2]

Cette surface est sensible : une tâche d'agent peut contenir des données clients, du contexte métier, des instructions confidentielles ou des références à des systèmes internes ; les journaux d'audit peuvent contenir des traces détaillées de décisions et d'actions. La valeur de Secura dépend précisément de sa capacité à observer et contrôler ces informations. [S1][S2]

Les preuves publiques sont insuffisantes sur les sujets suivants : politique de confidentialité, finalités de traitement, durée de conservation des logs, chiffrement au repos, chiffrement applicatif éventuel, séparation des tenants, localisation des données, sous-traitants, droits des personnes, purge, export, DPA et procédure d'incident. Les routes Privacy et Terms retournent 404, ce qui rend impossible une vérification documentaire de base. [S3][S4]

3.2 Prompts, injection et contrôle des décisions agentiques

La proposition de Secura couvre partiellement le risque d'agentic failure par design : permissions déclarées, allow/deny lists, intervention handlers capables de pause/redirect/halt, score de risque dans l'exemple (ctx.riskScore > 0.8) et exécution limitée par maxSteps. Ces éléments sont alignés avec une approche de contrôle runtime, plutôt qu'une simple revue statique des prompts. [S1]

La documentation publique ne décrit toutefois pas les mécanismes précis de résistance à l'injection de prompt, à l'instruction indirecte, à la confusion d'outils, à la sur-permission dynamique, à la contamination de contexte, à la sortie de périmètre ou à l'escalade par chaînes multi-étapes. Elle ne précise pas non plus si les règles sont évaluées avant chaque tool call, après chaque réponse modèle, au niveau des entrées utilisateur, au niveau des sorties outil, ou via un moteur de politique indépendant du modèle. [S1][S2]

Le claim “Agents operate exclusively within declared boundaries — no scope creep” est fort. Sans documentation sur le modèle de menace, les limites connues, les faux positifs/faux négatifs, les tests adversariaux et les conditions d'échec, il doit être lu comme un positionnement produit, non comme une preuve de sécurité exhaustive. [S1]

3.3 Credentials, clés API et séparation d'accès

Le parcours d'accès public repose sur des clés de test gratuites expirant après 72 heures. La documentation indique une clé active par utilisateur, un retour 409 si un utilisateur a déjà consommé un essai expiré, et une validation via Authorization: Bearer, x-api-key ou x-secura-api-key. Après le premier jour, la validation renvoie un statut expiring_soon, un remainingDays, un paymentSetupRequiredet une instruction destinée à être transmise par l'agent à son utilisateur. [S2]

• Le format, l'entropie, le stockage et le hashing des clés ne sont pas documentés publiquement. [S2]
• Les mécanismes de rotation, révocation, expiration forcée, limitation de débit, détection d'abus et verrouillage de compte ne sont pas visibles. [S2]
• Les permissions semblent déclarées par l'intégrateur dans l'appel d'exécution, mais la documentation publique ne précise pas comment Secura vérifie qu'une permission demandée est autorisée par la clé, le tenant ou le contrat. [S2]
• La compatibilité GET /api/free-period-key est mentionnée, mais non testée afin d'éviter d'émettre une clé ou de modifier un état. [S2]

La présence d'un endpoint de validation acceptant plusieurs emplacements de clé est pratique pour l'intégration, mais elle accroît la nécessité d'une documentation claire sur la priorité, les logs, la redaction des secrets et la prévention d'exposition dans les traces. [S2][S3][S5]

3.4 Paiements, conversion et responsabilité commerciale

Le site relie l'accès production à un checkout Stripe public. La documentation indique que les payloads d'expiration et de warning incluent une action URL vers le paiement de production. [S2][S9]

Le choix d'un checkout Stripe réduit potentiellement l'exposition directe de Secura aux données de carte, mais il ne remplace pas les obligations commerciales et juridiques du fournisseur : conditions de vente, remboursement, taxes, facturation, support, renouvellement, annulation, SLA et responsabilité en cas de mauvaise exécution d'un agent. Or les pages Terms et Privacyretournent 404, et aucune page de pricing détaillée autre que le CTA checkout n'a été observée. [S1][S4][S9]

Le fait que l'agent soit explicitement instruit d'informer l'utilisateur qu'il doit configurer un paiement introduit une dimension UX/compliance spécifique : l'instruction de paiement est transmise via l'agent autonome, non seulement via une interface SaaS classique. [S2]

3.5 Continuité opérationnelle, fiabilité et observabilité

Secura affirme une tolérance aux pannes avec retry automatique, exponential backoff, circuit breakers et graceful degradation. La homepage met en avant une latence annoncée inférieure à 2 ms d'overhead, des traces OpenTelemetry-compatible, des webhooks et des métriques de confiance/reliability/multi-step success. [S1]

La matérialité publique est contradictoire. Le rendu observé affiche Trust Score 0/100, Reliability 0.00% et Multi-Step Success 0.0%. La balise meta description du HTML annonce en revanche Trust score 97/100 et 99.93% reliability. Sans page de statut fonctionnelle, historique d'incidents, méthodologie de calcul ou preuve de monitoring, il n'est pas possible de déterminer si les zéros sont des placeholders, un bug de rendu, une absence de données, ou l'état réel du service au moment de l'observation. [S1][S6]

La page Statusvisible en footer retourne 404. Ce point est particulièrement important pour un produit d'exécution agentique : si Secura se place dans le chemin critique d'un agent autonome, son indisponibilité peut bloquer l'agent, dégrader un workflow ou créer des comportements de fallback dangereux. [S6]

3.6 Juridique, conformité et responsabilité sécurité

La homepage affiche SOC 2 / Type II Readyet décrit des exports “compliance-ready”. Le vocabulaire est utile commercialement, mais “ready” ne vaut pas attestation. Aucune attestation SOC 2, lettre d'auditeur, période couverte, critères de contrôle, politique de sécurité, page trust center ou documentation de conformité n'a été trouvée. [S1][S5]

Le produit revendique l'immutabilité des audit trails et une capacité de replay forensic. Ces claims engagent des attentes fortes : intégrité des logs, horodatage fiable, protection contre altération, contrôle d'accès aux traces, chaîne de conservation, export probant, rétention et suppression. Aucun détail public ne permet de vérifier ces propriétés. [S1]

La responsabilité est également non cadrée. Si un agent exécute une action dommageable malgré Secura, ou si Secura bloque une action légitime et cause une perte, les surfaces publiques ne disent pas qui supporte le risque, quelles exclusions s'appliquent, quel support existe, ni quels engagements de correction ou notification sont fournis. [S3][S4]

Les signaux de traction publique sont faibles. La page indique une bêta privée et un produit v0.9.1-beta. Aucun logo client, cas d'usage détaillé, témoignage, métrique d'adoption, volume d'appels, nombre de tenants, revenu, benchmark externe ou présence SERP significative liée à Secura n'a été identifié dans les requêtes exact-match effectuées. [S1][S12]

Les métriques de performance affichées sont difficiles à exploiter : l'overhead annoncé est <2ms, mais aucune méthodologie, environnement de mesure, percentile, volume ou benchmark n'est fourni. Les métriques live rendues à zéro sont incompatibles avec la meta description plus positive. [S1]

1. Dépendance chemin critique. Secura se positionne entre l'agent et ses actions. Une panne, latence élevée ou décision erronée peut bloquer ou altérer des workflows. Les modes fail-open/fail-closed ne sont pas documentés. [S1][S6]
2. Maturité bêta. Le statut v0.9.1-beta et l'absence de pages légales/status suggèrent une maturité publique encore limitée. [S1][S3][S4][S6]
3. Disponibilité SDK non confirmée. Le package @secura/sdk cité dans la documentation de la homepage n'a pas été trouvé sur le registre npm public consulté. [S10]
4. Ambiguïté métrique. Les zéros de télémétrie visibles peuvent être interprétés défavorablement s'ils restent publics. [S1]
5. Checkout avant cadre contractuel. Le parcours paiement est accessible alors que les conditions et la confidentialité ne le sont pas. [S4][S9]

Secura vend un message de sécurité. Cette catégorie augmente l'exigence de preuve : les visiteurs attendent un niveau de rigueur supérieur à un simple SaaS généraliste. Trois éléments peuvent créer un risque réputationnel immédiat : liens de pied de page 404, métriques live à zéro et claim SOC 2 / Type II Readynon accompagné d'une explication. [S1][S3][S4][S5][S6]

Le risque n'est pas seulement qu'un client refuse d'acheter ; il est qu'un observateur interprète les claims comme prématurés. Dans un secteur où les termes “secure”, “immutable”, “compliance-ready” et “no scope creep” sont sensibles, il est préférable de publier moins de claims, mais mieux sourcés, que de maintenir des formulations absolues sans documentation. [S1][S5]

Les risques juridiques principaux sont liés à l'absence de cadre public plutôt qu'à un problème prouvé :

• Données personnelles et confidentialité : l'exemple collecte un email et des métadonnées, sans politique privacy accessible. [S2][S3]
• Conditions commerciales : le checkout production est accessible, sans conditions publiques observées. [S4][S9]
• Responsabilité d'exécution : aucune clause publique ne définit les limites de responsabilité si un agent cause une erreur malgré Secura ou si Secura bloque une opération nécessaire. [S1][S4]
• Claims conformité : SOC 2 / Type II Ready et “compliance-ready exports” doivent être encadrés pour ne pas être confondus avec une certification ou attestation effective. [S1]
• Preuve et audit logs : l'immutabilité et le replay forensic peuvent impliquer des obligations de conservation, d'accès, de purge et de protection, non documentées publiquement. [S1]

Ces constats ne constituent pas un avis juridique. Ils indiquent les points à vérifier contractuellement avant intégration ou investissement.

Conditions minimales avant production

1. Publier ou fournir sous NDA les documents légaux : Terms, Privacy, DPA, sous-traitants, juridiction, support, SLA, incident response.
2. Publier une page sécurité expliquant stockage des clés, chiffrement, séparation tenant, redaction des secrets, rotation/révocation, rate limits et modèle de menace.
3. Corriger les liens 404 du footer et expliquer les métriques live, avec méthodologie de calcul et historique.
4. Clarifier le statut SOC 2 / Type II Ready : readiness interne, audit en cours, attestation disponible, ou simple objectif.
5. Confirmer la disponibilité du SDK, son canal de distribution, sa version, son changelog et sa signature/provenance.
6. Documenter les limites des protections contre prompt injection, tool misuse, sur-permission et exécution multi-étapes.

Conditions d'usage acceptable maintenant

Secura peut être observé, testé uniquement dans un environnement non sensible avec données synthétiques, et évalué comme composant prometteur d'une future stack agentique. Toute donnée client réelle, secret, action irréversible, paiement automatisé, opération réglementée ou système de production devrait rester hors périmètre jusqu'à clarification.

Toutes les sources ci-dessous ont été consultées le 2026-08-05entre 13:33 et 13:35 UTC. Les consultations ont été passives : GET/HEAD HTTP, rendu navigateur public, lecture de pages et requêtes exact-match de recherche. Aucun login, achat, soumission de formulaire, POST API, scan de ports, fuzzing, bruteforce, contournement ou accès non public n'a été réalisé.

La revue suit huit sections : identité, architecture, sécurité, performance/traction, risques opérationnels, risques réputationnels, risques juridiques et recommandation. La sécurité est volontairement centrale et découpée en six dimensions : données clients, prompts/injection, credentials/API keys, paiements, continuité opérationnelle et juridique/responsabilité.

Chaque affirmation matérielle est rattachée à une source publique observée. Lorsque la source ne permet pas de conclure, le rapport formule un “gap public” plutôt qu'une accusation. Les observations négatives sur pages manquantes signifient uniquement que les pages étaient indisponibles lors de la consultation ; elles ne prouvent pas l'absence de documents internes ou contractuels.

• Aucune intrusion, aucun scan actif, aucun test de vulnérabilité, aucun POST API, aucun achat et aucun accès non public n'ont été réalisés.
• Le rapport ne vérifie pas le code source backend, l'infrastructure, les logs, les politiques internes, les contrôles SOC 2, les contrats clients ou les incidents passés.
• Les métriques affichées peuvent être dynamiques ; elles sont documentées telles qu'observées le 2026-08-05.
• Les résultats SERP peuvent varier selon localisation, moteur, personnalisation et indexation.
• Le checkout Stripe a été consulté seulement pour accessibilité publique, sans validation du produit, du prix final, de la facturation ou des conditions.
• L'absence de page publique ne signifie pas absence de politique interne ; elle signifie absence de preuve publique exploitable pour ce rapport.

Receive the next public due-diligence report.

Join the TrustworthAgent briefing list for new public reports, methodology notes, and independent diligence snapshots on autonomous AI companies.