La primera regla de un sistema que pueden usar agentes es no darles más poder del que necesitan. Ese criterio guio el diseño de la API y el servidor MCP de mi sitio personal.
El objetivo es que el software y los agentes puedan consultar de forma segura el contexto público del sitio. Añadir acceso para agentes no requiere convertir cada función del sitio en una función de IA.
Datos públicos y datos privados
La primera decisión de seguridad es definir qué pertenece a la interfaz pública.
En mi sitio, los datos públicos incluyen:
- información del perfil;
- proyectos públicos;
- productos públicos;
- notas publicadas;
- enlaces públicos;
- campos de estado públicos;
- capturas públicas.
Los datos privados deben quedar fuera:
- borradores de notas;
- registros de administración;
- detalles de analíticas;
- datos de facturación;
- secretos;
- datos privados de clientes;
- estado interno del panel;
- planes de productos sin publicar.
Parece obvio, pero los sistemas consultables por agentes hacen más importante ese límite. Cuando una herramienta existe, las personas y los agentes intentarán usarla. La opción más segura es que la herramienta no pueda acceder a datos privados desde el principio.
Empieza por el acceso de solo lectura
Para el servidor MCP de un sitio personal, las herramientas de solo lectura bastan.
Las preguntas útiles consisten en consultar información:
- ¿Quién es Orlando?
- ¿Qué ha construido?
- ¿Qué productos ha publicado?
- ¿Qué notas ha escrito?
- ¿Qué proyectos usan una tecnología concreta?
Ninguna requiere permiso para escribir.
Por eso las herramientas MCP deben recuperar contexto público sin modificar el estado del sistema.
Evitaría herramientas destructivas, acciones de administración y operaciones como «actualizar perfil» o «eliminar nota». Tampoco añadiría «enviar correo» sin un modelo de permisos muy claro. El acceso de solo lectura mantiene pequeña la superficie de riesgo.
Valida todas las entradas
Las herramientas para agentes también necesitan validar sus entradas. Con los agentes, hay más razones para hacerlo.
Los modelos pueden enviar:
- slugs inválidos;
- valores inesperados para una enumeración;
- consultas demasiado amplias;
- cadenas mal formadas;
- valores de idioma confusos.
La validación debe ocurrir en la entrada del sistema. Por ejemplo:
- los slugs deben corresponder a contenido conocido;
- los estados deben pertenecer a enumeraciones finitas;
- el idioma debe tener una alternativa segura;
- los límites deben tener valores máximos;
- los filtros desconocidos no deben cambiar el comportamiento en silencio.
No confíes en que el modelo enviará siempre argumentos correctos. Trátalo como a cualquier otro cliente.
Los límites de peticiones siguen siendo necesarios
Los endpoints públicos de lectura deberían tener límites de peticiones, incluso en un sitio personal pequeño.
Los agentes de IA, rastreadores, scripts y experimentos pueden generar más tráfico del esperado. Los límites hacen más previsible el servicio público.
Las reglas deben estar visibles:
- cuántas peticiones se permiten;
- cuándo se reinicia la ventana;
- cuándo debería reintentar un cliente.
Las cabeceras que comunican esos límites forman parte de la experiencia del desarrollador y del modelo de seguridad.
Adapta CORS a cada endpoint
CORS no es un sistema de seguridad completo, pero hay que configurarlo según el uso.
Para endpoints de lectura pública, una configuración permisiva puede ser razonable porque el contenido ya es público.
Para endpoints privados o de administración, la configuración debería ser mucho más restrictiva.
El error es tratar todas las rutas igual. Los endpoints de contenido público y los de operaciones privadas tienen riesgos distintos y necesitan supuestos distintos.
Evita filtrar borradores
Filtrar borradores por accidente es uno de los errores más fáciles de cometer en sistemas basados en contenido.
Si el directorio mezcla trabajo publicado y sin publicar, la API y la capa MCP deben respetar esa separación.
Una página puede ocultar los borradores mientras un endpoint enumera todo porque lee el directorio directamente.
La regla:
If it is not meant to be public, it should be filtered before it reaches any public interface.
Si un contenido no debe ser público, hay que filtrarlo antes de que llegue a cualquier interfaz pública.
Eso incluye:
- respuestas de la API;
- resultados de herramientas MCP;
- índices de búsqueda;
- canales RSS;
- generación del sitemap;
- datos estructurados.
Una sola fuente de contenido puede alimentar muchas salidas. Por eso el límite de publicación debe ser explícito.
No filtres secretos mediante los resúmenes
Los sistemas pensados para agentes suelen añadir resúmenes.
Me gusta ese patrón. Las respuestas de mi API incluyen campos ai_summary para ayudar a los agentes a entender qué recibieron.
Esos resúmenes necesitan respetar el mismo límite de acceso que los datos originales.
No generes resúmenes a partir de datos que el usuario no debería ver. No incluyas metadatos privados en un texto supuestamente útil. No conviertas el estado interno en un resumen público. El resumen también es una salida del sistema.
Las descripciones deben aclarar el alcance
Las descripciones de las herramientas MCP también forman parte de la seguridad. No deberían insinuar que la herramienta tiene un acceso que no existe.
Una descripción insuficiente:
Gets all information about Orlando.
«Obtiene toda la información sobre Orlando» sugiere un acceso demasiado amplio.
Una descripción más precisa:
Returns public profile information for Orlando Ascanio. Does not include private contact records, analytics, drafts, or admin data.
Aclara que devuelve información pública del perfil y excluye contactos privados, analíticas, borradores y datos de administración.
Ese límite ayuda al modelo a responder con honestidad y al usuario a entender qué puede consultar la herramienta.
Limita lo que puede hacer cada herramienta
Cuantas más cosas puede hacer una herramienta, más difícil resulta razonar sobre ella.
Para un sitio personal, las herramientas concretas son más seguras:
get_projects
get_project
get_products
get_product
get_notes
get_note
get_orlando_bio
Cada una recupera una clase específica de contenido público.
Eso es más fácil de validar, documentar, probar y supervisar que una herramienta enorme con un comportamiento vago. La seguridad y la claridad suelen mejorar juntas.
Qué evitaría
En este tipo de sistema evitaría:
- herramientas MCP con capacidad de escritura;
- herramientas que desencadenan efectos externos;
- exponer paneles de administración mediante MCP;
- devolver variables de entorno sin filtrar;
- indexar borradores sin publicar;
- aceptar rutas arbitrarias de archivos;
- aceptar URL arbitrarias para hacer peticiones;
- nombres de herramientas que sugieran acceso ilimitado.
La mayoría no son necesarias para un sitio personal, así que no deberían estar disponibles.
La lección principal
Hacer que un sitio personal sea legible para los agentes consiste en exponer el contexto público adecuado mediante interfaces estables y limitadas.
La versión más segura también es la más clara:
Public content in.
Structured public context out.
No private state.
No destructive tools.
No unnecessary permissions.
Entra contenido público y sale contexto público estructurado. No se expone estado privado ni hay herramientas destructivas o permisos innecesarios.
Eso basta para que el sitio sea útil a los agentes sin convertirlo en un panel de control abierto. Un sistema legible, estructurado y con límites claros deja espacio para evolucionar.
Un pequeño voto de confianza
¿Valió la pena leer esta nota?