¿Debe su negocio ser invocable por un agente?

Un crédito puede aparecer en su libro mayor que ningún empleado emitió y que ningún atacante forzó. Un cliente habló con un asistente de IA, la ventana de ChatGPT, Claude o Gemini que ese cliente ya usa. El asistente llamó un trabajo que usted hizo invocable por un agente: un trabajo que sus sistemas van a correr cuando ese asistente lo pida. Decidió que un reembolso era el siguiente paso útil, presentó un acceso válido y su sistema aceptó la llamada, exactamente como se construyó para hacerlo.

El lunes: escriba los tres trabajos que un asistente nunca tendrá permitido empezar. Pagos y reembolsos. Ediciones destructivas y eliminaciones. Exportación masiva de cualquier cosa personal. Luego cace cualquier trabajo ya conectado que no pertenezca a esa lista. Usted no empieza cableando un servidor.

Un acceso no es un permiso.

Las respuestas equivocadas son baratas. Las acciones equivocadas no.

El fallo para el que la gente se prepara es una mala respuesta. Un precio equivocado citado por un chatbot le cuesta un correo de corrección.

El fallo que de verdad duele es un cambio de estado: un reembolso emitido, un registro eliminado, una lista de clientes exportada, una reserva sobrescrita. Las tarifas de contracargo llegan semanas después. Una exportación de datos personales que sale de su perímetro se vuelve una decisión de notificación. Si sus logs no pueden responder «quién hizo esto» en una consulta, esa semana se vuelve dos.

Los trabajos de escritura se envían porque la demo es mejor con ellos. Una conexión de solo lectura es un Loom poco impresionante. Una conexión que reserva la cita obtiene el presupuesto. Callable comercializa software de voz que responde el teléfono de un negocio 24/7, reserva citas y toma reservaciones, porque reservar es lo que cierra la venta del software. Ese incentivo es por qué la superficie riesgosa se construye primero.

El acceso llega. Usted decide qué puede hacer.

El cableado común es el Model Context Protocol (MCP), el protocolo de contexto del modelo, publicado el 18 de junio de 2025: una especificación que deja que un asistente llame un trabajo en sus sistemas. Dice que una persona debe consentir antes de que corra un trabajo, y luego dice que la especificación misma no lo hace cumplir. El cumplimiento es suyo, y también la factura.

La página de trabajos les dice a los implementadores que revisen entradas, limiten quién puede llamar qué, topen las tormentas de reintentos y traten las respuestas del asistente como no confiables. Nada de eso llega con la conexión MCP. Cada ítem es trabajo que construye su equipo.

La sección de acceso de la misma revisión de MCP se apoya en la plomería de acceso ordinaria para que una credencial pueda llegar por HTTP y rechazarse cuando falta o es demasiado débil. Qué trabajos debería poder empezar ese acceso vive fuera de la especificación, fuera de su proveedor de acceso y fuera del kit que instaló. Es un juicio que su negocio toma una vez y luego tiene que defender.

Las notas de seguridad existen porque los implementadores siguen asumiendo que el formato del cable está haciendo el trabajo de seguridad. Un acceso atado a la audiencia equivocada, una sesión adivinable, un ID de cliente estático: esas son las formas habituales en que una demo que funciona se vuelve un incidente. Lea las notas. No trate la versión de MCP como un programa de controles.

Algo cambió en diciembre de 2025 que hizo esto urgente. Google empezó a desplegar conexiones MCP alojadas empezando por Maps y BigQuery, bajo la frase «agent-ready by design». Cloudflare envió una forma de una línea de exponer un método por una llamada remota. Cuando las plataformas hacen de la exposición un default de una línea, la decisión de alcance deja de ser una fase de diseño. Se vuelve algo que un desarrollador hace a mitad de un sprint sin decírselo a nadie.

Permita cuatro trabajos, niegue tres, confirme uno

Aquí está la división que defendemos, y el razonamiento importa más que la lista.

Permitidos, de solo lectura:

Negados de plano: pagos y reembolsos, ediciones destructivas y eliminaciones, exportación masiva de cualquier cosa personal. No vamos a construir esos como trabajos invocables por un agente, a ningún presupuesto. El peor resultado de esos trabajos es una acción equivocada. Endurecer las indicaciones no mueve un trabajo al otro lado de esa línea.

Un tramo del medio: creación de borrador. Un asistente puede proponer una reserva, un ticket o un pedido. Una persona lo confirma. MCP tiene un paso de confirmación integrado (preguntarle a la persona a mitad del trabajo y dejar que esa persona edite la respuesta). La mayoría de las implementaciones se saltan ese paso.

Permita trabajos cuyo peor resultado es una respuesta equivocada. Niegue trabajos cuyo peor resultado es una acción equivocada.

