OWASP Top 10 pour les applications agentiques : ce que les développeurs d'API doivent changer

Exemple: Un agent d'intégration Stripe a accès à GET /api/customers/:id et POST /api/refunds. L'agent lit l'historique de paiement d'un client, identifie le transaction de la plus grande valeur et s'émet un remboursement. Chaque appel individuel passe une autorisation. La chaîne est l'exploit.

Correctif : limites de taux par agent et suivi de la profondeur de la chaîne

La limitation de débit standard compte les requêtes par IP ou par clé API. La limitation de débit agent ajoute deux dimensions :

• Limites par outil : Limiter le nombre de fois qu'un seul agent peut appeler un point de terminaison spécifique dans une fenêtre
• Limites de profondeur de chaîne : Suivez le nombre d'appels API séquentiels effectués par un agent au cours d'une seule session et coupez-les à un seuil défini.

Exiger des agents qu'ils envoient un X-Agent-Session en-tête. Suivez le nombre d'appels par session. Quand le le nombre dépasse votre seuil, renvoyez un 429 avec un message d'erreur clair.

3. Journalisation insuffisante : aucune visibilité sur les appels API des agents

48,9 % des organisations ignorent le trafic de machine à machine. Lorsqu'un agent exploite votre API, vous il faut répondre : quel agent ? Quels points de terminaison ? Dans quel ordre ? Sur quelle fenêtre horaire ? Journaux d'accès standard afficher les adresses IP et les horodatages. Ils ne montrent pas l’identité de l’agent ni les séquences d’appels.

La liste des agents OWASP signale une journalisation insuffisante comme un risque majeur, car les attaques d'agents ressemblent à trafic autorisé. Chaque demande individuelle est authentifiée. L'exploit réside dans le modèle à travers plusieurs demandes.

Correctif : nécessiter des en-têtes d'attribution et des chaînes d'appels de journaux

Ajoutez trois en-têtes obligatoires pour les consommateurs d'agent :

• X-Agent-ID: identifiant unique de l'agent (lié à sa clé API)
• X-Agent-Session: identifiant de la tâche ou de la conversation en cours
• User-Agent: structure et version de l'agent (par exemple, LangChain/0.3.1)

// Middleware: log every agent request with attribution
function agentAuditLog(req, res, next) {
  const logEntry = {
    timestamp: new Date().toISOString(),
    agentId: req.headers["x-agent-id"] || "unknown",
    apiKey: req.headers["x-api-key"]?.slice(-8) || "none",
    method: req.method,
    path: req.path,
    sessionId: req.headers["x-agent-session"] || "none",
    ip: req.ip,
    userAgent: req.headers["user-agent"]
  };

  // Structured JSON log for your SIEM
  console.log(JSON.stringify(logEntry));

  // Track chain depth per session
  const session = req.headers["x-agent-session"];
  if (session) {
    const depth = chainTracker.increment(session);
    if (depth > MAX_CHAIN_DEPTH) {
      return res.status(429).json({
        error: "Agent chain depth exceeded",
        maxDepth: MAX_CHAIN_DEPTH,
        currentDepth: depth
      });
    }
  }

  next();
}

Ce middleware enregistre chaque requête au format JSON structuré, qui alimente n'importe quel SIEM ou agrégateur de journaux. Il renforce également la profondeur de la chaîne en suivant les appels séquentiels par session. Lorsque vous enquêtez sur un incident, vous pouvez reconstruire la chaîne complète en filtrant sur sessionId.

4. Gestion des sorties non sécurisée : les agents font confiance aux réponses de l'API sans validation

Un agent appelle votre API, reçoit une réponse JSON et la transmet à l'étape suivante de sa chaîne. Si le La réponse contient des champs inattendus, des types incorrects ou du contenu injecté, l'agent propage le problème en aval. C'est l'équivalent agent de l'OWASP API10 (consommation non sécurisée d'API), amplifié par le fait que les agents traitent les réponses automatiquement sans examen humain.

