Ton assistant IA peut répondre à un inconnu. Tu le laisses faire ? Your AI assistant can reply to a stranger. Do you let it?

28 septembre 2026 · ~5 min de lecture · Jules Robineau 28 September 2026 · ~5 min read · Jules Robineau

Depuis des mois, un agent lit ma boîte mail. Un agent, c'est un programme piloté par un modèle de langage, et qui peut agir : lire, trier, écrire. Le mien s'occupe des propositions de mission. Il les trie, il les évalue, il rédige les réponses.

Reste une question : qui appuie sur envoyer ?

TL;DR : mon agent lit tout et rédige tout, sans me demander. Mais pour envoyer, chaque type de réponse a sa règle. Une question simple part toute seule, deux fois maximum, avec un délai. Un refus attend toujours mon clic. Une mission sérieuse revient toujours vers moi. Et ces règles vivent dans le code : aucun prompt ne peut les changer.

Cet article est pour les devs qui veulent brancher un agent sur leur messagerie sans lui donner leur signature.

OpenClaw a rendu la question concrète

OpenClaw, c'est l'assistant IA open source qui a explosé cette année. Il tourne chez toi. Il lit tes messages. Et il peut y répondre à ta place.

La sécurité n'a pas suivi. Censys a compté 21 639 instances ouvertes sur internet. Le marketplace d'extensions a hébergé plus d'un millier de paquets malveillants. Krebs on Security en a fait une enquête.

Ces failles-là se corrigent avec des patchs. Mais une question reste, même tout patché : tu laisses une machine parler en ton nom à un inconnu ?

Moi, je vis avec cette question. Mon agent tourne en production, sur ma vraie boîte. Voici les règles que je lui ai données, et pourquoi.

Le vrai risque, c'est ce qui sort

Quand l'agent lit, je risque mes données. C'est sérieux, mais ça se maîtrise : il tourne en local, avec le minimum d'accès.

Quand l'agent écrit à un inconnu, je risque mon nom. Un brouillon raté se corrige en deux secondes. Un mail raté, parti chez un prospect, ne s'efface plus.

Donc ma règle ne porte pas sur ce que l'agent sait faire. Elle porte sur ce qui sort.

Ce que l'agent fait tout seul

Toute la lecture et toute la préparation tournent sans moi.

D'abord, un filtre tout bête. L'email doit contenir au moins deux mots du monde des missions. Pas d'IA ici : une liste de mots, rapide et prévisible. Les newsletters s'arrêtent là.

Ensuite, un modèle local lit le mail. Il remplit une grille de cinq critères : stack, type de contrat, date de démarrage, tarif, télétravail. Chaque critère reçoit un verdict : GO, NO_GO ou inconnu.

Enfin, un modèle cloud rédige une réponse dans mon style. Résultat : un brouillon. Rien d'autre.

Je ne relis aucune de ces étapes. Si l'agent se trompe ici, ça ne coûte rien. Rien n'est parti.

Ce qu'il envoie seul, et ce qu'il n'enverra jamais

Au moment de répondre, l'agent choisit une action. Chaque action a sa propre règle d'envoi. C'est un switch en Go, pas une humeur du modèle.

Il manque le tarif ou le télétravail ? L'agent pose la question, et il l'envoie tout seul. Une question simple n'engage rien.

Refuser une mission ? Jamais tout seul. Un refus ferme une porte, avec mon nom en bas. Le brouillon attend mon clic. Dans le code, l'envoi automatique est interdit en dur pour cette action.

Envoyer mon dossier de compétences ? Jamais tout seul non plus.

Et quand une mission coche au moins trois critères sur cinq, sans aucun NO_GO ? L'agent arrête de répondre. Il me résume le fil et me passe la main.

Regarde bien la logique. Plus la conversation devient sérieuse, moins l'agent a de droits. Jamais l'inverse.

Deux garde-fous, même sur les questions simples

Même l'envoi automatique des questions garde deux limites.

Un plafond : deux envois automatiques par conversation. C'est un compteur dans le code, pas une promesse dans le prompt. Au troisième échange, tout redevient brouillon. Une boucle avec un inconnu doit s'arrêter toute seule.

