Gestiona tu equipo desde tu agente

Team permite a un propietario o administrador leer la organización y proponer cambios desde un agente de programación como Claude Code o Codex: listar miembros, revisar el registro de auditoría, revocar un portátil perdido o endurecer la política. El agente nunca aplica un cambio por su cuenta. Cada escritura se convierte en un cambio pendiente que una persona aprueba fuera de la conversación.

zn-gate es una barrera de seguridad local, no un MDM. Los tokens de administrador de organización dan a un agente una forma acotada y revocable de ayudarte a administrar la organización; no dan a la organización control sobre la máquina de nadie.

Crear un token de administrador de organización

1. En el panel, abre Equipo → Tokens.
2. Asigna un nombre al token (por ejemplo laptop-claude), elige sus ámbitos y una caducidad de 7, 30 o 90 días.
3. Copia el token. Se muestra una sola vez. zn solo almacena un hash del token, por lo que no puede volver a mostrarse; si lo pierdes, revócalo y crea uno nuevo.

Los tokens empiezan por znorg_, para que los escáneres de secretos y el Scrubber de zn-gate puedan reconocerlos. La parte posterior a znorg_ hasta el siguiente _ es el prefijo público que se muestra en el panel y en el registro de actividad.

Límites:

• Hasta 10 tokens activos por organización y 5 por persona.
• Un token solo funciona mientras su creador siga siendo propietario o administrador. Si abandona la organización o pasa a ser miembro, el token deja de funcionar de inmediato y aparece como Inactive.
• Revocar un token surte efecto en la siguiente solicitud y cancela sus cambios pendientes. Los propietarios y administradores pueden revocar cualquier token de la organización.

Ámbitos

Los tokens nuevos empiezan con los ámbitos de lectura marcados. Añade ámbitos de escritura solo si quieres que el agente proponga cambios.

Un token hereda los límites de su creador: el token de un administrador no puede eliminar a otro administrador ni cambiar roles, porque los administradores tampoco pueden hacerlo. Los auditores pueden crear tokens limitados a audit:read y audit:export.

Ningún token, con independencia de sus ámbitos, puede:

• tocar la facturación, los puestos o la suscripción;
• crear, listar o revocar tokens, ni cambiar la configuración de la organización;
• crear tokens de unión ni aceptar invitaciones;
• aprobar o rechazar un cambio pendiente, incluido el suyo propio.

Conecta tu agente

Ejecuta estos comandos en tu propia terminal, no a través del agente.

# 1. Copy the token, then store it in the system keychain (read from the clipboard)
npx -y zn-gate team admin login --from-clipboard

# 2a. Claude Code
claude mcp add zn-gate -- npx -y zn-gate mcp

Para Codex, añade el servidor a ~/.codex/config.toml:

[mcp_servers.zn-gate]
command = "npx"
args = ["-y", "zn-gate", "mcp"]

zn-gate team admin login verifica el token con la API y lo guarda en el Llavero de macOS, el Administrador de credenciales de Windows o libsecret, fuera de la configuración del agente. zn-gate team admin status muestra qué organización y token están configurados (nunca el secreto), y zn-gate team admin logout lo elimina de la máquina. Revoca también el token en el panel si la máquina se pierde.

Las herramientas team_* solo aparecen en el agente cuando hay un token configurado, y únicamente las permitidas por sus ámbitos. ZN_LOCAL_ONLY=true las desactiva.

CI y máquinas sin llavero

Define ZN_ORG_TOKEN como secreto de CI o en tu shell. No lo pongas en la configuración MCP del agente (.mcp.json, ~/.codex/config.toml): el agente puede leer esos archivos.

export ZN_ORG_TOKEN=<paste the token here>

Qué puede hacer el agente

Herramientas de lectura: team_whoami, team_org_get, team_members_list, team_installs_list, team_policy_get, team_audit_query, team_audit_summary, team_activity_list, team_changes_list y team_change_status. team_audit_export escribe la exportación en ~/zn-exports/ y devuelve solo su ruta, el número de filas y el SHA-256, nunca el contenido.

