Tokens MCP

El token que usa un agente para hablar con WhyStack es un PAT, un personal access token. Da acceso de lectura a toda tu infraestructura, a través del Agent que corre dentro de ella. Es una credencial de primera clase, y esta página es lo que necesitas para emitir una sin arrepentirte.

El token pertenece a una persona, no a la organización

Eso tiene una consecuencia que precede a cualquier decisión de alcance: un token sin dueño es siempre de solo lectura. Los tokens emitidos fuera de un usuario (por la CLI de operaciones, o heredados de antes de que los tokens fueran personales) no tienen identidad a la cual atribuir, así que el gate de escritura falla cerrado y nunca escriben. Si lo que quieres es un agente que abra tickets, el token tiene que pertenecer a alguien.

Dos puertas en serie

Escribir pasa por dos verificaciones independientes, y pasar una no es pasar la otra:

El alcance del token: read o write, elegido al emitirlo.
El rol del dueño: el permiso mcp:write, que pertenece a owner y admin.

El alcance es una restricción adicional, nunca una promoción:

Alcance del token	Rol del dueño	Resultado
`read`	owner / admin	Solo lectura
`read`	member	Solo lectura
`write`	owner / admin	Lectura más las cinco tools de escritura
`write`	member	Solo lectura
cualquiera	sin dueño (CLI/legado)	Solo lectura

La puerta del rol es la que falla cerrada. Un usuario inactivo, un rol que no se resuelve, un error de consulta: todos niegan la escritura en vez de permitirla. La puerta del alcance solo sabe bloquear, y por eso es una restricción extra y nunca la única.

Entonces, ¿por qué alguien elegiría write? Por una razón concreta: esa persona quiere que su agente abra un ticket en Jira o publique en Slack durante una investigación, sin salir del flujo. Si no, read es la respuesta correcta, y es el valor por defecto del formulario de emisión, a propósito. Lo que desbloquea exactamente un token write está en lo que escribe el agente.

Se muestra una vez

Al crearlo, el valor crudo del token aparece exactamente una vez. Lo que persiste en nuestra base de datos es solo su sha256.

No hay recuperación. No hay pantalla de “mostrar el token otra vez”, ni camino de soporte que pueda extraerlo: literalmente no lo tenemos. Si se pierde, el camino es revocarlo y emitir otro.

Solicitud → aprobación → claim

Un member no tiene que volverse admin para tener acceso al MCP. Pide, alguien autoriza, y lo genera por su cuenta:

Estado	Qué ya pasó	Qué falta
`pending`	El solicitante pidió (nombre, alcance, motivo)	Que un owner/admin revise
`approved`	Un owner/admin autorizó el nombre y el alcance	El solicitante todavía tiene que generar el token
`claimed`	El solicitante lo generó y vio el valor, una vez	Nada; el token existe
`denied`	Un owner/admin lo rechazó	Nada; la solicitud está cerrada

El estado que confunde es approved, y merece decirse con todas las letras: aprobado no es tener un token. La aprobación autoriza; el token solo empieza a existir cuando el solicitante lo genera. Hasta entonces, no se creó ningún secreto.

Dónde actúa cada lado: quien solicita y después genera ve sus solicitudes en su perfil; quien revisa ve la cola en Gobernanza.

Generar dos veces a partir de la misma solicitud no puede ocurrir: la transición approved → claimed es atómica, así que dos intentos simultáneos producen exactamente un token.

Revocación

La revocación es soft: el token se marca como revocado, y la fila se queda por la pista. Tiene alcance de organización (no puedes revocar el token de otra org) y se convierte en un evento de auditoría.

El efecto es inmediato en la práctica: la identidad del token se resuelve en cada request, no solo cuando se abre la sesión. Una sesión MCP en curso con un token revocado muere en la llamada siguiente, con 401. No hace falta esperar a que nada expire.

Cómo saber si un token está vivo

Existen dos columnas de metadatos exactamente para esto, y las dos son lo que separa un “token olvidado” de un “token que alguien está usando”:

Último uso. Se actualiza cuando el token se autentica (con una ventana de un minuto, para no escribir en cada request). Un token que nadie usó en meses es candidato a revocación, y es la lista de higiene más barata que hay aquí.
Origen observado. La dirección de red desde la que ese token nos llegó por última vez. Es como se vuelve visible un uso desde un lugar que nadie esperaba, y es por donde empiezas al configurar la allowlist de origen de red, en vez de adivinar el bloque. Guardamos solo la última dirección, se borra junto con el token al revocarlo, y desaparece sola después de 90 días sin repetirse; quien no quiera el registro puede desactivarlo, en la pantalla de la allowlist.

Dónde se filtran los tokens

No son hipótesis; son los tres de siempre:

Un .mcp.json commiteado. El archivo de configuración del cliente MCP vive en el directorio del proyecto. Si el token literal está adentro, entra al repositorio y sigue siendo válido en el historial después de “eliminarlo”.
Logs de CI. Un echo de variables, un comando con --verbose, un dump del entorno de un paso que falló.
Backups de laptops. Directorios de proyecto que se sincronizan con un almacenamiento personal en la nube.

Ante la sospecha, revoca. Es la única respuesta que cierra el agujero. La allowlist de origen de red achica la ventana (un token filtrado deja de alcanzar, porque también hace falta estar en tu red), pero no reemplaza la rotación, y quien tenga a la vez el token y acceso a la red permitida sigue pasando.

Qué queda registrado

La emisión, la revocación y cada paso del flujo de solicitud se convierten en eventos en la pista de auditoría de tu organización, con el actor. Las escrituras hechas con el token son una pista aparte, atribuida por usuario. Consulta lo que escribe el agente.