Comment tester les agents IA appelant vos APIs sans perte de données

Un agent de codage IA a exécuté un script, l’a vu réussir, puis a vu une table de base de données de production disparaître. Le post-mortem Hacker News est devenu viral avec une idée simple : « L’IA n’a pas supprimé votre base de données, vous l’avez fait. » L’agent a suivi une définition d’outil, l’outil a appelé un vrai point d’accès, l’API n’avait pas de garde-fous, et un humain avait donné les clés à un processus qui ne s’arrête pas pour demander si DELETE FROM users est suspect. Même schéma dans un fil r/ClaudeAI : un agent en boucle de facturation a consommé des centaines d’euros en jetons avant que quelqu’un ne s’en aperçoive. Surface différente, même cause racine : personne n’avait testé l’API.

Essayez Apidog dès aujourd’hui

💡 Si vous déployez des agents autonomes qui appellent vos API, ce guide est pour vous. Vous allez mettre en place des maquettes pour les points d’accès externes, isoler les opérations destructrices, écrire des tests de contrat pour les schémas d’outils, définir des budgets par agent et rejouer les scénarios de panne avant la production. Nous utiliserons Apidog pour l’échafaudage de test, car il prend en charge OpenAPI, génère des serveurs de maquette sans code d’assemblage et permet d’exécuter des scénarios qui correspondent aux séquences d’appels d’outils d’un agent.

TL;DR

Les agents échouent en production quand leurs outils appellent des API sans garde-fous : limites de débit absentes, pas d’idempotence, suppressions directes, schémas cassés. La correction tient en quatre actions :

1. tester les définitions d’outils par rapport à votre spécification OpenAPI ;
2. exécuter un serveur de maquette pour les points d’accès destructeurs ;
3. imposer des budgets par agent et des clés d’idempotence ;
4. rejouer les scénarios de défaillance en CI.

Apidog permet de centraliser l’import OpenAPI, les maquettes et l’exécution de scénarios dans un seul projet.

Introduction

Il y a un an, « tester un agent IA » signifiait souvent envoyer un prompt à Claude ou GPT et juger la réponse. Ce n’est plus suffisant.

Les agents actuels appellent des fonctions. Ces fonctions appellent vos API. Vos API touchent des bases de données, des processeurs de paiement, des CRM, des systèmes de notification et des services tiers. Une mauvaise définition d’outil ou une limite de débit manquante n’est plus un détail d’implémentation : c’est un incident de production.

Le point important : la couche modèle n’est pas celle où vous stoppez la plupart des dégâts. La couche API l’est.

Dans cet article, vous allez construire un flux de test agent-API basé sur quatre garde-fous :

• contrats de schéma entre outils et OpenAPI ;
• maquettes pour les points d’accès destructeurs ;
• idempotence et suppressions logiques ;
• budgets par agent.

Vous verrez aussi comment mettre ce flux en place dans Apidog, puis l’exécuter dans votre pipeline CI.

Pourquoi les échecs des agents ressemblent à des échecs d’API

Lisez plusieurs post-mortems d’agents IA et un motif apparaît : le modèle n’est généralement pas le protagoniste. L’API l’est.

Injection de prompt

Un utilisateur télécharge un PDF avec des instructions cachées. L’agent le lit. L’appel d’outil suivant part vers /admin/users avec delete_all=true.

Le modèle n’a pas « décidé » de supprimer les utilisateurs. Il a suivi des instructions qu’il n’avait aucune raison technique de rejeter.

La correction n’est pas seulement un meilleur prompt. La correction consiste à ne jamais exposer delete_all=true à un jeton issu d’une session utilisateur standard. L’autorisation doit être appliquée côté API, avec le contexte utilisateur réel.

Dérive de schéma

Votre spécification OpenAPI dit que amount est un entier en cents.

La définition d’outil de l’agent dit que amount est un nombre flottant en dollars.

Trois mois plus tard, un remboursement de 19 cents devient 19 dollars. Le modèle n’a pas inventé l’erreur : il a utilisé le schéma que vous lui avez fourni.

Il fallait tester le contrat.

Boucles de réessai

Un agent tente d’envoyer un e-mail transactionnel. L’appel échoue. Le planificateur réessaie. Puis réessaie encore. En deux minutes, votre API d’e-mail est appelée mille fois.

Chaque réessai coûte de l’argent. Chaque réessai peut déclencher un vrai message. Sans limite de débit et sans budget, l’agent peut transformer une erreur transitoire en incident client.