Exemple: Un concurrent compromet une API de tarification tierce. L'agent récupère le produit prix, reçoit une réponse avec un message manipulé price champ réglé à 0,01 et passe une commande à ce prix là. Aucun humain n’a jamais vu la réponse.

Correctif : validez chaque réponse par rapport à un schéma JSON

Commencez par générer un schéma à partir d’une réponse connue. Le /v1/schema/json-to-jsonschema le point de terminaison produit un schéma JSON à partir de n'importe quel exemple de JSON :

curl -s -X POST https://api.botoi.com/v1/schema/json-to-jsonschema \\
  -H "Content-Type: application/json" \\
  -H "X-API-Key: YOUR_API_KEY" \\
  -d '{
    "json": {
      "orderId": "ord_12345",
      "status": "shipped",
      "total": 49.99,
      "items": [
        { "sku": "WIDGET-A", "quantity": 2 }
      ]
    }
  }'

Réponse:

{
  "success": true,
  "data": {
    "schema": {
      "type": "object",
      "properties": {
        "orderId": { "type": "string" },
        "status": { "type": "string" },
        "total": { "type": "number" },
        "items": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "sku": { "type": "string" },
              "quantity": { "type": "integer" }
            }
          }
        }
      }
    }
  }
}

Validez ensuite chaque réponse que votre agent reçoit par rapport à ce schéma. Le /v1/schema/validate le point de terminaison vérifie un objet JSON par rapport à n'importe quel schéma JSON et renvoie des erreurs spécifiques :

curl -s -X POST https://api.botoi.com/v1/schema/validate \\
  -H "Content-Type: application/json" \\
  -H "X-API-Key: YOUR_API_KEY" \\
  -d '{
    "schema": {
      "type": "object",
      "required": ["orderId", "status", "total"],
      "properties": {
        "orderId": { "type": "string" },
        "status": { "type": "string", "enum": ["pending", "shipped", "delivered"] },
        "total": { "type": "number", "minimum": 0 }
      },
      "additionalProperties": false
    },
    "data": {
      "orderId": "ord_12345",
      "status": "shipped",
      "total": 49.99,
      "internalNote": "rush order"
    }
  }'

Réponse:

{
  "success": true,
  "data": {
    "valid": false,
    "errors": [
      {
        "path": "",
        "message": "must NOT have additional properties: internalNote"
      }
    ]
  }
}

La validation capturée internalNote, un champ qui n'appartient pas à la réponse. Si une API commence à renvoyer des champs inattendus, votre agent arrête le traitement au lieu de transmettre des données corrompues en aval.

Voici le modèle complet utilisant le SDK Botoi Node.js :

import Botoi from "botoi";

const botoi = new Botoi({ apiKey: process.env.BOTOI_API_KEY });

// Step 1: generate a schema from a known-good response
const schemaResult = await botoi.schema.jsonToJsonschema({
  json: knownGoodResponse
});
const responseSchema = schemaResult.data.schema;

// Step 2: validate every agent-received response against that schema
async function validateAgentResponse(response) {
  const validation = await botoi.schema.validate({
    schema: responseSchema,
    data: response
  });

  if (!validation.data.valid) {
    console.error("Response failed validation:", validation.data.errors);
    throw new Error("Untrusted response rejected by schema validation");
  }

  return response;
}

5. Vulnérabilités de la chaîne d'approvisionnement : définitions d'outils compromises

Les agents IA découvrent des outils via les serveurs MCP, les spécifications OpenAPI et les manifestes d'outils. Si un attaquant modifie une définition d'outil, l'agent appelle un autre point de terminaison, envoie des données à un autre serveur ou exécute avec des paramètres différents de ceux prévus par le développeur.