Un délai : chaque envoi attend entre deux et six heures, au hasard. La réponse a l'air humaine. Et pendant l'attente, le brouillon reste visible dans ma boîte. Je le supprime, l'envoi échoue. Ce délai, c'est mon droit de veto.

Les règles vivent dans le code, pas dans le prompt

Mon agent démarre dans un mode, choisi par un flag : draft, hybrid ou review. En draft, rien ne part jamais. En hybrid, seules les questions simples partent seules. En review, tout attend ma validation.

Le prompt ne décide rien là-dedans. C'est le point le plus important de cet article.

Pourquoi ? À cause de l'injection de prompt. Un email piégé peut convaincre un modèle de changer d'avis. Il ne peut pas changer un flag compilé.

J'ai déjà testé cette philosophie sur les permissions : mon agent a tenté de supprimer mes secrets, il n'a pas pu. L'envoi suit la même règle. Elle s'impose en dehors du modèle.

Et quand je veux tout valider : le mode review

Parfois je veux zéro envoi automatique. Je passe en mode review.

Chaque réponse arrive alors dans une petite interface web, chez moi, jamais exposée sur internet. Trois boutons : valider, corriger, rejeter. Si je rejette, j'explique en une phrase, et l'agent réécrit le brouillon avec mon retour. Chaque décision part dans un journal, pour réentraîner plus tard.

Pour LinkedIn, je vais encore plus loin. Une extension colle la réponse dans le champ de message. Elle n'envoie jamais. Le clic final reste à moi, physiquement.

La checklist pour ton agent

Une règle par type d'action, jamais par conversation.

Liste ce que ton agent peut faire, action par action
Pour chaque action, trois questions : réversible ? mon nom ? un inconnu ?
Laisse la lecture et la préparation tourner sans validation
N'autorise l'envoi seul que pour les questions simples, avec un plafond
Ajoute un délai avant chaque envoi auto : c'est ton droit de veto
Mets les règles dans le code, flag ou switch, jamais dans le prompt
Garde une trace de chaque décision, pour relire plus tard
Garde l'interface de validation en local, loin d'internet

Ce qu'il faut retenir

Alors, tu le laisses faire ? Lire, trier, préparer : oui, à fond. Parler à des inconnus : chaque action a sa règle, avec un plafond, un délai, et un mode où tout passe par toi.

OpenClaw n'a pas créé ce problème. Il l'a mis à l'échelle. La liberté de ton agent est une décision d'architecture, pas une ligne de prompt.

Tu veux brancher un agent sur ta messagerie sans lui donner ta signature ? Parlons-en.

For months, an agent has been reading my inbox. An agent is a program driven by a language model, and it can act: read, sort, write. Mine handles mission proposals. It sorts them, evaluates them, and drafts the replies.

One question remains: who presses send?

TL;DR: my agent reads everything and drafts everything, without asking me. But for sending, each type of reply has its own rule. A simple question goes out alone, twice at most, with a delay. A refusal always waits for my click. A serious mission always comes back to me. And these rules live in code: no prompt can change them.

This article is for developers who want to wire an agent into their inbox without handing it their signature.

OpenClaw made the question concrete

OpenClaw is the open source AI assistant that blew up this year. It runs on your machine. It reads your messages. And it can answer them for you.

Security did not keep up. Censys counted 21,639 instances open on the internet. The extension marketplace hosted over a thousand malicious packages. Krebs on Security ran an investigation.

Those flaws get fixed with patches. But one question survives, even fully patched: do you let a machine talk to a stranger in your name?

I live with that question. My agent runs in production, on my real inbox. Here are the rules I gave it, and why.

The real risk is what leaves

When the agent reads, I risk my data. That is serious, but manageable: it runs locally, with minimal access.

When the agent writes to a stranger, I risk my name. A bad draft takes two seconds to fix. A bad email, sent to a prospect, cannot be erased.

So my rule is not about what the agent can do. It is about what leaves.

What the agent does on its own

All the reading and all the preparation run without me.

