AI Security

Appel d'outils sécurisé : Protégez vos agents LLM contre les injections et la sur-authorization

Alors que les organisations déploient de plus en plus d'agents de grands modèles de langage (LLM) pour automatiser des workflows complexes, le mécanisme d'appel d'outils (également connu sous le nom d'appel de fonctions) est devenu une surface d'attaque critique. Bien que l'appel d'outils permette aux LLM d'interagir avec des API externes, des bases de données et des services, il introduit des risques de sécurité significatifs s'il n'est pas mis en œuvre avec des garde-fous rigoureux. Cet article explore l'architecture de l'appel d'outils sécurisé, en se concentrant sur les stratégies de défense en profondeur pour les applications IA modernes.

Le risque principal : Injection de prompt indirecte et sur-authorization

Les attaques traditionnelles par injection de prompt ciblent directement les instructions du modèle. Cependant, dans une architecture d'agent, un attaquant peut manipuler la sortie d'un outil pour influencer les appels ultérieurs du modèle. Plus critique encore, si le LLM a accès à des outils trop permissifs (par exemple, une fonction delete_user_account sans validation), il devient un vecteur d'élévation de privilèges. Le modèle lui-même n'est peut-être pas malveillant, mais il peut être contraint d'exécuter des actions à fort impact sur la base d'entrées utilisateur ambiguës.

Pour atténuer ces risques, les développeurs doivent adopter le principe du moindre privilège et mettre en œuvre des couches de validation strictes avant toute exécution d'outil.

Mise en œuvre d'une passerelle de validation

Ne permettez jamais au LLM d'exécuter des outils directement. Traitez plutôt les appels d'outils proposés par le LLM comme des données non fiables. Vous devez mettre en œuvre une passerelle de validation qui vérifie le schéma, les arguments et les autorisations utilisateur avant l'exécution. Voici un exemple Python montrant comment valider les arguments d'outils à l'aide d'une bibliothèque de schéma stricte comme Pydantic.

from pydantic import BaseModel, field_validator
from typing import Optional

class TransferFundsArgs(BaseModel):
    recipient_id: str
    amount: float
    currency: str

    @field_validator('amount')
    @classmethod
    def validate_amount_positive(cls, v):
        if v <= 0:
            raise ValueError("Amount must be positive")
        if v > 10000:
            raise ValueError("Daily transfer limit exceeded")
        return v

def secure_tool_execution(llm_output: dict, user_session: UserSession):
    """
    Validates LLM tool output before execution.
    """
    tool_name = llm_output.get("tool_name")
    args = llm_output.get("arguments")
    
    # 1. Validate Schema
    try:
        validated_args = TransferFundsArgs(**args)
    except Exception as e:
        return {"status": "error", "message": f"Validation failed: {str(e)}"}
    
    # 2. Check User Permissions (Authorization)
    user_balance = user_session.get_balance()
    if validated_args.amount > user_balance:
        return {"status": "error", "message": "Insufficient funds"}
        
    # 3. Execute securely
    execute_transfer(validated_args.recipient_id, validated_args.amount)
    return {"status": "success"}

Assainissement des contextes d'entrée et de sortie

Au-delà de la validation des arguments, le contexte transmis au LLM doit être assaini. Lorsqu'un outil renvoie des données qui seront réinjectées dans le LLM, assurez-vous que les informations sensibles sont supprimées ou masquées. Par exemple, si un outil get_user_profile renvoie des données d'identité (PII - Personally Identifiable Information), le système doit filtrer les numéros de sécurité sociale, les numéros de carte de crédit ou les identifiants internes avant que le LLM ne traite le résultat.

De plus, mettez en œuvre une limitation de débit (rate limiting) et une journalisation pour tous les appels d'outils. Des pics anormaux dans l'utilisation d'outils spécifiques peuvent indiquer un script d'attaque automatisé sondant à la recherche de vulnérabilités.

Conclusion

L'appel d'outils sécurisé n'est pas une option ; c'est une exigence fondamentale pour les agents IA prêts pour la production. En traitant les sorties du LLM comme des données non fiables, en imposant une validation stricte des schémas et en mettant en œuvre des vérifications d'autorisation robustes, les développeurs peuvent débloquer la puissance des workflows agents sans compromettre la sécurité. À mesure que le paysage de l'IA évolue, rester à jour sur les techniques d'injection et maintenir une approche de confiance zéro pour l'accès aux outils sera clé pour construire des systèmes IA résilients.

Share: