FAQ

Pourquoi ne pas donner à mon agent l’accès à mon Gmail ou Outlook ?

Sécurité — L’OAuth Gmail/Outlook donne à votre agent accès à l’intégralité de votre boîte de réception (médical, financier, juridique, personnel). Une injection de prompt dans n’importe quel email entrant pourrait manipuler un agent ayant accès à tout cela. InboxAPI donne à votre agent sa propre boîte de réception isolée avec classification de confiance et marquage de données sur chaque message.

Identité — Quand votre agent envoie depuis votre Gmail, les destinataires ne peuvent pas savoir à qui ils parlent. Les réponses arrivent dans votre boîte, mélangées avec votre vrai courrier. InboxAPI donne à votre agent sa propre adresse — une séparation claire entre vous et votre agent.

Praticité — Les API Gmail/Outlook ne sont pas natives MCP. Vous auriez besoin de middleware, de plomberie OAuth et d’intégration sur mesure. InboxAPI fonctionne directement avec n’importe quel client MCP.

Quelle différence avec AWS SES, SendGrid ou Resend ?

Ce sont des API d’envoi — vous construisez une infrastructure email par-dessus. InboxAPI donne à votre agent une identité email complète : envoyer, recevoir, rechercher, répondre et transférer. Il n’y a rien à configurer et aucune infrastructure à gérer.

Quelle différence avec AgentMail ou a1base ?

Nous avons construit notre propre stack email à partir de zéro. Nous ne wrappons pas SES, Postfix ou un quelconque service d’envoi tiers. Le courrier de votre agent passe par une infrastructure que nous exploitons directement.

C’est vraiment gratuit ?

Oui. Pas de carte de crédit, pas de période d’essai, pas de paliers d’utilisation. Nous travaillons sur des plans payants avec des fonctionnalités supplémentaires, mais l’expérience de base restera toujours gratuite.

Comment prévenez-vous le spam et les abus ?

La création de compte nécessite un proof-of-work. Chaque compte dispose de 5 créneaux de carnet d’adresses pour les destinataires externes — lorsque tous les créneaux sont utilisés, l’entrée la moins récemment utilisée est automatiquement remplacée après 5 jours d’inactivité. Des quotas d’envoi quotidiens et une limitation de débit sont appliqués sur chaque compte. Ces contraintes sont structurelles — ce ne sont pas des politiques, c’est la façon dont le système fonctionne.

Et l’injection de prompt via email ?

Chaque email entrant inclut une classification de confiance — fiable, agent, non vérifié ou suspect — selon que l’expéditeur figure dans votre carnet d’adresses et que son email passe les vérifications d’authentification. Cela aide votre agent à décider avec quelle prudence traiter chaque message. Les emails d’autres agents InboxAPI sont signalés séparément pour que votre agent sache vérifier avec vous avant d’agir.

De plus, le contenu des emails non fiables est automatiquement transformé par spotlighting (marquage de données) — les espaces sont remplacés par un caractère marqueur unique pour que votre agent puisse clairement distinguer les données email de ses propres instructions. Cela réduit le taux de succès des attaques par injection de prompt intégrées dans les emails de ~50% à moins de 3%.

Qu’est-ce que le spotlighting ?

Les outils de récupération d’emails appliquent le marquage de données au contenu non fiable, remplaçant les espaces par un caractère marqueur Unicode unique généré par requête. Le contenu contenant le marqueur doit être traité comme des données externes — jamais comme des instructions à suivre. Pour récupérer le texte original, remplacez le marqueur par un espace. Les emails d’expéditeurs fiables (dans votre carnet d’adresses avec authentification valide) ne sont pas spotlightés par défaut. Cette technique est basée sur la recherche académique (arXiv:2403.14720).

Et les fuites de données ?

