Mínimo privilegio y autorización, quitar capacidades le gana a vigilarlas

Una plantilla interna conecta cada agente nuevo a los nueve servidores MCP de la empresa, con permisos de lectura y escritura, “para que nadie se quede trabado”. Meses después, un agente que solo tenía que resumir una reunión publica las notas en un canal de toda la empresa porque un documento se lo pidió. Nadie lo atacó con sofisticación: tenía la capacidad y la usó.

Exceso de capacidades

El exceso de capacidades (capability bloat) aparece de dos formas, y las dos se arreglan sacando, no sumando:

• Herramientas que el rol no usa. Un agente de soporte que lee tickets y redacta respuestas no necesita reembolsar ni borrar cuentas. Cada herramienta de más es superficie de ataque y tokens gastados en cada pedido.
• Herramientas superpuestas (overlapping tools). Tres herramientas de búsqueda sobre el mismo índice, con descripciones casi iguales, hacen que el modelo llame a varias, repita búsquedas o elija la equivocada. Consolidalas en una sola con parámetros claros.

La regla es el mínimo privilegio (least privilege): cada agente recibe solo las herramientas, los servidores y los permisos que su rol necesita, y credenciales de solo lectura donde alcanza con leer. Así, aunque una inyección de prompt vuelva a aparecer, el daño posible es mínimo.

Controles que eliminan y controles que compensan

Control	Qué hace con el riesgo
Quitar la herramienta o el permiso	Lo elimina
Credenciales de solo lectura, alcances mínimos	Lo acota
Confirmación humana antes de la acción	Lo compensa
Logs y auditoría	Lo detecta después
Instrucción en el prompt (“nunca publiques”)	Lo sugiere

Las confirmaciones y los logs son útiles como capas extra, pero si el rol no necesita la capacidad, la respuesta correcta es quitarla.

Autorización: con la identidad de quien pregunta

El otro hueco clásico está en cómo el servidor llega a los datos. Si un servidor MCP accede a la API de recursos humanos con una cuenta de servicio (service account) que ve todos los legajos, cualquier usuario puede pedir el sueldo de un colega y recibirlo. Un filtro sobre la respuesta o una línea en el system prompt no arreglan eso: el modelo ya tiene el dato.

La autorización se hace con la identidad del usuario final (por ejemplo, con un token delegado) y se aplica en la capa de datos, donde ya viven las reglas de acceso. El modelo nunca debería poder traer algo que el usuario no puede ver.

En un servidor MCP remoto con OAuth hay dos reglas de la especificación que el examen usa:

• El servidor valida la audiencia del token (token audience): acepta solo tokens emitidos para él. Firma válida y vigencia no alcanzan.
• El reenvío del token (token passthrough) está prohibido: si el servidor tiene que llamar a otra API, lo hace como cliente, con un token propio para esa API, no con el que recibió.

Las trampas típicas

• Loguear las herramientas peligrosas “para auditar después” en lugar de quitarlas.
• Pedir confirmación humana para cada llamada, incluso las lecturas: frena todo y la gente termina aprobando sin mirar.
• Compensar herramientas superpuestas con ejemplos en el prompt o con un router delante.
• Pasar a un modelo más grande “que sigue mejor las instrucciones”: el tamaño no cambia el alcance de los permisos.
• Cerrar un hueco de autorización con una instrucción en el prompt o un filtro de salida.
• Mover el token a la URL o alargar su vigencia.

En el examen

Si el escenario lista lo que el rol “solo necesita” y lo que el agente “también puede” hacer, buscá la opción que quita lo que sobra. Si describe que un usuario vio datos ajenos, buscá dónde se pierde la identidad del usuario: la respuesta es propagarla y hacer cumplir el acceso en la API, no en el modelo. Y si aparece un token que se acepta “aunque fue emitido para otro servicio”, la respuesta combina validar la audiencia y usar un token propio aguas abajo.