Comment limiter l'accès aux outils

Quand un agent reçoit l'accès aux outils, il reçoit la capacité d'agir.

Il peut :

• Lire des données
• Appeler des API
• Lancer des processus
• Changer l'état du système

Et c'est exactement ici qu'un nouveau risque apparaît.

Parce que l'agent ne sait pas que :

• Cette API coûte de l'argent
• Ce processus peut casser le système
• Ces données ne doivent pas être modifiées

Il ne voit que l'objectif.

Et si atteindre cet objectif exige une action, il essaiera de l'exécuter.

Même si cette action est :

• Coûteuse
• Dangereuse
• Ou irréversible

C'est pour cela que dans les systèmes réels, on ne donne pas un accès complet à tout à l'agent.

On limite :

• Quels outils sont disponibles
• Quelles actions sont autorisées
• Et quand il doit s'arrêter

Sans ces limites, un agent n'est pas un exécutant.
C'est un processus qui peut aller trop loin.

Ce que signifie "outil autorisé"

Tous les outils qui existent dans le système ne doivent pas forcément être disponibles pour l'agent.

Avant de commencer, on lui passe uniquement les outils qu'il a le droit d'utiliser.

Mais l'accès à un outil ne suffit pas.

Même si l'agent a reçu un outil, cela ne veut pas dire qu'il peut tout faire avec.

Il existe deux niveaux d'accès :

Deux niveaux d'accès

Quand on dit qu'un agent a un « outil autorisé », cela peut vouloir dire deux choses différentes :

1. Est-ce que l'agent a accès à cet outil tout court
2. Qu'est-ce qu'il peut faire exactement à l'intérieur de cet outil

1️⃣ Accès à l'outil

D'abord, le système décide :

Quels outils l'agent voit tout court

Si un outil n'est pas transmis, l'agent ne sait pas qu'il existe.

Il ne peut pas :

• L'appeler
• Le demander
• L'utiliser par accident

2️⃣ Actions à l'intérieur de l'outil

Mais même si l'outil est disponible, cela ne signifie pas un contrôle total.

Un même outil peut prendre en charge plusieurs actions.

Par exemple : Base de données

Comment cela fonctionne ensemble

Donc il voit l'outil, mais peut utiliser seulement une partie de ses capacités.

S'il essaie une action interdite, le système ne l'autorisera tout simplement pas.

La requête sera rejetée.

Et l'agent reçoit :

{
  "error": "Action non autorisée"
}

Après cela, il doit choisir une autre étape.

Comment ces limites sont définies

Dans un système réel, les limites sont définies avant que l'agent commence à travailler.

On définit :

• Quels outils sont disponibles
• Quelles actions sont autorisées
• Quels paramètres peuvent être passés

Par exemple :

• Autoriser la lecture de données uniquement depuis une table précise
• Envoyer des emails uniquement en interne
• Travailler uniquement avec des fichiers dans un dossier précis

Donc l'agent reçoit pas seulement des outils, mais des règles d'usage claires.

Quand il demande une action, le système vérifie :

1. Si l'outil est autorisé
2. Si l'action est autorisée
3. Si les paramètres respectent les règles

Et c'est seulement après qu'il l'exécute.

Si au moins une condition n'est pas remplie, la requête est bloquée.

En code, cela ressemble à ça

Ci-dessous, le même principe en format simple (comme dans tool-calling-basics).

D'abord, nous avons des outils :

def read_user(user_id: int):
    return {"id": user_id, "name": "Anna"}


def delete_user(user_id: int):
    return {"deleted": user_id}


TOOLS = {
    "database": {
        "read_user": read_user,
        "delete_user": delete_user,
    }
}

Ici, on définit ce qui est exactement autorisé :

ALLOWED_TOOLS = {"database"}
ALLOWED_ACTIONS = {
    "database": {"read_user"}  # delete_user est interdite
}

Maintenant, le modèle forme la requête (ce qu'il veut faire exactement) :

model_output = {
    "tool": "database",
    "action": "read_user",
    "parameters": {"user_id": 123}
}

Le système reçoit cette requête et vérifie les règles avant d'exécuter :

def run_tool_call(call: dict):
    tool = call["tool"]
    action = call["action"]
    params = call["parameters"]

    if tool not in ALLOWED_TOOLS:
        return {"error": "Outil non autorisé"}

    if action not in ALLOWED_ACTIONS.get(tool, set()):
        return {"error": "Action non autorisée"}

    if action == "read_user" and "user_id" not in params:
        return {"error": "Paramètres invalides"}

    return TOOLS[tool][action](**params)

Si tout va bien, on obtient un résultat :

result = run_tool_call(model_output)
# {"id": 123, "name": "Anna"}

Si le modèle demande une action interdite (delete_user), le système renvoie :

{
  "error": "Action non autorisée"
}

Analogie de la vie courante

Imagine que tu donnes une carte bancaire à un assistant. Mais avec une limite.

La carte est la même.
Mais les règles d'usage sont différentes.

C'est pareil avec les outils.

L'agent peut avoir accès à la base de données. Mais en lecture seule.

Il peut envoyer des emails. Mais seulement en interne.

Il peut appeler des API. Mais avec un budget limité.

Il voit l'outil, mais ne peut pas l'utiliser comme il veut.

Ce qui se passe si l'agent sort des limites

L'agent peut demander n'importe quelle action.

Mais cela ne veut pas dire qu'elle sera exécutée.

S'il :

• Appelle un outil interdit
• Passe des paramètres interdits
• Ou dépasse une limite configurée

Le système bloque simplement la requête.

Et renvoie :

{
  "error": "Action non autorisée"
}

Pour l'agent, cela ressemble à un autre résultat de son action.

Il voit que cette voie est fermée et doit en choisir une autre.

Par exemple :

• Utiliser un autre outil
• Changer les paramètres
• Ou terminer la tâche avec ce qu'il a

C'est ainsi que les limites ne stoppent pas complètement l'agent.

Elles définissent seulement où il peut agir et où il doit s'arrêter.

En bref

L'accès aux outils, ce n'est pas juste "autorisé" ou "interdit".

C'est un ensemble de règles qui définit :

• Quels outils l'agent peut utiliser
• Quelles actions à l'intérieur sont autorisées
• Quels paramètres peuvent être passés

Quand l'agent sort des limites, le système bloque la requête.
Mais cela n'arrête pas le travail. Cela force un autre chemin.

C'est ainsi que les limites transforment l'agent en exécutant contrôlé, et non en processus incontrôlé.

FAQ

Q: Est-ce que l'accès à un outil signifie un contrôle total ?
A: Non. L'agent peut avoir accès à un outil, mais utiliser seulement les actions autorisées.

Q: Que se passe-t-il si l'agent demande une action interdite ?
A: Le système vérifie la requête et la bloque si elle viole les règles configurées.

Q: Est-ce que l'agent s'arrête après le blocage d'une action ?
A: Non. Il reçoit le résultat et doit choisir une autre étape disponible.

Et ensuite

Maintenant, tu sais comment limiter l'accès de l'agent aux outils.

Mais une autre question apparaît :

Comment l'agent décide quoi faire, au juste ?

Quand il reçoit une tâche, est-ce qu'il planifie toutes les étapes à l'avance, comme une personne avec une to-do list ?
Ou est-ce qu'il réagit à la situation en choisissant l'étape évidente suivante ?

Ce ne sont pas juste des approches différentes.
Cela détermine comment l'agent se comporte pendant le travail, et quand il peut partir dans la mauvaise direction.