Absence d’idempotence

L’agent appelle POST /payments. Le réseau time out. Il réessaie. Le premier appel avait pourtant réussi.

Résultat : double facturation.

L’agent ne peut pas savoir si l’appel initial a abouti si l’API ne lui donne aucun mécanisme pour le vérifier. Une clé d’idempotence règle ce problème côté serveur.

Le fil conducteur est simple : l’agent fait ce que ses outils lui permettent de faire. Les outils sont votre API. Donc, commencez l’audit par le contrat API, puis par le harnais de l’agent, et seulement ensuite par le modèle.

Les quatre garde-fous essentiels à toute intégration agent-API

1. Tester les contrats de schéma des outils

Votre spécification OpenAPI est la source de vérité. Votre agent utilise souvent une définition d’outil séparée, parfois copiée depuis la documentation ou écrite à la main.

Ces deux artefacts dérivent.

Ajoutez un test de contrat qui échoue dès que la définition d’outil ne correspond plus au schéma OpenAPI.

Exemple minimal en Python pour valider une définition d’outil de style Claude contre une spécification OpenAPI :

import json
from jsonschema import Draft202012Validator

def validate_tool_against_openapi(tool_def: dict, openapi_spec: dict) -> list[str]:
    """Return a list of mismatch errors, empty list = pass."""
    errors = []

    op = openapi_spec["paths"][tool_def["path"]][tool_def["method"].lower()]
    api_schema = op["requestBody"]["content"]["application/json"]["schema"]
    tool_schema = tool_def["input_schema"]

    api_props = set(api_schema.get("properties", {}).keys())
    tool_props = set(tool_schema.get("properties", {}).keys())

    for missing in api_props - tool_props:
        if missing in api_schema.get("required", []):
            errors.append(f"Tool missing required field: {missing}")

    for extra in tool_props - api_props:
        errors.append(f"Tool defines field not in API: {extra}")

    for prop, api_def in api_schema.get("properties", {}).items():
        if prop in tool_schema.get("properties", {}):
            tool_def_prop = tool_schema["properties"][prop]

            if api_def.get("type") != tool_def_prop.get("type"):
                errors.append(
                    f"Type mismatch on {prop}: "
                    f"API={api_def.get('type')} "
                    f"tool={tool_def_prop.get('type')}"
                )

    return errors

À intégrer dans votre CI :

python scripts/validate_agent_tools.py

Règle pratique : toute PR qui modifie OpenAPI ou les définitions d’outils doit exécuter ce test. Si la liste d’erreurs n’est pas vide, le build échoue.

2. Utiliser des maquettes pour les points d’accès destructeurs

Un agent ne doit jamais apprendre en production.

Pour chaque point d’accès qui modifie l’état, fournissez un équivalent de maquette :

• POST /payments
• DELETE /users/{id}
• PATCH /subscriptions/{id}
• POST /notifications
• PUT /accounts/{id}

Pendant le développement, l’agent appelle le serveur de maquette. En staging, il appelle une base de données bac à sable. En production, il n’obtient l’accès qu’après validation.

Apidog génère des maquettes directement depuis la spécification OpenAPI, avec des valeurs réalistes basées sur le schéma. Vous pointez l’URL de base de l’agent vers le serveur de maquette et vous observez les appels qu’il produit.

Si l’agent tente un PUT /users/{id}/delete parce qu’il a mal interprété la documentation, vous le voyez dans les traces. La base de production ne reçoit rien.

Voir aussi le guide sur le développement contract-first.

3. Ajouter idempotence et suppressions logiques

Tout point d’accès en écriture appelé par un agent devrait accepter une clé d’idempotence.

Toute suppression devrait être logique par défaut. La suppression physique doit passer par un chemin distinct, idéalement avec validation humaine.

Exemple de middleware Express :

const idempotencyCache = new Map();

function idempotency(req, res, next) {
  const key = req.headers['idempotency-key'];

  if (!key) {
    return res.status(400).json({
      error: 'Missing Idempotency-Key header'
    });
  }

  if (idempotencyCache.has(key)) {
    const cached = idempotencyCache.get(key);
    return res.status(cached.status).json(cached.body);
  }

  const originalJson = res.json.bind(res);

  res.json = function (body) {
    idempotencyCache.set(key, {
      status: res.statusCode,
      body
    });

    setTimeout(() => {
      idempotencyCache.delete(key);
    }, 24 * 60 * 60 * 1000);

    return originalJson(body);
  };

  next();
}

