English · Español

03 — Authn/Authz: la suposición de confianza local¶

🇪🇸 stdio entre procesos locales ya hereda los permisos del proceso padre — no hay autenticación que hacer. En cuanto MCP cruza la red, se necesita TLS, tokens, scopes, todo el aparato. Phase 31 vive en el primer mundo; Phase 33 (HTTP) cruza al segundo.

Esta página es corta por diseño: authn/authz sobre stdio es trivial, y authn/authz sobre HTTP es un problema de Fase 33/37 que aplazamos deliberadamente.

Qué significan "authn" y "authz"¶

Autenticación (authn): ¿quién eres?
Autorización (authz): ¿estás permitido hacer esto?

Una postura de seguridad correcta responde ambas preguntas antes de honrar ninguna petición. Las dos son independientes — autenticado pero no autorizado es el modo de fallo en producción más común (el usuario correcto, el permiso equivocado).

stdio hereda la identidad del padre¶

Cuando el cliente de la Fase 31 lanza el subproceso del servidor, el servidor hereda:

El mismo UID/GID que el cliente.
La misma visibilidad de filesystem (mismo chroot, mismo cgroup).
Las mismas variables de entorno (a menos que se filtren explícitamente).
El mismo namespace de red (a menos que se aísle explícitamente).

No hay pregunta separada de "¿quién me está llamando?" que el servidor tenga que hacer. El llamador es, por definición, la misma frontera de confianza que el servidor mismo. authn es "el proceso padre", y authz es "lo que sea que el proceso padre tenga permitido hacer".

Esto es a la vez la fortaleza y la debilidad de stdio:

Fortaleza: cero código de auth que escribir. No tokens, no TLS, no rotación. Lo que pueda hacer tu shell, lo puede hacer tu servidor MCP.
Debilidad: cualquier inyección de código en el proceso padre (el agente) es también una inyección de código en el servidor de tools. El sandbox de la Fase 32 tampoco ayuda aquí — el sandbox corre una tool, mientras que el servidor de tools corre todas las tools.

Para el alcance microscópico de la Fase 31 (4 tools de lookup de datos de solo lectura, sin red, sin escrituras de filesystem), la fortaleza gana. Para un agente de producción con tools que, por ejemplo, ejecutan comandos de shell o golpean una base de datos, el cálculo se invierte — y necesitas el sandbox de la Fase 32, el threat-modeling de la Fase 37, y (cuando entra HTTP) auth completa con session tokens.

Qué cambia cuando MCP pasa a HTTP¶

La Fase 33 expondrá el agente sobre HTTP. El agente seguirá hablando con el servidor de tools sobre stdio. Esa es la topología MCP recomendada — el servidor de tools se queda local; solo el agente como servicio está en la red.

Si expusiéramos MCP sobre HTTP (cosa que el protocolo soporta), necesitaríamos:

Seguridad de transporte. TLS para confidencialidad + integridad. mTLS para authn mutua.
Session tokens. Los bearer tokens OAuth 2.0 son la elección obvia; el transporte HTTP de MCP los recomienda.
Scopes por tool. "Este token puede llamar a conjugate pero no a run_shell." MCP no impone esto directamente; la capa de authz del servidor sí.
Rate limiting. Especialmente para tools que golpean servicios downstream. Basado en tokens o IP.
Audit logging. Cada tool call, quién la llamó, cuándo, con qué args, qué resultado. La Fase 34 (observabilidad) lo maneja para el agente; el servidor de tools contribuye con su traza.

No hacemos nada de esto en la Fase 31. La decisión está documentada; se revisita en la Fase 37 / 33.

Modelo de amenazas para la Fase 31 (una página)¶

Adversarios:

Un usuario local malicioso con el mismo UID que el agente. Ya tiene acceso completo; MCP no añade protección. Mitigación: no corras el agente como usuario privilegiado.
Una dependencia de tool comprometida. Una librería importada por lookup_spanish.py podría exfiltrar datos. Mitigación: versiones pineadas §A8, escaneo de lockfile con pip-audit (gate de Fase 0).
Una prompt injection en el input del modelo que cause que el agente llame a una tool con argumentos maliciosos. Territorio de Fase 32; las tools de la Fase 31 son de datos puros sin efectos secundarios, así que una llamada maliciosa malgasta CPU pero no escapa.
Un confused-deputy: el agente es engañado para llamar a una tool que no debería. Misma preocupación de Fase 32. Mitigación: sandbox por tool + las decisiones de permiso por tool viven en el agente, no en la tool misma.

De estos, solo el tercero y el cuarto importan en la Fase 31. Ambos esperan a la Fase 32.

Modelos de permisos¶

Dos patrones de diseño:

Basado en capacidades (capability-based). El agente recibe una lista de capacidades (tokens, descriptores de fichero, schemas firmados) al arranque; cada tool call requiere presentar la capacidad correspondiente. El agente no puede fabricar capacidades que no le fueron dadas. Esto es lo que aproxima el modelo MCP-con-OAuth de Anthropic.
Basado en ACL. Una tabla central de allow-list mapea (identidad-llamador, nombre-tool) → permitido/denegado. El servidor consulta la tabla en cada tools/call.

Para la Fase 31 no usamos ninguno — no hay identidad de llamador. La capa HTTP de la Fase 33 introducirá auth capability-based: el session token por petición lleva la lista de tools permitidas, y el agente rechaza tool calls fuera de esa lista.

Una nota sobre UX de permisos¶

En el Claude Code real, cada tool call muestra un prompt de permiso a menos que la tool esté en una allow-list. El usuario puede:

Permitir una vez.
Permitir para siempre (añade a la allow-list).
Denegar.

Esto está fuera del protocolo — es una política de UX del lado del cliente. MCP no lo dicta. La Fase 31 no implementa prompts de permiso (no hay usuario sentado en nuestro harness de pruebas). La Fase 33 podría añadirlos como parte de la superficie de serving.

Superficie de auth fase a fase¶

Fase	Superficie de auth	Qué hacemos
31	solo stdio, sin auth	Documentar la suposición.
32	Añadir sandbox por tool	Límites de recursos, sin salida de red.
33	HTTP para el agente	Añadir bearer tokens estilo OAuth; la capa de tools se queda en stdio.
34	Añadir audit logs	Cada tool call registrada.
37	Pasada completa de threat-modeling	Tests adversariales para inyección de args de tool, prompt injection.

Qué NO cubre esta página¶

Flujos OAuth específicos. Fase 33.
Implementación del sandbox. Fase 32.
Formato de audit log. Fase 34.
Pruebas adversariales. Fase 37.

Fin de la teoría. A lab/00-typed-tools.md.