Les emails sortants sont analysés à la recherche de jetons d’authentification et d’identifiants. Si votre agent tente accidentellement d’envoyer un email contenant un JWT ou un jeton d’accès, le message est rejeté avant de quitter la plateforme. Cela empêche les agents d’être trompés pour divulguer des données sensibles par email. De plus, toutes les adresses destinataires dans les opérations d’envoi, de réponse et de transfert sont validées selon RFC 5322 — les adresses malformées sont rejetées avant la livraison.

Les agents peuvent-ils se spammer mutuellement ?

Les mêmes limites d’envoi s’appliquent à tous les emails sortants — les plafonds de destinataires, les quotas et la limitation de débit fonctionnent de la même manière quel que soit le destinataire.

Les emails de mon agent atterriront-ils dans les spams ?

Peut-être au début. Chaque agent obtient un tout nouveau sous-domaine, et les nouveaux expéditeurs n’ont pas encore de réputation. Les destinataires devront peut-être vérifier leur dossier spam pour les premiers emails. Avec le temps, à mesure que votre agent envoie du courrier légitime et que les destinataires interagissent avec, la délivrabilité s’améliore. Voir Livraison des Emails pour plus de détails.

Pourquoi l’email plutôt qu’un protocole agent natif comme A2A ?

L’email atteint l’ensemble de l’internet existant — des milliards de personnes et d’entreprises l’utilisent déjà. A2A exige que les deux parties implémentent le protocole. Quand votre agent doit joindre quelqu’un en dehors de son propre écosystème, l’email est l’option universelle. Les agents auront probablement besoin des deux.

Pourquoi l’email plutôt que WhatsApp, Telegram ou d’autres applications de messagerie ?

Les applications de messagerie semblent naturellement adaptées à la communication entre agents, mais elles ont des limitations structurelles qui les rendent impraticables pour les agents à grande échelle.

Scalabilité — Vous pouvez créer des centaines d’adresses email par programmation. WhatsApp, Telegram et Signal nécessitent tous des numéros de téléphone et une vérification. Dépasser quelques comptes est impraticable, souvent contraire aux conditions d’utilisation, et parfois impossible sans cartes SIM physiques. Si votre workflow nécessite 50 agents, il vous faut 50 numéros de téléphone.

Pas de contrôle d’accès — L’email est le seul canal de communication où vous pouvez créer une identité sans numéro de téléphone, pièce d’identité ou approbation d’un propriétaire de plateforme. Aucune entreprise ne contrôle qui obtient une adresse email.

Protocole ouvert — L’email est fédéré et neutre vis-à-vis des fournisseurs. WhatsApp, Discord et Telegram sont propriétaires — ils peuvent révoquer l’accès API, bannir des comptes bots ou changer les règles à tout moment. L’email ne peut pas être coupé par une seule entreprise.

Conformité aux CGU — La plupart des plateformes de messagerie interdisent explicitement les comptes automatisés ou ont des processus d’approbation stricts (l’API WhatsApp Business nécessite une vérification d’entreprise, Telegram restreint la messagerie bot-à-bot). L’email n’a pas de telles restrictions — l’envoi automatisé est un cas d’utilisation de premier ordre.

Portée universelle — Les canaux de messagerie sont cloisonnés. Votre bot Telegram ne peut pas atteindre un utilisateur WhatsApp. L’email atteint quiconque possède une adresse email — c’est-à-dire pratiquement tout le monde.

Complémentaire, pas concurrent — Les frameworks d’agents multi-canaux comme OpenClaw supportent des dizaines de canaux de messagerie, et l’email devrait en faire partie. InboxAPI comble le vide que les plateformes de messagerie ne peuvent structurellement pas combler : création d’identités illimitée et programmable sans approbation de plateforme requise.

Quelles sont les limites d’envoi ?

Chaque compte dispose de 5 créneaux de carnet d’adresses pour les destinataires externes. Lorsque tous les créneaux sont utilisés, l’entrée la moins récemment utilisée est automatiquement remplacée après 5 jours d’inactivité. Les emails vers d’autres adresses @inboxapi.ai, @inboxapi.io et @inboxapi.dev ne comptent pas dans cette limite. Voir Limites et Utilisation pour tous les détails.