app.post('/payments', idempotency, createPayment);

Côté agent, générez un UUID par opération logique :

const operationId = crypto.randomUUID();

await fetch(`${API_BASE_URL}/payments`, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Idempotency-Key': operationId
  },
  body: JSON.stringify({
    customer_id: 'cus_123',
    amount: 1999,
    currency: 'eur'
  })
});

Si l’agent réessaie après un timeout, il réutilise la même clé. L’API renvoie la réponse mise en cache au lieu de créer un deuxième paiement.

Ce modèle s’applique aussi aux e-mails, aux créations CRM, aux mises à jour de tickets et à toute écriture non triviale.

4. Définir des plafonds budgétaires par agent

Chaque agent doit avoir un budget explicite :

• budget de jetons ;
• nombre d’appels API ;
• coût maximum ;
• durée maximale ;
• profondeur maximale d’appels d’outils.

Exemple de politique :

agent_budget:
  max_tokens_per_session: 50000
  max_api_calls_per_minute: 30
  max_cost_cents_per_task: 500
  max_tool_call_depth: 10
  max_runtime_seconds: 300

Quand un plafond est atteint, l’API ou la passerelle doit échouer en mode fermé :

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-Budget-Exceeded: max_api_calls_per_minute
Content-Type: application/json

Réponse :

{
  "error": "budget_exceeded",
  "limit": "max_api_calls_per_minute",
  "action": "escalate_to_human"
}

Le planificateur de l’agent peut alors remonter le problème à un humain ou annuler la tâche.

Ces quatre contrôles se renforcent :

• les tests de contrat détectent les erreurs de schéma ;
• les maquettes isolent les opérations destructrices ;
• l’idempotence bloque les doubles écritures ;
• les budgets arrêtent les boucles incontrôlées.

L’objectif est de transformer « l’agent a fait quelque chose de terrible » en « l’agent a reçu un 429, a journalisé le problème et a demandé de l’aide ».

Tester les appels API d’agents avec Apidog

Voici un flux de travail concret dans Apidog.

Vous aurez besoin de :

• votre spécification OpenAPI ;
• les définitions d’outils de l’agent ;
• une liste des points d’accès destructeurs ;
• un environnement de test ou de maquette.

Étape 1 : importer la spécification OpenAPI

Dans Apidog :

1. créez un nouveau projet ;
2. importez votre fichier OpenAPI 3.x ;
3. vérifiez que les chemins, méthodes, schémas et exemples sont correctement détectés ;
4. corrigez les champs manquants ou ambigus.

Si votre API n’est pas encore décrite avec OpenAPI, commencez par là. La fiabilité de l’agent dépend d’une source de vérité que les humains, les tests et les outils peuvent lire.

Le guide du workflow API axé sur la conception détaille cette approche.

Étape 2 : créer des réponses de maquette pour les écritures

Identifiez tous les points d’accès qui modifient l’état :

• POST
• PUT
• PATCH
• DELETE

Pour chacun :

1. ouvrez le point d’accès dans Apidog ;
2. ajoutez une réponse de maquette ;
3. générez une réponse depuis le schéma ;
4. remplacez les valeurs par des données clairement fictives.

Exemples de conventions utiles :

{
  "id": "mock_user_1970_001",
  "email": "mock_user@example.test",
  "created_at": "1970-01-01T00:00:00.000Z",
  "status": "mock_active"
}

Utilisez des préfixes comme mock_ et des dates évidentes. Si une donnée fuit dans des logs ou un dashboard, elle sera immédiatement identifiable.

Démarrez ensuite le serveur de maquette. Apidog fournit une URL stable du type :

https://mock.apidog.com/m1/votre-identifiant-de-projet/

Configurez votre agent avec une variable d’environnement :

API_BASE_URL=https://mock.apidog.com/m1/votre-identifiant-de-projet/

Ne codez jamais l’URL de maquette dans le prompt ou dans la définition d’outil. Gardez le même agent et changez uniquement l’environnement :

# Développement
API_BASE_URL=https://mock.apidog.com/m1/project-id/

# Staging
API_BASE_URL=https://staging-api.example.com

# Production
API_BASE_URL=https://api.example.com

Voir le modèle plus large du développement contract-first.

Étape 3 : écrire un scénario qui reproduit les appels de l’agent

Les scénarios Apidog permettent d’enchaîner des appels API avec des assertions.

Pour un agent qui trie des tickets de support, un scénario peut ressembler à ceci :

