Sandbox d’agent IA et autorisations Android : trois limites à vérifier
Comprendre la différence entre sandbox d’agent IA, autorisations Android et validation d’action, avec un exemple de brouillon relu sur téléphone.
- Un sandbox d’agent IA limite l’environnement d’exécution, mais il ne décide pas à lui seul quels fichiers, réseaux ou données l’agent peut utiliser.
- Android possède déjà son propre isolement d’apps et ses autorisations ; ces permissions donnent un accès système, pas une validation du destinataire ou du contenu d’une action.
- FoneClaw intervient dans la couche téléphone : lire l’état visible, agir dans les champs pris en charge et appliquer la politique de validation configurée pour les actions sensibles.
- Pour transformer une analyse distante en brouillon Android, transférez seulement le texte utile, vérifiez le destinataire et le contenu, puis traitez l’envoi comme une décision séparée.
Trois protections répondent à trois questions
Un sandbox d’agent IA et les autorisations Android ne protègent pas la même chose. Le sandbox encadre l’endroit où un agent exécute du code ou manipule des fichiers. Android isole déjà les apps sur le téléphone et contrôle les accès sensibles. La validation d’action, elle, décide si une étape concrète doit être confirmée avant de toucher un message, un champ ou une autre donnée visible.
Chez FoneClaw, notre rôle se situe dans cette couche téléphone : utiliser l’état visible de l’écran, exécuter les actions Android prises en charge et appliquer la politique de validation configurée. Les validations dépendent à la fois des réglages globaux et de la politique de chaque outil ; pour les actions conséquentes, configurez une validation obligatoire.
| Couche | Ce qu’elle contrôle | Ce qu’elle ne valide pas | À vérifier |
|---|---|---|---|
| Sandbox d’agent | Processus, fichiers mappés, réseau autorisé, état de travail. | Le destinataire d’un SMS ou la pertinence d’une action Android. | Fichiers accessibles, sorties réseau, secrets et logs. |
| Android | Isolement des apps, permissions d’accès aux données et actions restreintes. | Le sens métier d’un message ou d’un paiement. | Permission nécessaire, app concernée et état visible. |
| Validation d’action | Moment où l’utilisateur relit, approuve ou reprend la main. | La sécurité complète du runtime distant. | Destinataire, contenu, résultat et politique de validation. |
Pour les contrôles au niveau d’une compétence ou d’une action, notre guide Sécurité des compétences d’agents IA : pourquoi les permissions sur mobile doivent être vérifiées au moment de l’action détaille cette vérification au plus près de l’usage.
Un sandbox a encore besoin de limites fichiers et réseau
Un sandbox réduit le contact direct entre une charge de travail et l’hôte. La documentation de gVisor sur son modèle de sécurité décrit par exemple une frontière supplémentaire entre des applications sandboxées et le noyau hôte. C’est une protection importante pour des agents capables d’exécuter du code ou de traiter des fichiers.
Mais l’isolement ne signifie pas absence d’accès. Une application sandboxée peut encore utiliser les fichiers qui lui sont montés et les ressources réseau autorisées. La politique autour des fichiers, des secrets, d’Internet et des services externes reste donc déterminante. Un agent peut être bien isolé tout en ayant accès à un document sensible ou à une sortie réseau configurée.
Cette nuance compte pour les workflows IA : un sandbox répond à la question “où l’agent travaille-t-il et comment l’hôte est-il protégé ?”. Il ne répond pas seul à “quelles données faut-il partager ?”. Pour comparer contrôle local et traitement distant, Confiance dans un agent IA : contrôle local Android ou sécurité cloud ? aide à séparer lieu d’exécution, données envoyées et action finale.
Accès Android et validation d’action sont séparés
Android apporte une autre protection. La page Android sur le sandbox applicatif explique que les apps sont isolées à l’aide d’identifiants utilisateur Linux et de processus distincts, avec application au niveau du noyau. Les apps ne peuvent normalement pas lire les données privées des autres apps sans mécanisme de partage autorisé.
Les autorisations Android répondent ensuite à la question de l’accès. La documentation Android sur les permissions distingue les permissions au moment de l’installation, les permissions à l’exécution et les permissions spéciales. Elles protègent des données et actions restreintes, et doivent être demandées au bon moment, pour un besoin réel.
Autoriser un accès n’est pas la même chose qu’approuver une action précise. Une permission peut permettre à une app de lire une donnée ou d’interagir avec une surface Android, mais elle ne confirme pas que le bon destinataire est choisi, que le texte est exact ou qu’une action externe doit être réalisée. Pour cette raison, FoneClaw sépare l’accès système, l’état visible de l’écran et la validation configurée pour les actions qui comptent.
Transformer une analyse en brouillon relu sur téléphone
Voici un workflow illustratif, volontairement simple. Vous utilisez un agent distant pour analyser un rapport non sensible, puis vous voulez envoyer une courte mise à jour depuis votre téléphone Android. La bonne méthode n’est pas de supposer un passage automatique du sandbox vers l’app de messagerie. Elle consiste à transférer seulement le résumé utile, choisir le destinataire sur le téléphone, relire le contenu et traiter l’envoi comme une décision séparée.
Exemple : l’analyse distante conclut que la livraison de pièces pour le client Nadia est repoussée à vendredi matin. Vous copiez le texte utile : “Les pièces arriveront vendredi matin ; je vous confirme le créneau dès réception.” Sur Android, FoneClaw peut aider si l’app est accessible et si le champ éditable visible est pris en charge. Nous pouvons lire l’état visible, identifier le champ actuel, puis entrer le brouillon dans ce champ. Cette saisie n’envoie pas le message, n’appuie pas sur Entrée et ne remplace pas la relecture.
- Gardez l’analyse distante dans son environnement et extrayez seulement les phrases nécessaires.
- Ouvrez ou sélectionnez la conversation du bon destinataire sur Android.
- Demandez un brouillon ou un placement dans le champ visible pris en charge.
- Relisez le nom, le texte, la date, les promesses et les pièces jointes éventuelles.
- Envoyez uniquement si vous décidez que le contenu et la destination sont corrects.
La qualité et la confidentialité dépendent aussi du modèle configuré. Un modèle en ligne peut traiter le contexte fourni pour la tâche. L’exécution sur téléphone ne prouve donc pas que tout le raisonnement reste local. La page Contrôler un téléphone Android avec un agent IA : intention, confirmation et vérification explique cette séparation entre intention, action prise en charge et résultat visible.
Récupérer sans répéter une action incertaine
La récupération doit respecter la couche où l’échec s’est produit. Si une permission Android est refusée, la bonne suite est de revoir le besoin et l’autorisation, pas d’essayer une autre action sensible. Si l’écran a changé, il faut relire l’état visible avant de toucher un champ. Si le résultat d’un envoi est incertain, inspectez l’app réelle avant de recommencer.
| Incident | Bonne récupération | À éviter |
|---|---|---|
| Permission refusée | Expliquer l’action bloquée et demander l’accès seulement s’il est nécessaire. | Contourner la permission par une autre surface. |
| Écran changé | Relire l’écran et vérifier le champ ou le destinataire actuel. | Réutiliser un ancien état visible. |
| Envoi incertain | Ouvrir la conversation ou l’app et vérifier le résultat. | Renvoyer le même message sans inspection. |
| Sandbox restauré | Reprendre l’analyse ou le brouillon dans l’environnement de travail. | Supposer qu’un effet externe déjà produit est annulé. |
Un checkpoint de runtime peut restaurer l’état de travail d’un agent. Il ne retire pas un message déjà parti ni une action externe déjà visible dans une app. Pour une méthode plus détaillée, consultez Diagnostiquer et récupérer un agent IA mobile : runbook Android pour échecs, permissions et relance d’outil.
Demander des preuves à chaque couche
Avant de faire confiance à un agent qui analyse à distance puis agit sur mobile, demandez des preuves séparées. Côté runtime : quels fichiers sont montés, quelles sorties réseau existent, où vont les secrets et quels journaux sont disponibles ? Côté Android : quelles permissions sont demandées, quelle app est visible, quel champ ou écran est utilisé ? Côté validation : quelle action exige une approbation, quel résultat est vérifié et quelle récupération existe en cas d’incertitude ?
Cette lecture évite de confondre isolation technique et autorité utilisateur. Un sandbox protège le travail de l’agent. Android encadre l’accès au téléphone. FoneClaw apporte des actions Android prises en charge avec état visible, saisie contrôlée et politiques d’approbation configurables. La page Fonctionnalités FoneClaw présente nos capacités Android actuelles.