First, a dumb filter. The email must contain at least two words from the mission world. No AI here: a word list, fast and predictable. Newsletters stop there.

Then a local model reads the email. It fills a five-criteria grid: stack, contract type, start date, rate, remote policy. Each criterion gets a verdict: GO, NO_GO or unknown.

Finally, a cloud model drafts a reply in my style. The result: a draft. Nothing else.

I review none of these steps. If the agent gets something wrong here, it costs nothing. Nothing has left.

What it sends alone, and what it never will

When it is time to reply, the agent picks an action. Each action has its own sending rule. It is a Go switch, not a model mood.

The rate or remote policy is missing? The agent asks, and sends it alone. A simple question commits nothing.

Declining a mission? Never alone. A refusal closes a door, with my name at the bottom. The draft waits for my click. In the code, auto-send is hardcoded off for that action.

Sending my skills file? Never alone either.

And when a mission checks at least three criteria out of five, with zero NO_GO? The agent stops replying. It summarizes the thread and hands it back to me.

Look at the logic. The more serious the conversation gets, the fewer rights the agent has. Never the other way around.

Two guardrails, even on simple questions

Even the automatic sending of questions keeps two limits.

A cap: two automatic sends per conversation. It is a counter in code, not a promise in a prompt. On the third exchange, everything becomes a draft again. A loop with a stranger must stop on its own.

A delay: each send waits between two and six hours, at random. The reply looks human. And while it waits, the draft sits visible in my mailbox. I delete it, the send fails. That delay is my veto right.

The rules live in code, not in the prompt

My agent starts in a mode, picked by a flag: draft, hybrid or review. In draft, nothing ever leaves. In hybrid, only simple questions leave alone. In review, everything waits for my approval.

The prompt decides none of this. That is the most important point in this article.

Why? Because of prompt injection. A booby-trapped email can talk a model into changing its mind. It cannot change a compiled flag.

I already tested this philosophy on permissions: my AI agent tried to delete my secrets, it could not. Sending follows the same rule. It is enforced outside the model.

And when I want to approve everything: review mode

Sometimes I want zero automatic sending. I switch to review mode.

Every reply then lands in a small web interface, at home, never exposed to the internet. Three buttons: approve, edit, reject. If I reject, I explain in one sentence, and the agent rewrites the draft with my feedback. Every decision goes to a log, for retraining later.

For LinkedIn, I go even further. An extension pastes the reply into the message box. It never sends. The final click stays mine, physically.

The checklist for your agent

One rule per type of action, never per conversation.

List what your agent can do, action by action
For each action, three questions: reversible? my name? a stranger?
Let reading and preparation run without validation
Allow solo sending only for simple questions, with a cap
Add a delay before every auto-send: that is your veto right
Put the rules in code, a flag or a switch, never in the prompt
Keep a trace of every decision, to reread later
Keep the approval interface local, away from the internet

What to remember

So, do you let it? Reading, sorting, preparing: yes, fully. Talking to strangers: each action has its rule, with a cap, a delay, and a mode where everything goes through you.

OpenClaw did not create this problem. It scaled it. Your agent's freedom is an architecture decision, not a prompt line.

Want to wire an agent into your inbox without handing it your signature? Let's talk.

Jules Robineau, développeur Go senior & DevSecOps freelance (Paris). Je construis et durcis des systèmes IA/backend en production, à l'échelle (25M+ utilisateurs). Certifié CompTIA PenTest+, Top 1% TryHackMe. Jules Robineau, senior Go backend & DevSecOps freelancer (Paris). I build and harden production AI/backend systems at scale (25M+ users). CompTIA PenTest+, Top 1% TryHackMe. → Services · GitHub · LinkedIn

Sources : Krebs on Security, « How AI Assistants Are Moving the Security Goalposts » · Reco, « OpenClaw: The AI Agent Security Crisis » · Palo Alto Networks, sur l'identité des agents autonomes

Sources: Krebs on Security, "How AI Assistants Are Moving the Security Goalposts" · Reco, "OpenClaw: The AI Agent Security Crisis" · Palo Alto Networks, on autonomous agent identity