1. POST /auth/token avec des identifiants de test ;
2. capturer le jeton d’authentification ;
3. GET /tickets?status=open avec le jeton ;
4. capturer le premier ID de ticket ;
5. POST /tickets/{id}/triage avec une catégorie ;
6. vérifier le statut 200 ;
7. capturer le champ assigned_to ;
8. POST /notifications avec un message ;
9. vérifier que le message respecte une expression régulière.

Exemple d’assertions à reproduire dans votre scénario :

pm.test("triage returns 200", function () {
  pm.response.to.have.status(200);
});

pm.test("assigned_to is present", function () {
  const body = pm.response.json();
  pm.expect(body.assigned_to).to.be.a("string");
});

pm.test("category is valid", function () {
  const body = pm.response.json();
  pm.expect(["billing", "technical", "account"]).to.include(body.category);
});

Vous rejouez ce que l’agent fera, mais contre le serveur de maquette, avec des assertions à chaque étape.

Si un développeur modifie le schéma de ticket et casse le champ assigned_to, le scénario échoue avant que l’agent n’atteigne la production.

Pour une approche plus complète, consultez le guide sur le test d’API pour les ingénieurs QA.

Étape 4 : exécuter les scénarios en CI

Ajoutez les scénarios à votre pipeline CI.

Exemple de commande :

apidog run -t scenario-id --env test

Dans une GitHub Action :

name: Agent API Scenarios

on:
  pull_request:
    paths:
      - "openapi/**"
      - "agents/**"
      - "tools/**"

jobs:
  test-agent-api:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run Apidog scenarios
        run: apidog run -t ${{ secrets.APIDOG_SCENARIO_ID }} --env test

Déclenchez ces tests sur toute PR qui touche :

• la spécification OpenAPI ;
• les définitions d’outils ;
• les prompts système ;
• la logique de planification ;
• les points d’accès appelés par l’agent.

Étape 5 : comparer deux versions de modèle

Quand vous changez de modèle, testez le comportement des appels d’outils.

Procédure :

1. exécutez l’agent avec le modèle A sur le même scénario ;
2. capturez la trace des appels d’outils ;
3. exécutez l’agent avec le modèle B ;
4. capturez la nouvelle trace ;
5. comparez les corps de requête.

Différences à surveiller :

• champ manquant ;
• enum différente ;
• date dans un autre format ;
• montant dans une autre unité ;
• priorité modifiée ;
• appel supplémentaire ;
• ordre d’appels différent.

Exemple de trace simplifiée :

{
  "model": "model-a",
  "tool_calls": [
    {
      "method": "POST",
      "path": "/tickets/123/triage",
      "body": {
        "category": "billing",
        "priority": "medium"
      }
    }
  ]
}

Comparez avec :

{
  "model": "model-b",
  "tool_calls": [
    {
      "method": "POST",
      "path": "/tickets/123/triage",
      "body": {
        "category": "billing",
        "priority": "high"
      }
    }
  ]
}

Le modèle B n’est pas forcément incorrect, mais il a changé le comportement opérationnel. Vous devez le savoir avant le déploiement.

Ce type d’évaluation est aussi utile lors d’une intégration API GPT-5.5.

Techniques avancées et astuces de pro

Fixez la température à zéro pendant les tests

Les agents non déterministes produisent des tests instables.

Pour tester les appels d’outils :

{
  "temperature": 0,
  "seed": 1234
}

Vous ne testez pas la créativité du modèle. Vous testez la stabilité des appels API.

Capturez les traces d’appels d’outils

Chaque exécution de test devrait enregistrer :

• nom de l’outil ;
• méthode HTTP ;
• chemin ;
• arguments ;
• corps de requête ;
• statut de réponse ;
• durée ;
• coût estimé.

Exemple :

{
  "run_id": "test_2026_05_01_001",
  "agent": "support-triage-agent",
  "tool_calls": [
    {
      "tool": "triage_ticket",
      "method": "POST",
      "path": "/tickets/123/triage",
      "status": 200,
      "duration_ms": 184
    }
  ]
}

Comparez les traces à une base de référence. Si l’agent commence à appeler /users deux fois au lieu d’une, vous devez le voir dans la PR, pas sur la facture.

Ne donnez jamais d’identifiants de production à un agent

Utilisez des comptes de service limités.

À éviter :

DATABASE_URL=postgres://prod-admin:password@prod-db
STRIPE_SECRET_KEY=sk_live_admin

À préférer :

API_BASE_URL=https://api.example.com
AGENT_SERVICE_TOKEN=short_lived_scoped_token

