La semana pasada dejé un agente depurando una integración contra una API interna y, al mirar los logs, me lo encontré llamando a endpoints que no le había pedido: estaba “explorando” el esquema por su cuenta, incluido un DELETE legacy que llevaba años deprecado. No pasó nada porque el entorno era de staging, pero la lección es la que lleva meses repitiendo Postman: el problema de seguridad con los agentes ya no es que un modelo escriba texto raro, es que un agente ejecuta acciones contra tus APIs, a velocidad de máquina y sin el criterio que un desarrollador aplica sin darse cuenta.
Si todavía te suena raro que un agente actúe como cliente de una API, repasa primero qué son los servidores MCP.
Postman publicó esta semana su planteamiento de seguridad para la era agéntica, y más allá del marketing de su propio agente, el post aterriza una idea que me parece correcta: tus APIs fueron diseñadas para consumidores humanos con juicio implícito, y los agentes no tienen ninguno. Los datos de su State of the API Report 2025 lo dejan en negro sobre blanco: el 89% de los desarrolladores usa IA generativa a diario, pero solo el 24% diseña sus APIs pensando en agentes. Ese hueco es tu superficie de ataque.
El caso que cuentan para ilustrarlo es de manual: en 2024, en una gran institución financiera, unos atacantes no rompieron ningún firewall; mandaron un email con instrucciones ocultas que hicieron que un asistente de IA aprobara transferencias fraudulentas por 2,3 millones de dólares. El agente hizo exactamente lo que estaba diseñado para hacer, y la API no notó la diferencia. Es prompt injection llevada al plano de las acciones, no del texto.
Con ese marco, este es el checklist que yo pasaría hoy a cualquier API que vaya a ser consumida por agentes. Nada de teoría nueva: son principios de seguridad de APIs de siempre, aplicados a un consumidor que no duda, no pregunta y no se cansa.
1. Inventario: no puedes proteger endpoints que no conoces
El riesgo API9:2023 Improper Inventory Management del OWASP API Security Top 10 existía antes de los agentes, pero con ellos se vuelve crítico. Un humano que integra tu API lee la documentación; un agente descubre endpoints llamándolos. Cada versión deprecada que sigue desplegada, cada endpoint de debug olvidado, cada API sombra de un equipo que ya no existe es una puerta que el agente encontrará por fuerza bruta semántica.
La respuesta organizativa es un catálogo vivo: qué APIs existen, quién las posee, qué versión está soportada y cuál es su contrato. Postman empuja su API Catalog como esa capa de gobierno —la idea es que el agente opere sobre lo que está catalogado y autorizado, no sobre todo lo que responde un 200—, pero el principio aplica igual con un Backstage, un portal propio o un repositorio de specs OpenAPI bien mantenido. Si un endpoint no está en el inventario, no debería estar expuesto.
2. Autorización por objeto y función, no “token válido, acceso total”
Los dos primeros puestos del OWASP API Security Top 10 2023 son autorización: API1 Broken Object Level Authorization y API5 Broken Function Level Authorization. Con agentes el riesgo se multiplica porque el patrón habitual es darle al agente un token “de servicio” con permisos de sobra “para que no falle”.
Lo mínimo razonable:
- Scopes de OAuth al mínimo necesario para la tarea concreta del agente. Si el agente consulta pedidos, su token no necesita
write:paymentsaunque “algún día igual lo use”. - Autorización a nivel de objeto en cada llamada: que el token sea válido no significa que pueda leer el recurso 12345. BOLA es la vulnerabilidad número uno de APIs y un agente iterando IDs la explota sin querer queriendo.
- Separación lectura/escritura a nivel de credencial, no de documentación. Si solo existe un token admin, el agente acabará usándolo para todo.
3. Aprobación humana para las operaciones que mutan
Aquí está la decisión de diseño que más me gusta del enfoque de Postman con su AI Engineer (en beta, disponible en el plan gratuito): el agente corre en un sandbox en la nube, sin tocar producción directamente, puede investigar, probar, documentar y proponer —pero las acciones que mutan pasan por aprobación humana explícita, integrada en el flujo de revisión de PRs de siempre.
No hace falta usar su producto para copiar el patrón: si tu agente puede crear, modificar o borrar a través de una API, mete un punto de aprobación humana en ese camino. Un agente que prepara el cambio y un humano que firma la ejecución es infinitamente más defendible ante un incidente que un agente con escritura directa “porque es más ágil”. La velocidad que pierdes en el caso feliz la recuperas con creces el día que el agente interprete mal una instrucción.
4. Rate limits y presupuestos de consumo por credencial
API4:2023 Unrestricted Resource Consumption y API6:2023 Unrestricted Access to Sensitive Business Flows describen exactamente el modo de fallo típico de un agente: un bucle de reintentos contra un endpoint de pago, una “exploración” que descarga medio catálogo, una tarea que llama a un flujo de negocio sensible mil veces porque su criterio de parada estaba mal puesto.
Un humano con un 429 para y mira qué pasa; un agente reintenta con backoff y sigue. Por eso los límites tienen que vivir en el servidor, por credencial: cuotas de peticiones, límites de gasto en endpoints que cuestan dinero (SMS, validaciones, llamadas a terceros) y umbrales de alerta cuando una credencial se sale de su patrón habitual. El rate limiting que “ya teníamos para el frontend” probablemente no está dimensionado para un consumidor que hace 500 llamadas por minuto sin pestañear.
5. Secretos fuera del alcance del agente
Si el agente (o su configuración, o sus ficheros de contexto) puede leer una API key, esa key acabará en un log, en un prompt o en un repo. Dos piezas de Postman que cubren esto y que sí he verificado en su documentación:
- Postman Vault: guarda claves como vault secrets en vez de en variables en claro. El Local Vault está disponible en todos los planes y no se sincroniza a la nube; el Shared Vault permite compartir a nivel de workspace, y en Enterprise (con el add-on de Advanced Security Administration) hay integraciones con 1Password, AWS Secrets Manager, Azure Key Vault y HashiCorp Vault para referenciar secretos sin copiarlos a Postman.
- Secret Scanner: detecta secretos expuestos en colecciones, entornos y documentación publicada, tanto en local antes de sincronizar (Local Secret Protection) como en la nube (Cloud Secret Detection, que escanea workspaces públicos por defecto).
El principio subyacente: el agente trabaja con referencias a credenciales, nunca con la credencial en texto plano dentro de su contexto.
6. Gobernanza en la especificación y en CI, no en un PDF
Las reglas de seguridad que solo viven en un documento de estilo no las cumple nadie, y un agente menos. Postman aplica sus reglas de API governance directamente sobre la especificación OpenAPI (3.1, 3.0 y 2.0): abres la spec en Spec Hub y la pestaña Issues te lista las violaciones, y en planes Enterprise puedes definir rulesets propios y meter la comprobación en tu pipeline de CI/CD con el Postman CLI, de modo que una spec que incumple las reglas rompe el build.
Que el contrato exija esquemas de autenticación definidos, que prohíba endpoints sin documentar o respuestas que devuelven de más, y que esa validación corra sola en cada PR, es la diferencia entre gobernar y rezar. Si el código lo escribe un agente, este control te interesa doble —de hecho, para auditar lo que el agente le hace a tu repo y a tu CI ya hablé de Ship Safe, que casa muy bien como complemento en el lado del código. Si quieres cerrar otro vector de la cadena de suministro, también te sirve el checklist de seguridad de npm.
7. Registra todo lo que hace el agente
Cuando un agente opera a velocidad de máquina, el log es la única crónica de lo que pasó. Cada llamada autenticada con su credencial, cada mutación aprobada (quién aprobó, cuándo, qué diff), cada ejecución en sandbox con sus artefactos. El planteamiento de Postman de devolver “artefactos verificables” —colecciones, resultados de tests, logs de ejecución, PRs— apunta a esto: que la actuación del agente sea reconstruible después. Sin ese rastro, un incidente con un agente es indistinguible de una caja negra, y la respuesta a incidentes se convierte en adivinación.
Cómo probar la seguridad de APIs con agentes de IA sin arriesgar producción
La prueba más barata que puedes hacer esta semana: monta un entorno aislado con datos sintéticos —un mock server o un staging bien cerrado—, dale a un agente real una tarea ambigua contra esa API y observa los logs. Qué endpoints descubre, qué intenta mutar, con qué frecuencia reintenta. Es la versión moderna del pentesting, y te va a enseñar más sobre tu superficie real que cualquier auditoría estática. Después, aplica el checklist: inventario, scopes mínimos, aprobación para escrituras, límites por credencial, secretos referenciados, gobernanza en CI y logs completos. Ningún punto es exótico; todos son urgentes cuando el consumidor no es una persona.
Preguntas frecuentes sobre seguridad de APIs con agentes de IA
¿Qué es la seguridad de APIs en la era de los agentes de IA?
Es aplicar los controles clásicos de seguridad de APIs (autorización, inventario, rate limiting, gestión de secretos, auditoría) asumiendo que el consumidor es un agente autónomo que actúa a velocidad de máquina, sin juicio implícito y susceptible de prompt injection. El OWASP API Security Top 10 sigue siendo la referencia base.
¿Qué es el prompt injection y por qué afecta a las APIs?
Es una técnica que oculta instrucciones maliciosas en el contenido que procesa un agente (un email, una web, un documento). Si el agente tiene credenciales para llamar a tus APIs, esas instrucciones pueden convertirse en acciones reales: transferencias, borrados, fugas de datos. La defensa pasa por scopes mínimos, aprobación humana en escrituras y sandboxing.
¿Es gratuito el AI Engineer de Postman?
Está en beta y disponible para usuarios del plan gratuito de Postman, según su página de producto. Sus piezas de seguridad relevantes son la ejecución en sandbox, la aprobación humana para cambios y el grafo de contexto de tus APIs. Las funciones de gobierno avanzadas (rulesets personalizados, dashboard de Secret Scanner) son de planes Enterprise.
¿Qué te ha parecido?
Déjame tu opinión, pregunta o sugerencia. Los comentarios se sincronizan con GitHub Discussions .