Un agente que puede borrar, va a borrar
Exponer una API para que un modelo la llame lleva una tarde. Lo difícil es todo lo que viene después: un agente reintenta, improvisa, y actúa en nombre de alguien cuyos permisos no tiene. Construimos la capa que hace eso seguro, y demostrable más adelante.
Hablar con un ingenieroCuándo nos llaman
- A un agente le dieron una herramienta que escribe, y ahora nadie puede decir qué cambios vinieron de una persona y cuáles del modelo.
- El agente reintentó tras un tiempo de espera y la operación corrió dos veces. Era un cobro.
- El acceso a las herramientas está acotado a la integración y no al usuario que preguntó, así que el agente alcanza datos que esa persona nunca habría podido abrir.
- El modelo llama a una herramienta con argumentos que son JSON válido y un disparate, y el sistema los ejecuta.
- No hay techo: un bucle mal cerrado y el agente se gasta el presupuesto del mes antes del mediodía.
- Alguien pregunta qué hizo el agente el martes pasado y la respuesta está en una transcripción de chat, no en un registro.
Qué construimos
Permisos que siguen a la persona, no a la integración
El agente actúa en nombre de alguien, así que tiene que poder hacer exactamente lo que esa persona puede y nada más. Acotar el acceso a la integración es lo que sale por defecto y es el error: convierte a cada usuario en tan poderoso como el más poderoso.
Operaciones que sobreviven a un reintento
Claves de idempotencia en todo lo que escribe, para que una llamada repetida sea inofensiva en vez de cara. Los agentes reintentan por diseño cuando se agota el tiempo, y que se agote no significa que la operación no haya ocurrido.
Un radio de daño acotado
Operaciones destructivas detrás de una confirmación, límites de cuánto puede cambiar una sola sesión, y una forma definida de deshacer. La pregunta no es si el agente va a hacer algo no previsto, sino cuánto cuesta cuando lo haga.
Interfaces que un modelo pueda usar de verdad
Descripciones y esquemas escritos para un lector sin contexto, y errores que dicen qué hacer en lugar de qué falló. Una descripción vaga produce una llamada equivocada hecha con seguridad.
Atribución que aguante después
Cada acción registrada con el agente, la versión del modelo, la persona por la que actuó y la entrada que lo disparó. Es el mismo problema de evidencia que el resto de la IA en producción, con un actor más en la cadena.
Proyectos típicos
Exponer un sistema existente a agentes, con seguridad
Un servidor MCP o una interfaz de herramientas sobre lo que ya corrés, con permisos, idempotencia y límites diseñados de entrada y no agregados después del primer incidente.
Auditar una integración con agentes ya en producción
Encontrar qué alcanza el agente que no debería, qué pasa al reintentar, y qué evidencia existe de lo que hizo. Alcance cerrado, informe escrito.
Agregar atribución a las acciones del agente
Sumar registro para que cada cambio sea rastreable hasta el agente, la versión del modelo y la persona detrás.
Ponerle techo al gasto del agente
Límites de presupuesto que cortan en lugar de avisar, por sesión y por período, con comportamiento definido al alcanzar el techo.
Qué se lleva
- Una interfaz de herramientas que tus agentes puedan usar y tu equipo de seguridad pueda explicar
- Permisos derivados del usuario que pregunta, demostrados con pruebas
- Idempotencia en cada camino de escritura, con el caso de reintento cubierto
- Techos de gasto y de frecuencia que cortan en lugar de notificar
- Un registro donde cada acción del agente nombra al modelo, a la persona y al disparador
Preguntas que nos hacen
¿Esto es simplemente MCP?
MCP es una forma de exponer la interfaz, y es buena. Pero el protocolo es la mitad fácil: estandariza cómo un modelo descubre y llama a tus herramientas, no quién puede llamar a qué, qué pasa en un reintento, ni cómo demostrás después qué se hizo. Esas son las partes que se rompen.
Nuestro agente sólo lee. ¿Igual hace falta?
El acceso de lectura es donde más duele el problema de permisos. Si la recuperación no está acotada al usuario que pregunta, un agente que sólo lee igual puede armar una respuesta con documentos que esa persona nunca tuvo permiso de abrir —y lo va a hacer de manera convincente—.
¿En qué se diferencia del trabajo de sistemas de IA auditables?
Mismo problema de evidencia, un actor más. Allá la pregunta es qué vio y qué produjo el modelo. Acá el agente además actúa: cambia cosas. Así que la atribución tiene que contestar no sólo qué se dijo sino qué se hizo, quién y en nombre de quién.
Los estándares se están moviendo. ¿No es muy temprano?
Se mueven los protocolos; los modos de falla no. Permisos, idempotencia, radio de daño y atribución eran las partes difíciles antes de que existieran los agentes y lo van a seguir siendo cuando el protocolo cambie de nombre. Construir contra eso no es apostar a un estándar.
Iniciar una conversación
Cuéntenos qué están construyendo, o qué se está rompiendo. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.