Si l’agent doit appeler la production, faites-le passer par un proxy qui :

• limite le périmètre ;
• signe les requêtes ;
• impose les budgets ;
• journalise les appels ;
• bloque les opérations sensibles.

Séparez les clés de lecture et d’écriture

La plupart des agents lisent plus qu’ils n’écrivent.

Créez deux scopes :

tickets:read
tickets:write

Donnez tickets:read par défaut. N’accordez tickets:write que pour les tâches qui le nécessitent, idéalement avec validation humaine.

Utilisez HTTP 423 pour les opérations avec approbation humaine

Pour une action verrouillée, renvoyez 423 Locked plutôt que 403 Forbidden.

Exemple :

HTTP/1.1 423 Locked
Content-Type: application/json

{
  "error": "human_approval_required",
  "confirmation_url": "https://admin.example.com/approvals/req_123",
  "expires_at": "2026-05-01T12:00:00Z"
}

403 signifie « interdit ». 423 signifie « verrouillé pour l’instant ». C’est plus clair pour un planificateur d’agent.

Échouez en mode fermé en cas de dérive de schéma

Si la définition d’outil ne correspond pas à OpenAPI, bloquez le build.

N’émettez pas seulement un warning.

if [ "$SCHEMA_DRIFT_DETECTED" = "true" ]; then
  echo "Schema drift detected between agent tools and OpenAPI"
  exit 1
fi

Le coût d’un build échoué est inférieur au coût d’une API appelée avec de mauvais arguments en production.

Erreurs courantes à éviter

• Coder en dur l’URL de maquette dans le prompt de l’agent.
• Oublier l’idempotence sur les « petits » points d’accès.
• Journaliser des corps de requête complets en production.
• Laisser les agents accéder directement à la base de données.
• Confondre score de confiance du modèle et sécurité de l’appel API.
• Utiliser les mêmes clés pour le développement, le staging et la production.
• Tester uniquement la réponse textuelle de l’agent, sans inspecter les appels d’outils.

Si votre agent appelle plusieurs services internes sans passerelle unique, les modèles de test de microservices expliquent comment répartir les scénarios entre services.

Alternatives et outillage

Vous avez plusieurs options pour tester les intégrations agent-API.

Résumé pratique :

• si vous utilisez déjà LangSmith, gardez-le pour l’évaluation des prompts et ajoutez une couche de test API ;
• si le modèle de prix ou de maquette de Postman ne vous convient plus, Apidog est une alternative ;
• si vous partez de zéro, choisissez un outil qui gère OpenAPI, les maquettes et les scénarios dans le même projet.

Certaines équipes combinent les outils : LangSmith pour les évaluations agent, Apidog pour les contrats API, les maquettes et les scénarios. Les deux couches ne résolvent pas le même problème.

Cas d’utilisation réels

Agent qui met à jour des lignes en production

Une équipe de succès client a développé un agent qui met à jour des champs de compte à partir de tickets support.

Avant le lancement, elle a :

• exigé une clé d’idempotence sur chaque écriture ;
• exécuté 200 relectures de scénarios dans Apidog ;
• utilisé une base de données bac à sable ;
• validé les enums côté API.

Les scénarios ont détecté deux cas où l’agent tentait de définir subscription_status sur une chaîne absente de l’énumération. L’équipe a ajouté une validation de schéma et a livré sans incident.

Agent qui appelle une API de paiements

Une équipe fintech a construit un agent de remboursement automatisé.

Garde-fous appliqués :

• maximum 5 remboursements par session ;
• maximum 50 dollars par remboursement ;
• idempotence obligatoire ;
• tests de contrat sur chaque PR ;
• validation humaine pour les montants hors seuil.

Elle a exécuté la suite de tests de contrat contre l’API utilisée. Six mois plus tard, 12 000 remboursements ont été traités sans double facturation.

Agent qui trie des issues GitHub

Une équipe plateforme a construit un agent de tri inspiré par Clawsweeper.

Elle a :

• simulé l’API GitHub dans Apidog ;
• écrit 50 scénarios de test ;
• couvert les issues supprimées, labels manquants et entrées mal formées ;
• capturé les traces d’appels d’outils.

Trois plantages ont été découverts avant le lancement. L’agent gère maintenant le tri sur un dépôt public avec plusieurs milliers d’issues ouvertes.

Checklist de mise en œuvre

Utilisez cette liste pour auditer votre intégration agent-API :

