Desarrollar servidores MCP.
Conectar sistemas de forma selectiva.
Una IA puede trabajar de forma controlada con sistemas existentes. DAXS desarrolla servidores MCP y adaptadores adecuados con herramientas claras, permisos limitados y resultados verificables.
Un servidor MCP permite utilizar funciones definidas desde aplicaciones de IA.
Un asistente necesita consultar un ticket, buscar documentación autorizada o preparar una entrada mediante un acceso claro y limitado. DAXS desarrolla servidores MCP y las conexiones API correspondientes para los sistemas empresariales existentes.
El Model Context Protocol describe cómo las aplicaciones de IA pueden utilizar herramientas, recursos de datos y prompts preparados, entre otras funciones. Un servidor MCP es un adaptador técnico: la seguridad y la autonomía requieren un diseño que va más allá del nombre de la herramienta.
API clásica
Una aplicación llama a una función definida de otro sistema. Se planifican el modelo de datos, los permisos, la validación y la gestión de errores de ese acceso.
Integración MCP
Un cliente de IA compatible puede utilizar funciones y recursos descritos mediante un protocolo común. La autorización concreta y la aplicación en destino siguen siendo tareas propias.
Agente de IA
Una aplicación combina modelo, estado y herramientas en varios pasos. Necesita un encargo limitado, condiciones de parada y un control trazable de sus acciones. Puede utilizar MCP u otras API.
Cliente, interfaz y destino comprueban su propia área.
La aplicación de IA propone una llamada. El servidor MCP comprueba identidad, función permitida y entradas. El sistema de destino aplica además sus permisos. Para acciones críticas se verifica una autorización concreta antes de ejecutar.
Arquitectura de ejemplo para una integración individual. Las versiones de cliente, SDK y protocolo compatibles se definen y prueban antes de implantar.
El encargo determina los datos y las acciones.
Una interfaz de tickets puede entregar solo los campos necesarios para una consulta de estado autorizada. Otra herramienta puede crear únicamente un borrador. El acceso a la base completa o las funciones generales de shell, SQL o administración excederían esas tareas.
| Tipo | Posible herramienta | Comprobación importante |
|---|---|---|
| Lectura | Consultar el estado de un ticket, buscar documentación autorizada o consultar el estado técnico. | Comprobar que el usuario pueda ver el objeto; entregar solo campos y resultados necesarios, sin datos de otros tenants. |
| Escritura limitada | Preparar un borrador de respuesta o una nota interna estructurada. | Validar campos y contenidos, identificar el borrador, controlar reintentos y devolver un resultado trazable. |
| Crítica | Iniciar un cambio acordado en un sistema productivo. | Autorización adicional vinculada a acción y objeto; volver a comprobar permisos justo antes de ejecutar y definir límites y reversión. |
Una herramienta de lectura también puede revelar información confidencial y necesita autorización. Para escribir se planifican idempotencia, estados de error y resultados inciertos: un timeout no demuestra que la acción no se haya ejecutado.
Autenticarse y tener permiso sobre un objeto son comprobaciones distintas.
Distinguimos inicio de sesión en el cliente, autorización en el servidor MCP y permisos en destino. El contexto de usuario, grupo y tenant procede de una identidad fiable. El rol y el alcance permitido no se aceptan por una simple instrucción textual del modelo.
Una integración HTTP remota necesita un modelo de autorización adecuado. Se comprueban el destinatario, la vigencia y el alcance de los tokens. Las credenciales de sistemas posteriores se protegen y limitan para cada destino; el token del cliente no se reenvía como acceso universal.
Una conexión a un proceso local tiene límites distintos de un servicio remoto, como el programa iniciado, su procedencia y sus permisos del sistema operativo. Se revisan el programa y sus accesos a datos. En ambas modalidades se acuerdan conexiones permitidas y responsabilidades técnicas.
MCP necesita una arquitectura de seguridad completa a su alrededor.
Los límites se aplican mediante lógica del servidor, permisos del destino, credenciales protegidas, reglas de red y autorizaciones verificables. La implantación se adapta a cliente, datos, acciones y modelo operativo.
Los límites siguen vigentes ante propuestas inadecuadas del modelo.
Los documentos, tickets o resultados de herramientas pueden contener instrucciones manipuladas. Se tratan como datos y no pueden otorgar permisos ni justificar acciones bloqueadas. Los prompts ayudan a orientar la aplicación; el control vinculante se aplica fuera del modelo.
Entradas y destinos
Validar en el servidor tipos, valores, objetos, rutas y cantidades de resultados. Limitar las API y destinos de red permitidos; evitar comandos libres y peticiones a direcciones sin control.
Acciones y autorizaciones
Mostrar con claridad el alcance y los efectos. Vincular las autorizaciones críticas a la operación concreta, limitar su vigencia y verificarlas antes de ejecutar. Definir cancelación y reintentos.
Operación y trazabilidad
Prever límites de llamadas y tiempo, errores y registros con finalidad definida. Mantener las credenciales fuera del contexto del modelo y de las salidas de diagnóstico. Poder investigar accesos anómalos y revocar permisos.
Probamos procesos normales, accesos prohibidos, contenidos manipulados, permisos caducados, llamadas duplicadas y autorizaciones denegadas. Esto reduce riesgos y permite evaluar los límites de la protección frente a prompt injection.
Empezar por una función manejable.
Registramos la aplicación de destino, API existentes, roles y campos necesarios. Así se define un catálogo limitado de herramientas con entradas y resultados claros. Un piloto de lectura puede mostrar su utilidad; los pasos de escritura se añaden y comprueban por separado cuando procede.
- Delimitar el encargo: ¿qué problema, objetos y usuarios?
- Desarrollar la interfaz: conectar la API de destino, describir la herramienta y aplicar permisos y gestión de errores.
- Aceptación práctica: comprobar casos permitidos y prohibidos, autorizaciones y reintentos.
- Entrega con asistencia: documentar gestión de accesos, versiones y responsabilidades.
DAXS puede asumir este desarrollo e integración a medida. Una consulta de datos también puede resolverse adecuadamente con una API clásica o un script. Acordamos el alcance según sus sistemas.
Una función deseada concreta, la aplicación afectada, documentación API y un ejemplo anonimizado. Mantenga las credenciales y los datos confidenciales de clientes fuera de una consulta pública.
Lo aclaramos en una conversación.
¿Qué diferencia una API de MCP?
Una API proporciona funciones de un sistema. MCP define una forma común de ofrecer herramientas y contexto a clientes de IA compatibles. Un servidor MCP puede utilizar API existentes, conservando sus permisos y reglas funcionales.
¿Necesita toda automatización un agente de IA?
No. Una importación definida o un cálculo inequívoco suelen resolverse más fácilmente mediante un script o una API directa. Un agente puede encajar cuando las tareas variables requieren elegir pasos con flexibilidad.
¿Puede una herramienta MCP realizar cambios?
Sí, si se desea funcionalmente y se protege técnicamente. Lectura, cambios limitados y acciones críticas se tratan por separado. Cada función incluye autorizaciones, permisos de destino, validación y resultados trazables.
¿Basta iniciar sesión en el servicio de IA?
No. El servidor comprueba al solicitante y sus facultades; el destino debe permitir la función y el objeto concretos. La llamada a una herramienta conserva los límites de permisos del usuario.
¿Cómo empieza un piloto útil?
Con un beneficio claro y unas pocas herramientas limitadas, inicialmente de lectura cuando sea posible. Definimos criterios de éxito y probamos accesos no autorizados, contenidos problemáticos, tiempos de espera y llamadas repetidas antes de ampliar las funciones de escritura.
Acceder a una herramienta requiere también autorización operativa.
Un agente en Linux puede utilizar API, herramientas locales o servicios externos. Se planifican por separado su identidad de servicio, los accesos limitados a archivos, el aislamiento de procesos, los destinos de red permitidos y la gestión segura de credenciales. Un agente local no funciona necesariamente sin conexión: cada llamada externa forma parte del flujo de datos. También se prueban cambios de modelo, errores de herramientas, límites de ejecución y costes y una vía de interrupción trazable.
Profundizar en permisos y autorizaciones para agentes
Script, flujo de trabajo o agente de IA: preguntas para decidir
Hablemos de su caso de uso.
¿Qué debe ser más sencillo, qué datos intervienen y qué sistemas existen? A partir de ello definimos un inicio útil y un siguiente paso manejable.