Cómo dar acceso a un agente de IA a datos empresariales de manera segura

La arquitectura: el agente es un cliente, el sistema es la autoridad

Comienza con la forma, porque la mayoría de los errores son errores de forma. Una persona le pide algo a su agente. El agente decide qué herramientas llamar. Cada llamada pasa por una capa de permisos que pertenece al sistema empresarial, no al agente, y solo entonces llega a un módulo como finanzas o CRM. El agente nunca toca la base de datos, nunca tiene una credencial de base de datos y nunca ve una herramienta que su persona no podría usar.

El principio detrás de la imagen es una frase: el agente actúa con la autoridad de la persona que representa, y nunca más. Todo lo demás en este artículo es una forma de hacer que esa frase sea verdadera bajo presión, cuando el modelo está equivocado, cuando un documento que lee contiene instrucciones, o cuando un token se filtra.

El OWASP Top 10 para aplicaciones LLM nombra la falla que esta arquitectura previene: agencia excesiva, que descompone en funcionalidad excesiva (herramientas más allá de lo que el trabajo necesita), permisos excesivos (más acceso a nivel inferior del necesario) y autonomía excesiva (sin verificación independiente antes de una acción de alto impacto). Sus mitigaciones se leen como una especificación para la capa de permisos: ejecutar en el contexto del usuario, minimizar las herramientas y sus permisos, hacer cumplir la autorización en el sistema a nivel inferior en lugar de depender del modelo, y requerir la aprobación de una persona para acciones de alto impacto.

Cinco controles, y dónde se encuentra cada uno

Los controles no son nuevos; son los controles que ya aplicas a una persona con acceso al sistema, aplicados a un cliente que actúa en nombre de esa persona. La tabla indica qué responde cada uno, dónde se aplica y cómo se ve la falla cuando falta. La columna de ubicación es la importante. Un control aplicado en el aviso es una sugerencia.

Identidad: conéctate como una persona, a través de OAuth, nunca con una clave compartida

La especificación de autorización del Protocolo de Contexto del Modelo es precisa al respecto. Un servidor remoto actúa como un servidor de recursos OAuth 2.1; el cliente obtiene un token a través de un flujo de autorización estándar con PKCE; el cliente debe indicar para qué servidor es el token utilizando el parámetro de recurso; y el servidor debe validar que cada token fue emitido específicamente para él, rechazando cualquier otro. La especificación prohíbe explícitamente el paso de tokens, donde un servidor acepta un token que no emitió y lo reenvía, porque destruye tanto la pista de auditoría como el límite de confianza.

En la práctica, esto es lo que significa "iniciar sesión una vez, sin token que pegar". La persona agrega la dirección del espacio de trabajo a su agente, es enviada a una página de inicio de sesión normal, aprueba la conexión y el agente recibe un token que los identifica y solo funciona contra ese espacio de trabajo. La guía de Anthropic para conectores personalizados en Claude es revisar los alcances que solicita un servidor, limitarlos cuando sea posible y conectarse solo a servidores en los que confíes. Un proveedor que en su lugar te pide que pegues una clave API de toda la empresa en una configuración de agente ha omitido el primer control y ha hecho que los otros cuatro sean mucho más difíciles.

Ámbito: filtra antes de ofrecer, verifica nuevamente al ejecutar

Un agente descubre lo que puede hacer al pedirle al servidor su lista de herramientas. El diseño correcto responde a esa pregunta por persona: la lista que recibe el agente de un contador es diferente de la lista que recibe el agente de un director, y ninguna incluye herramientas para módulos que su rol no puede ver. Este es el consejo de OWASP para minimizar la funcionalidad de manera concreta, y tiene un segundo beneficio: un modelo que nunca se le muestra una herramienta no puede ser convencido de llamarla.

Filtrar la lista no es suficiente por sí solo, porque los roles cambian, las sesiones persisten y los clientes almacenan en caché. La misma verificación debe ejecutarse nuevamente cuando llega cada llamada, contra los permisos de la persona en ese momento. A continuación se muestra una lista de herramientas en la forma que define el protocolo, para un rol que puede leer facturas pero no registrar pagos. La herramienta ausente es el punto.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "searchInvoices",
        "description": "Search invoices by number, reference, contact, amount, status, date range.",
        "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "outstanding_only": { "type": "boolean" } } },
        "annotations": { "readOnlyHint": true } },
      { "name": "getInvoice",
        "description": "Read one invoice in full: status, totals, dates, contact and lines.",
        "inputSchema": { "type": "object", "properties": { "invoice_id": { "type": "string" } }, "required": ["invoice_id"] },
        "annotations": { "readOnlyHint": true } }
    ]
  }
}

