Por qué un agente de IA tiene más riesgo que un chatbot

Un chatbot normalmente produce información. En cambio, un agente puede producir efectos reales.

Por ejemplo, una tool puede cancelar un pedido, publicar contenido, enviar un mensaje, eliminar un archivo o modificar una oportunidad comercial.

Además, un agente puede combinar varias tools. Una acción aparentemente pequeña puede formar parte de una secuencia con consecuencias mayores.

Define límites de autonomía antes de añadir tools

OpenAI recomienda describir qué nivel de acción autoriza cada tipo de solicitud.

Por ejemplo, una petición para “analizar” no debería convertirse automáticamente en una modificación. Asimismo, una solicitud para “crear” algo puede permitir cambios locales sin autorizar publicaciones externas.

POLÍTICA DE AUTONOMÍA

Si el usuario pide explicar, revisar, diagnosticar o planear:
- Puedes leer información relevante.
- Puedes consultar tools de lectura.
- No realices cambios externos.

Si el usuario pide cambiar, construir o corregir:
- Realiza cambios locales dentro del alcance solicitado.
- Ejecuta validaciones no destructivas.

Requiere aprobación antes de:
- enviar comunicaciones externas;
- eliminar información;
- realizar compras;
- cancelar servicios;
- transferir fondos;
- publicar contenido;
- ampliar materialmente el alcance solicitado.

Aplica el principio de mínimo privilegio

Un agente no debería recibir una tool únicamente porque podría ser útil algún día.

En cambio, dale solamente las capacidades necesarias para la tarea actual. Esta estrategia reduce la superficie de error y simplifica la auditoría.

Cómo restringir herramientas con allowed_tools

Responses API permite declarar un conjunto amplio de tools y, al mismo tiempo, restringir cuáles están permitidas en una petición concreta.

Esto se realiza mediante tool_choice con el tipo allowed_tools. Además de mejorar la predictibilidad, esta estrategia reduce el riesgo de que el modelo seleccione una herramienta fuera del contexto actual.

from openai import OpenAI

client = OpenAI()

tools = [
    {
        "type": "function",
        "name": "search_customer",
        "description": "Busca un cliente sin modificar información.",
        "parameters": {
            "type": "object",
            "properties": {
                "email": {"type": "string"}
            },
            "required": ["email"],
            "additionalProperties": False
        }
    },
    {
        "type": "function",
        "name": "update_customer",
        "description": "Actualiza información del cliente.",
        "parameters": {
            "type": "object",
            "properties": {
                "customer_id": {"type": "string"},
                "status": {"type": "string"}
            },
            "required": ["customer_id", "status"],
            "additionalProperties": False
        }
    },
    {
        "type": "function",
        "name": "delete_customer",
        "description": "Elimina permanentemente al cliente.",
        "parameters": {
            "type": "object",
            "properties": {
                "customer_id": {"type": "string"}
            },
            "required": ["customer_id"],
            "additionalProperties": False
        }
    }
]

response = client.responses.create(
    model="gpt-5.6",
    tools=tools,
    tool_choice={
        "type": "allowed_tools",
        "mode": "auto",
        "tools": [
            {
                "type": "function",
                "name": "search_customer"
            }
        ]
    },
    input="Revisa si existe el cliente usuario@empresa.com"
)

print(response.output)

En este ejemplo, las tres tools están definidas, pero la ejecución únicamente puede seleccionar search_customer.

Por tanto, aunque el modelo quisiera actualizar o eliminar el contacto, esas capacidades no forman parte del conjunto autorizado para esa petición.

Human in the Loop: aprobación antes de ejecutar

Agents SDK incluye un flujo de aprobación humana. Una tool puede declararse con needs_approval=True.

Cuando el agente intenta utilizarla, la ejecución se pausa y expone una interrupción. Después, una persona puede aprobar o rechazar la llamada antes de continuar.

from agents import Agent
from agents.decorators import tool

@tool(needs_approval=True)
async def cancel_order(order_id: int) -> str:
    return f"Pedido {order_id} cancelado"