[ ] La spécification OpenAPI est la source de vérité.
[ ] Chaque définition d’outil est comparée à OpenAPI en CI.
[ ] Les points d’accès POST/PUT/PATCH/DELETE ont des maquettes.
[ ] L’agent utilise une URL de base configurable par environnement.
[ ] Chaque écriture exige une clé d’idempotence.
[ ] Les suppressions sont logiques par défaut.
[ ] Les opérations dangereuses nécessitent une approbation humaine.
[ ] Les agents utilisent des comptes de service à portée limitée.
[ ] Les clés de lecture et d’écriture sont séparées.
[ ] Les budgets par agent sont appliqués côté API ou passerelle.
[ ] Les traces d’appels d’outils sont capturées.
[ ] Les scénarios sont rejoués sur chaque PR pertinente.
[ ] Les logs de production masquent les PII et secrets.

Conclusion

Si vous ne retenez qu’une idée : l’agent n’est pas le problème principal. L’API est soit le problème, soit la solution, selon les garde-fous que vous avez mis en place.

À appliquer dès maintenant :

• traitez les schémas d’outils comme des contrats ;
• testez-les contre OpenAPI en CI ;
• simulez les points d’accès destructeurs ;
• exigez l’idempotence sur chaque écriture ;
• définissez des budgets qui échouent en mode fermé ;
• rejouez les scénarios avant chaque déploiement.

Les incidents d’agents IA ne vont pas disparaître. Les équipes qui s’en sortent sont celles qui testent la couche API avant de donner des outils aux modèles.

Téléchargez Apidog et commencez par le serveur de maquette. C’est souvent le garde-fou le plus rapide à mettre en place.

Pour aller plus loin, consultez aussi les outils de test API pour les ingénieurs QA et le guide sur comment écrire des fichiers AGENTS.md.

FAQ

Comment tester les appels API des agents IA sans dépenser trop de jetons ?

Exécutez l’agent contre un serveur de maquette pendant le développement. Les URL de maquette d’Apidog renvoient des réponses réalistes sans appeler vos vrais services. Fixez la température à 0 et utilisez un petit ensemble de prompts stables. Pour la configuration complète, consultez la liste de contrôle de test de l’ingénieur QA.

Quelle est la différence entre tester l’agent et tester l’API ?

Le test d’agent vérifie si le modèle choisit le bon outil et remplit correctement les arguments.

Le test d’API vérifie si le point d’accès se comporte correctement lorsqu’il est appelé.

Les deux sont nécessaires. Un agent correct qui appelle une API cassée produit des résultats cassés. Une API correcte appelée par un agent mal configuré produit aussi des bugs.

Ai-je besoin de clés d’idempotence sur chaque point d’accès ?

Oui, sur chaque point d’accès en écriture.

Les lectures sont idempotentes par définition. Les écritures ne le sont pas, et les agents réessaient. Un middleware d’idempotence évite les paiements doublés, les e-mails répétés et les lignes créées plusieurs fois.

Comment empêcher l’injection de prompt de déclencher de mauvais appels API ?

Ne vous fiez pas uniquement au prompt.

L’API doit appliquer l’autorisation selon le contexte utilisateur réel. Si l’utilisateur ne peut pas appeler /admin/delete-all-users, l’agent agissant pour lui ne doit pas pouvoir le faire non plus.

Le prompt peut réduire le risque. L’autorisation côté API le bloque réellement.

Puis-je utiliser Apidog avec Claude ou GPT sans écrire ma propre couche d’outils ?

Vous pouvez pointer les définitions d’outils de votre agent vers l’URL de maquette Apidog pendant les tests. Utilisez une variable d’environnement pour changer l’URL de base entre maquette, staging et production.

Quel est le bon plafond budgétaire pour un agent ?

Commencez strict, puis ajustez avec les données.

Exemple de départ :

• 50 000 jetons par session ;
• 30 appels API par minute ;
• 5 dollars par tâche ;
• 10 appels d’outils imbriqués maximum.

Surveillez pendant deux semaines, puis augmentez les plafonds réellement nécessaires. L’objectif est de bloquer les boucles incontrôlées sans empêcher le travail normal.

Comment détecter la dérive de schéma entre les outils de mon agent et mon API ?

Comparez les schémas en CI sur chaque PR.

Prenez la définition d’outil de l’agent, comparez-la au schéma OpenAPI du même point d’accès, puis faites échouer le build en cas de divergence. L’extrait Python dans la section des garde-fous fournit une base simple à intégrer dans votre dépôt.