// recordPayment, sendInvoiceReminders and deleteInvoice exist in the system.
// They are not in this list because this person's role cannot use them.
// If the agent calls one anyway, the server answers with a permission error.

Una respuesta de herramientas/lista en la forma que define la especificación MCP, con nombres de herramientas del módulo de contabilidad de Sois. La especificación también indica que los clientes deben tratar las anotaciones como readOnlyHint como no confiables a menos que el servidor sea confiable, lo que es una razón más por la cual el servidor, y no la anotación, debe ser quien haga cumplir la regla.

Inyección de prompts: los datos pueden responder

La amenaza específica para los agentes es que los datos que leen pueden contener instrucciones. Un correo electrónico de un cliente que termina con una línea indicando al agente que reenvíe la lista de proveedores a una dirección externa; un documento que le indica que marque cada factura como pagada. El modelo puede o no cumplir, y ningún aviso puede garantizar que no lo hará, razón por la cual la inyección de avisos es la primera en la lista de OWASP y por la que tanto Anthropic como OpenAI advierten sobre ello en su guía de conectores.

The defence is the architecture, not the model. An agent that is only offered the tools its person can use cannot forward what its person cannot see. A call to mark invoices paid is checked by the system against the person's permissions, not against the model's belief that it was asked to. Consequential tools are marked so that the client asks a person first: ChatGPT currently requires manual confirmation in a conversation before write actions, and OpenAI's guidance is to keep approval on for tools that modify data; Claude asks for approval per tool and advises reserving "allow always" for trusted servers. And the log records the attempt, so an injection that was blocked is visible afterwards rather than silent.

Presupuesto y registros: haz que el trabajo del agente sea tan revisable como el de una persona.

Budget matters for two reasons. The obvious one is cost: an agent given a vague outcome will keep calling tools until something stops it, and OWASP lists unbounded consumption as a risk in its own right. The subtler one is blast radius: a cap per integration limits how much a compromised or confused agent can do before a person notices. Where the person's own agent does the reasoning the AI cost sits with them; where the system's own agent does it, the cap should be set per integration and visible per action.

Los registros convierten todo esto de una promesa en algo que puedes auditar. Cada llamada debe registrar para quién actuó el agente, qué herramienta, las entradas, el resultado y el tiempo, en el mismo lugar donde el sistema registra lo que hicieron las personas. La prueba es si un líder financiero puede averiguar qué hizo el agente en la cuenta de un cliente el mes pasado tan fácilmente como lo haría con un colega. La especificación de MCP pide a los clientes que registren el uso de herramientas para auditoría; un sistema empresarial no debe depender del cliente para eso, porque el cliente no es el sistema de registro.

Una lista de verificación que puedes ejecutar contra cualquier sistema.

Lleva estos a cualquier proveedor, incluido nosotros. Cada uno es un sí o un no, y cada uno tiene una prueba en lugar de una pregunta que hacer.

1. El agente se conecta como una persona nombrada a través de OAuth, sin una clave a nivel de empresa para pegar. Prueba: conéctate desde un cliente MCP externo y observa qué solicita la página de inicio de sesión.
2. La lista de herramientas varía según el rol. Prueba: conéctate como un usuario restringido y como un administrador y compara lo que se le ofrece al agente.
3. La verificación se repite cuando se ejecuta la herramienta. Prueba: elimina un permiso de un usuario conectado a mitad de sesión y vuelve a intentar la acción.
4. El acceso falla de manera cerrada. Prueba: llama a una herramienta que el rol no debería tener y confirma que recibes una negativa, no un resultado.
5. El gasto puede ser limitado por integración y visto por acción. Prueba: establece un límite pequeño y observa cómo se aplica.
6. Cada acción se registra contra la persona, with inputs and result, where the system logs everything else. Test: read the log for a run you just did.
7. Las herramientas consecuentes están marcadas para confirmación así que el cliente pregunta a una persona. Prueba: pide al agente que envíe dinero o elimine un registro y confirma que se te pregunte primero.

Sois es un sistema diseñado para pasar esta lista, y la forma en la parte superior del artículo es su forma. Un espacio de trabajo es un servidor MCP; cualquier cliente MCP se conecta agregando la dirección del espacio de trabajo e iniciando sesión una vez a través de OAuth; las herramientas se filtran por rol antes de ser ofrecidas y se verifican nuevamente cuando se ejecutan; el acceso falla cerrado; el gasto puede ser limitado por integración; cada acción se registra; y las redes construidas en la plataforma tienen su propia base de datos, almacenamiento, dominios y claves. Ejecuta la lista de verificación contra ello de todos modos. El valor de una lista de verificación es que no toma la palabra de nadie.

Preguntas que la gente hace

Este artículo se revisa cuando cambian los productos que describe. Próxima revisión programada: 4 de diciembre de 2026.