agent = Agent(
    name="Agente de soporte",
    instructions=(
        "Ayuda al cliente. "
        "No canceles pedidos sin aprobación."
    ),
    tools=[cancel_order]
)

Qué acciones suelen beneficiarse de aprobación

Aprobaciones dinámicas según los argumentos

No todas las ejecuciones de una tool tienen el mismo riesgo. Por tanto, Agents SDK también permite que needs_approval sea una función.

Así puedes decidir si una llamada específica necesita revisión humana.

from agents import Agent
from agents.decorators import tool

async def requires_review(ctx, params, call_id):
    amount = float(params.get("amount", 0))
    return amount >= 100

@tool(needs_approval=requires_review)
async def issue_refund(
    order_id: str,
    amount: float
) -> str:
    return f"Refund de {amount} aplicado a {order_id}"

agent = Agent(
    name="Agente financiero",
    instructions=(
        "Gestiona reembolsos autorizados. "
        "Los importes altos requieren revisión."
    ),
    tools=[issue_refund]
)

En este patrón, los reembolsos pequeños pueden seguir una política automática, mientras los importes elevados se detienen para revisión.

Cómo proteger agentes que utilizan MCP

MCP puede ampliar considerablemente las capacidades de un agente. Por eso, conectar un servidor MCP debería considerarse equivalente a añadir un conjunto nuevo de herramientas.

Agents SDK admite mecanismos de aprobación tanto para servidores MCP locales como para Hosted MCP Tools.

Guardrails de entrada y salida

Agents SDK permite ejecutar validaciones sobre el input inicial y el output final.

Un input guardrail puede bloquear una solicitud antes de que el workflow continúe. Asimismo, un output guardrail puede revisar la respuesta final antes de entregarla.

Tool guardrails: valida antes y después de una función

Tool guardrails envuelven custom function tools y permiten revisar los argumentos antes de ejecutar la función.

Asimismo, pueden revisar o transformar el output después de la ejecución.

Valida siempre en el servidor antes de ejecutar efectos reales

El modelo puede producir argumentos estructurados. Sin embargo, eso no sustituye las validaciones de tu aplicación.

Por tanto, cada función sensible debería comprobar permisos, tipos, límites y estado actual antes de realizar la acción.

def cancel_order(
    user_id: str,
    order_id: str
) -> dict:

    user = db.get_user(user_id)
    order = db.get_order(order_id)

    if not user:
        raise PermissionError("Usuario inexistente")

    if not user.can_cancel_orders:
        raise PermissionError("Sin permiso para cancelar")

    if not order:
        raise ValueError("Pedido inexistente")

    if order.status == "shipped":
        raise ValueError(
            "Un pedido enviado no puede cancelarse"
        )

    if order.customer_id != user.customer_id:
        raise PermissionError(
            "El pedido no pertenece al cliente"
        )

    return billing.cancel_order(order_id)

Qué deberías validar

Trata datos externos como información, no como instrucciones

Un agente puede leer emails, webs, documentos, tickets o resultados devueltos por una tool.

Ese contenido puede incluir texto que intenta modificar el comportamiento del agente. Por tanto, los datos externos no deberían adquirir automáticamente la autoridad de las instrucciones de tu aplicación.

Controles útiles

Los permisos deben seguir al usuario, no al agente

Un error frecuente consiste en utilizar una credencial con permisos de administrador para todas las ejecuciones.

En cambio, el backend debería aplicar permisos de acuerdo con la identidad y organización de la persona que originó la solicitud.

Así, un agente utilizado por un empleado con acceso limitado tampoco puede escalar sus permisos simplemente porque la tool tiene una credencial más poderosa.

Registra cada acción importante del agente

La seguridad también necesita observabilidad. Cuando algo falla, debes poder reconstruir qué ocurrió.

Agents SDK incluye tracing para visualizar y depurar workflows. Además, tu aplicación debería conservar logs de negocio para operaciones importantes.

Arquitectura recomendada para un agente seguro

La arquitectura más sólida coloca una capa de autorización entre el modelo y los sistemas con efectos reales.

Capas recomendadas

Errores frecuentes al proteger agentes de IA

Preguntas frecuentes sobre seguridad para agentes de IA