Aquí no sigue ninguna construcción de servidor. El código es la parte que su equipo ya puede escribir. Si está precificando el trabajo, cuánto cuestan de verdad los agentes de IA y construir frente a comprar son más útiles que otro tutorial.

Déle a cada trabajo su propia clave

Cuatro defaults siguen de tratar al llamante como una máquina.

Un acceso por trabajo, no uno por integración. Una credencial que lee facturas no debería llegar a tickets.

Ate el acceso a la cuenta. El asistente solo es el mensajero. A los mensajeros los cambian, los retiran y los adquieren.

Límites de tasa dimensionados para algo que nunca se aburre. Un humano se rinde después de tres intentos. Un asistente reintenta hasta que se queda sin tokens, las unidades facturadas que un modelo gasta en una indicación. Ponga claves de idempotencia en cualquier cosa que escriba, para que la segunda llamada idéntica aterrice como una no-operación.

Déle a cada credencial de trabajo una fecha de vencimiento, para que la revocación se quede como mantenimiento rutinario.

Y registre el nombre del trabajo, los argumentos, la identidad del llamante y el cambio de estado resultante, en un solo lugar. Ese es el artefacto que decide si una semana mala es una tarde mala. Si compras va a preguntar por esto, un piloto de agente que sobrevive a compras cubre lo que compras lee.

El bucle aburrido cuesta más que el ataque ingenioso

Todos planean para la indicación adversaria. El fallo más opaco cuesta más.

Digamos que un trabajo toma un parámetro ambiguo. Un asistente lo llama. La respuesta se ve incompleta, así que adivina un valor un poco distinto y llama de nuevo. Nada se filtra. No se abusa de ninguna credencial. La cola se llena de registros casi idénticos, y el daño es volumen y conciliación.

El mecanismo está documentado. Un estudio de servidores de producción que exponen trabajos a asistentes lo dice de forma directa: los modelos eligen trabajos solo a partir de las descripciones en lenguaje llano, saltándose la documentación y los esquemas. Un trabajo que un ingeniero encuentra obvio puede ser ambiguo para el llamante.

Así que el default es una cuota por llamante y un esquema de argumentos que niega de plano los valores ambiguos. Un parámetro con tres lecturas plausibles es un bug.

También nos negamos a reportar «acciones resueltas por un asistente» como métrica de éxito. Cuenta llamadas que ocurrieron, no decisiones que fueron correctas, y es el número más probable de hacer que una superficie peligrosa se vea como una victoria en una carpeta de directorio.

Cómo se ve el nuestro, para que usted pueda comprobarlo

Nuestro propio sitio es invocable por un agente, y la superficie es chica a propósito. mcp.strataigize.com responde a tools/list del protocolo de asistente con ocho trabajos: siete lecturas públicas (quiénes somos, nuestros servicios, casos, herramientas gratis, una búsqueda de contenido, cómo contratar, una recuperación de página) y una acción autenticada, pedir una consulta de crecimiento en nombre de una persona nombrada, bajo un solo alcance llamado audit:request. Nada en ese servidor puede mover dinero, exportar una lista o cambiar un registro. El documento de recurso protegido nombra el servidor de autorización, y un auth.md en texto plano lo explica todo; ambos están donde un asistente mira primero. Recuperamos el servidor, su lista de trabajos, ese documento y auth.md el 13 de septiembre de 2026 para escribir este párrafo, y usted también puede recuperarlos.

El número compañero honesto: en los siete días al 6 de septiembre de 2026, nuestros logs no mostraron que ningún cliente asistente externo lo hubiera llamado. Construir la superficie y que el mercado la use son eventos distintos, y solo el segundo cuenta como adopción.

Escriba primero la lista de negativa

La mayoría de los equipos dimensiona esto como un proyecto de integración: acotarlo como un conector, entregárselo a quien posee la API, enviarlo en un sprint. Dimensionado así, la decisión de permisos igual se toma. Se toma por default, por quien escribió la descripción del trabajo, y nadie firma la lista.

Dimensiónelo en cambio por lo que defendería por escrito después de la peor llamada que permiten sus logs. Empiece por la lista de negativa. Escriba los tres trabajos que un asistente nunca va a empezar antes de los cuatro que sí, y haga de esa lista un documento que firmen su CTO y su abogado, fechado, junto a la revisión de MCP del 18 de junio de 2025 contra la que construyó.

Para la mayoría de los negocios la respuesta es una superficie chica de solo lectura, un tramo de borrador que una persona confirma, y pagos y exportación masiva que un asistente nunca puede empezar. Esa versión hace una peor demo y un fin de semana más seguro.

Escriba primero la lista de negativa. Luego vaya a hallar el trabajo ya conectado que no pertenece a la lista. Si quiere esa superficie diseñada y no adivinada, empiece por consultoría de IA. La versión pública de lo que enviamos es superficies invocables por un agente.