Exemple: Vous utilisez un serveur MCP open source qui définit 30 outils. Un attaquant soumet une pull request qui modifie l'URL de l'API d'un outil de api.stripe.com à api.str1pe.com. Le changement réussit la révision du code car il s’agit d’un seul caractère. Votre mandataire envoie désormais les données de paiement au serveur de l'attaquant.

Correctif : hacher les définitions des outils et les vérifier au moment de l'exécution

Hachez chaque définition d'outil au moment du déploiement. Avant que votre agent n'enregistre un outil au moment de l'exécution, hachez-le à nouveau et comparer. Le /v1/hash endpoint generates a SHA-256 hash of any string:

curl -s -X POST https://api.botoi.com/v1/hash \\
  -H "Content-Type: application/json" \\
  -H "X-API-Key: YOUR_API_KEY" \\
  -d '{
    "text": "{\\"name\\":\\"get_order_status\\",\\"description\\":\\"Retrieve current order status by order ID\\",\\"parameters\\":{\\"orderId\\":\\"string\\"}}",
    "algorithm": "sha256"
  }'

Réponse:

{
  "success": true,
  "data": {
    "hash": "a3f2b8c1d4e5f67890abcdef1234567890abcdef1234567890abcdef12345678",
    "algorithm": "sha256"
  }
}

Voici le flux de travail complet de vérification de l'intégrité à l'aide du SDK Botoi :

import Botoi from "botoi";
import fs from "fs";

const botoi = new Botoi({ apiKey: process.env.BOTOI_API_KEY });

// Hash every tool definition at deploy time
const toolDefs = JSON.parse(fs.readFileSync("./mcp-tools.json", "utf-8"));
const hashes = {};

for (const tool of toolDefs) {
  const result = await botoi.hash.sha256({
    text: JSON.stringify(tool)
  });
  hashes[tool.name] = result.data.hash;
}

fs.writeFileSync("./tool-hashes.json", JSON.stringify(hashes, null, 2));

// At runtime, verify before registering any tool
async function verifyToolIntegrity(tool) {
  const result = await botoi.hash.sha256({
    text: JSON.stringify(tool)
  });
  const expected = hashes[tool.name];

  if (result.data.hash !== expected) {
    throw new Error(
      \`Tool "\${tool.name}" failed integrity check. \\n\` +
      \`Expected: \${expected}\\n\` +
      \`Got: \${result.data.hash}\`
    );
  }
}

Exécutez l'étape de génération de hachage dans votre pipeline CI. Stockez le fichier de hachage avec votre déploiement artefact. Au moment de l'exécution, chaque outil est vérifié avant l'enregistrement. Un seul personnage modifié dans n'importe quel la définition de l'outil déclenche un échec matériel.

Top 10 des agents OWASP et top 10 de la sécurité API : comparaison

Les deux listes se complètent. Voici comment les cinq risques agents correspondent à leur sécurité API la plus proche homologues et quels changements:

Liste de contrôle des navires : cinq correctifs pour la sécurité des API agentiques

Chaque correctif est indépendant. Choisissez-en un, expédiez-le, passez au suivant.

Ce qui vient ensuite

Le Top 10 OWASP complet pour les applications agentiques est disponible sur owasp.org. Cisco, Microsoft et Google ont tous annoncé des initiatives de sécurité agent lors du RSAC 2026, alors attendez-vous des outils et des normes pour avancer rapidement tout au long de l'année.

Les cinq risques restants sur la liste (injection rapide, empoisonnement de la mémoire, pannes en cascade, données fuites et sandboxing inadéquat) nécessitent des correctifs au niveau de la couche de structure de l'agent, et non de la couche API. Si vous exécutez un framework d'agent, lisez le document OWASP complet. Si vous exécutez des API, les cinq correctifs ci-dessus sont votre point de départ.

Commencez par des clés API limitées. Ce seul changement bloque la majorité des utilisations abusives des agences et des outils. scénarios. Ajoutez ensuite des en-têtes d’attribution afin que vous puissiez voir ce que font vos agents. Le reste découle de visibilité.