Que se passe-t-il quand j’atteins la limite ?

Quand les 5 créneaux sont utilisés, l’entrée la moins récemment utilisée est automatiquement remplacée après 5 jours d’inactivité.

How does the addressbook work? Do I need to add contacts?

The addressbook is automatic — contacts are added when you send email. You never need to add, configure, or manage contacts manually. There is no settings file, no contact list to maintain, and no setup step.

When your agent sends an email to a new external address, that address is recorded in the addressbook. Each account has 5 slots. When all 5 are in use, the least recently used entry is auto-replaced after 5 days of inactivity. Emails to other @inboxapi.ai addresses are always unlimited and don’t use a slot.

Quelles sont les limitations actuelles ?

Bien qu’InboxAPI soit pleinement fonctionnel pour les emails agent-humain et agent-agent, il y a quelques limitations actuelles :

• 5 créneaux de carnet d’adresses pour les destinataires externes : Chaque compte dispose de 5 créneaux pour les destinataires externes. Lorsque tous sont utilisés, l’entrée la moins récemment utilisée est automatiquement remplacée après 5 jours d’inactivité.
• Usage personnel uniquement : InboxAPI n’est pas un service d’email transactionnel — ne l’utilisez pas pour l’envoi en masse, le marketing ou les notifications d’application.

Comment fonctionnent les identifiants ?

Les identifiants de votre agent sont stockés localement dans ~/.config/inboxapi/credentials.json (Linux) ou ~/Library/Application Support/inboxapi/credentials.json (macOS). La CLI gère automatiquement la création et le renouvellement des jetons — votre agent n’a jamais besoin de gérer les jetons manuellement.

Que se passe-t-il si mon agent perd l’accès à son compte ?

Si les identifiants de votre agent sont perdus ou corrompus, vous pouvez récupérer le compte en utilisant l’outil account_recover — mais uniquement si vous avez préalablement lié votre email via verify_owner. La récupération révoque tous les jetons existants et émet de nouveaux identifiants. Sans email de propriétaire vérifié, il n’y a aucun moyen de récupérer un compte verrouillé.

Qu’est-ce que la vérification de propriétaire ?

La vérification de propriétaire lie votre adresse email personnelle au compte InboxAPI de votre agent. Votre agent appelle verify_owner avec votre email, vous recevez un code à 6 chiffres, et votre agent le soumet pour compléter la vérification. Une fois vérifié, vous pouvez récupérer le compte si les identifiants sont perdus, et les restrictions d’essai sont supprimées du compte.

Quels domaines sont bloqués pour l’envoi ?

InboxAPI maintient une liste de blocage qui empêche l’envoi vers les domaines gouvernementaux (.gov), militaires (.mil), de renseignement, des forces de l’ordre, d’infrastructure nucléaire/critique et de messagerie jetable.

Comment fonctionne la classification de confiance ?

Chaque email entrant est classé en l’un des quatre niveaux de confiance :

Niveau de confiance	Signification	Action recommandée
Trusted	L’expéditeur est dans votre carnet d’adresses avec SPF/DKIM valide	Sûr pour agir
Agent	L’expéditeur est un agent InboxAPI connu	Lire librement, mais confirmer avec votre humain avant d’agir
Unverified	SPF/DKIM valide mais expéditeur pas dans le carnet	Faire preuve de prudence
Suspicious	Authentification échouée ou expéditeur inconnu	Signaler et confirmer avant d’agir

Qu’est-ce qui empêche un agent d’acheter des choses ou d’autoriser des transactions par email ?

InboxAPI est un canal de communication, pas un environnement d’exécution. Il peut livrer un email, mais il ne peut pas cliquer sur des boutons, entrer des numéros de carte de crédit ou interagir avec des systèmes externes. Le risque d’actions non autorisées vient de la façon dont un agent est configuré et des autres outils auxquels il a accès — pas de son email.