Un chat de soporte puede convertirse en una acción que implica movimiento de dinero cuando un backend de FastAPI acepta la salida del modelo como una instrucción autoritativa.
En el escenario de fallo que analizamos en este curso, una aplicación cliente envía un mensaje aparentemente normal a POST /v1/chat; el servicio FastAPI reenvía ese texto a un proveedor de modelos y el modelo devuelve una instrucción de herramienta que se asemeja a una solicitud de reembolso.
El backend ejecuta la llamada a la herramienta tan pronto como el modelo la sugiere, sin verificar si el usuario final tiene permiso para realizar dicha acción y sin tratar la salida del modelo como texto no confiable.
No se requiere nada inusual para que se produzca el fallo. El backend hace exactamente aquello para lo que fue diseñado, pero ejecuta el paso con mayores privilegios —la acción de la herramienta— basándose en una cadena de texto que proviene de fuera del límite de confianza.
Una vez que se ha ejecutado la acción irreversible, ningún filtro posterior puede deshacer el efecto secundario; por ello, debemos decidir dónde establecer el primer punto de control efectivo.
Una misma solicitud atraviesa varios límites donde el texto no confiable se transforma en gastos o efectos secundarios; el curso se mantiene centrado en esa ruta específica para que cada mecanismo de control se ubique en el lugar adecuado.
El texto no confiable puede provenir de tres fuentes, incluso cuando la aplicación cliente se comporta correctamente: el mensaje del cliente llega a través de la solicitud HTTP, los documentos recuperados provienen de los propios almacenes de datos del backend y los resultados de las herramientas llegan desde otros sistemas que podrían ser erróneos o maliciosos.
El consumo de dinero y datos puede ocurrir en dos puntos: la llamada al proveedor del modelo conlleva un coste y consumo de tokens, mientras que la ejecución de la herramienta puede leer o modificar recursos reales que quizás no pertenezcan al usuario.
Los únicos puntos de control fiables son las verificaciones realizadas en el servidor (dentro del servicio FastAPI) en torno a esos puntos de consumo. El curso implementa la autenticación, la asociación con el inquilino (tenant binding), las cuotas, los filtros de entrada y salida, la autorización de herramientas, el aislamiento (sandboxing) y el registro de auditoría como barreras explícitas; la redacción del prompt no garantiza ninguna de estas medidas, ya que el prompt del sistema es legible y el modelo simplemente sigue las instrucciones del texto.
El siguiente diagrama señala cada entrada no confiable y cada punto de control a lo largo de la ruta de solicitud que estamos analizando. Identifiquemos con precisión el momento en que el texto adquiere autoridad y dónde podemos denegar la operación.
Este diagrama hace visible una regla. No se confía en ninguna flecha que transporte texto, y solo los cuadros de nuestro servicio pueden rechazar, limitar, validar, autorizar y registrar lo sucedido.
Un contrato de API seguro requiere códigos de rechazo coherentes, ya que tanto los clientes como la depuración de incidencias dependen de resultados predecibles cuando una barrera de control rechaza una solicitud.
Definimos el mapa de rechazos una sola vez y luego lo reutilizamos, vinculando siempre cada rechazo al límite o barrera que lo aplica, en lugar de al modelo.
401 Unauthorized: rechaza credenciales del llamante ausentes, inválidas, revocadas o comprometidas; el servicio devuelve este error antes de consumir cuota o llamar al proveedor.403 Forbidden: rechaza a un llamante autenticado que opera fuera de su ámbito permitido (incluyendo casos de aprobación denegada o caducada) y también rechaza intentos de acceder a herramientas en destinos bloqueados con los que nunca se llega a contactar.422 Unprocessable Content (RFC 9110): rechaza la salida del modelo que no supera la validación de esquema, ya que una salida no validada es simplemente texto hasta que el servidor demuestra que cumple con el contrato de la herramienta.429 Too Many Requests (con Retry-After): rechaza solicitudes cuando se ha agotado el límite de tasa o la cuota; el contador debe compartirse para evitar que las réplicas multipliquen el límite de forma inadvertida.503 Service Unavailable: se produce cuando el almacén del contador de cuotas no está disponible o un interruptor de circuito (circuit breaker) abierto impide aplicar la restricción, ya que el servicio no puede determinar con seguridad si el consumo está permitido.504 Gateway Timeout: se produce cuando la llamada al proveedor supera el tiempo de espera (timeout) del servicio, ya que las llamadas bloqueadas indefinidamente implican un consumo ilimitado.Para mantener un enfoque práctico en el curso, construimos un único artefacto funcional y lo reforzamos paso a paso. El artefacto consiste en una ruta POST /v1/chat con soporte multiinquilino (tenant-aware) capaz de invocar exactamente una herramienta; cada lección posterior añade una barrera de control a dicho flujo.
En el caso de un fallo inicial, el llamante puede ser legítimo; esto significa que la autenticación puede tener éxito aunque la solicitud derive en una acción no autorizada de la herramienta.
Si el servicio espera a validar la salida del modelo hasta después de ejecutar la llamada a la herramienta, la validación de esquema aún puede rechazar una carga útil (payload) mal formada, pero no puede revertir una acción que parece correcta pero que nunca debió permitirse.
La decisión importante es qué etapa puede denegar la operación antes de que se ejecute una acción irreversible de la herramienta. ¿Cuál es el primer punto de control que detecta el fallo: la autenticación, la autorización de la herramienta o la validación de la salida?