Las herramientas de escritura proponen un cambio y devuelven su estado: team_member_invite, team_invitation_revoke, team_member_remove, team_member_set_role, team_install_revoke, team_policy_propose y team_change_cancel. El token nunca aparece en los resultados de las herramientas, en los errores ni en los registros; solo aparece su prefijo.

Cómo funcionan las aprobaciones

Cada escritura se guarda en el servidor como un cambio pendiente con un resumen y un resumen criptográfico (digest) de 8 caracteres, ambos calculados por el servidor a partir de los parámetros. El servidor también decide la clase del cambio; lo que envíe el agente se ignora.

Cambios que endurecen el acceso o que pueden deshacerse (eliminar a un miembro, revocar una invitación o una instalación, degradar a un administrador, invitar a un miembro, añadir una regla de denegación, eliminar hosts permitidos) los confirma una persona, en este orden:

1. un formulario de confirmación mostrado por el agente, si el cliente admite formularios de elicitación de MCP;
2. si no, un diálogo nativo del sistema, donde No es la opción predeterminada y la falta de respuesta en 2 minutos cuenta como no;
3. si no, un enlace a Equipo → Aprobaciones en el panel.

La confirmación en el agente debe producirse en un plazo de 10 minutos. El enlace del panel sigue siendo válido durante 72 horas.

Cambios que abren acceso o conceden privilegios (añadir hosts o comandos permitidos, eliminar o reordenar reglas, invitar a un administrador o ascender a alguien a administrador) solo se aprueban en el panel, en un plazo de 72 horas. Aprobar requiere un inicio de sesión de los últimos 10 minutos; si tu sesión es más antigua, el panel te pide que vuelvas a iniciar sesión. Conceder el rol de administrador solo puede aprobarlo el propietario. Cuando la organización usa Always approve in the dashboard, se exige ese mismo inicio de sesión reciente para cada cambio propuesto por un agente.

La página de aprobación muestra el resumen del servidor, el digest, qué token y cliente lo solicitaron y, en los cambios de política, las reglas antes y después. Una nota escrita por el agente se muestra al final y se marca como no verificada. Aprueba solo los cambios que tú pediste y comprueba que el digest coincide con el que muestra tu agente.

El servidor vuelve a comprobarlo todo cuando se aplica el cambio: el rol del creador, los ámbitos, la configuración de la organización y la versión de la política. Si la política cambió entretanto, el cambio falla y el agente debe proponerlo de nuevo.

Configuración de la organización: cambios del agente

En Equipo → Ajustes, el propietario elige cómo se aprueban los cambios del agente:

Registro de actividad

Equipo → Actividad enumera cada solicitud hecha con un token de organización, incluidas las lecturas, y cada cambio realizado en el panel. Cada entrada muestra quién actuó, si procedía del panel o via agent, el prefijo y el id del token, el cliente (por ejemplo claude-code 2.1.240), la acción y su resultado, incluidas las solicitudes rechazadas. Las direcciones IP no se almacenan. Ábrelo desde la fila de un token para ver solo ese token.

Servidor MCP remoto (próximamente)

Está previsto para una versión posterior un servidor MCP alojado en https://mcp.usezn.com/mcp, con inicio de sesión mediante tu cuenta de zn. Ofrecerá las mismas herramientas, y cada escritura se aprobará en el panel.

Límites

• Quien robe un token puede, hasta que caduque o sea revocado, hacer como máximo cambios del primer tipo: endurecer el acceso o cambios que pueden deshacerse desde el panel, y quedan registrados en el registro de actividad. No pueden modificar la política, conceder el rol de administrador, tocar la facturación ni crear tokens. Elige Always approve in the dashboard si quieres que cada cambio pase por una sesión con inicio de sesión.
• Una confirmación en el agente o en un diálogo del sistema protege contra una inyección de prompt que intente aprobar por sí sola. No protege contra software de la máquina que pueda controlar la interfaz de usuario.
• La aprobación solo sirve si la persona lee lo que aprueba. El resumen y el digest provienen del servidor, nunca del agente.