Safe defaults

Los agentes son rápidos. Eso es bueno cuando hacés algo bien y malo cuando hacés algo mal — los errores también escalan. El stack de Prysm:ID limita el blast radius en tres capas: autenticación scopeada al humano, confirmación humana en operaciones destructivas, y paridad estricta con la API REST (sin “modos especiales” del MCP que la API no permita).

Capa 1 — Autenticación: el agente actúa como vos

El MCP server (@prysmid/mcp) se autentica vía device flow (RFC 8628). Vos te logueás una vez en auth.prysmid.com y el server cachea un access_token (~12 horas) + refresh_token (~30 días) en ~/.config/prysmid-mcp/token.json.

Consecuencias:

El agente solo puede operar workspaces a los que vos tenés acceso. No es una “service key” universal — son tus credenciales delegadas vía OAuth, así que el server-side aplica las mismas validaciones que aplica al dashboard.
Cada workspace endpoint valida membresía. Aunque el agente conozca el slug de un workspace ajeno, el handler retorna 404 (no 403, para no leakear existencia) — mismo trato que el dashboard.
Revocás cuando querés. Cerrá tu sesión Prysm:ID o borrá el token.json; el agente queda sin auth.
El audit log marca cada acción con actor=user:<tu-email>. No hay un actor bot separado por design — sabés que pasó porque la herramienta lo hizo en tu nombre.

Capa 2 — Confirmación humana en destructivos

Los handoff prompts oficiales (Claude Code ES/EN, Antigravity ES/EN) instruyen explícitamente al agente:

Para acciones destructivas (delete_workspace, delete_oidc_app, delete_idp), pedíme confirmación EXPLÍCITA antes de cada llamada — perdería users + apps + IdPs irreversiblemente.

El agente no auto-confirma. Si decís “no” o “esperá”, el agente para.

Operaciones que el prompt marca como destructivas

Tool	Por qué
`delete_workspace`	Irreversible. Borra la instance entera de Zitadel + DNS + SMTP.
`delete_oidc_app`	Romperás logins activos de esa app.
`delete_idp`	Si era el único IdP y password+register estaba off, dejarías el workspace sin método de login.
`delete_user`	Pierde sesiones, attribution histórico, etc.
`set_spending_cap` cuando reduce el cap por debajo del uso actual	Puede cortar facturación abruptamente.

Operaciones que NO requieren confirmación (y por qué)

Acción	Por qué
Cualquier creación reversible (`create_workspace`, `create_oidc_app`, `add_idp`)	Si el agente creó algo de más, lo borrás. Costo bajo.
Lecturas (`list_`, `get_`)	Obvio.
`update_branding`	Cambiar logo / colores no es destructivo; reversible en una llamada.
`update_login_policy`	Las curated tools auto-promueven el override per-org sin tocar otras orgs; cambios son reversibles vía PATCH.
`set_spending_cap` upward	Pagar más nunca rompió un cliente (cost: dejas overage cap más alto, reversible).

Capa 3 — Paridad estricta con la API REST

El MCP server no tiene “modos especiales”. Toda tool MCP termina haciendo exactamente la misma llamada HTTP que haría el dashboard a api.prysmid.com. Esto significa:

No hay un endpoint del MCP que el browser no pueda hacer. Si el dashboard no te deja borrar X sin confirmar en un modal, el agente tampoco puede hacerlo silenciosamente — el handler 4xx-ea con la misma validación.
Los rate limits son los mismos. Un agente desbocado intentando crear 1000 workspaces va a topar con el cap de la API REST, no uno especial del MCP.
El audit log es uno solo. Tanto la actividad del dashboard como la del agente aparecen en el mismo feed con el mismo actor=user:<email>.

Auditoría de qué hizo tu agente

En app.prysmid.com → audit (cuando el panel exista — hoy es vía API), filtrá por:

Tu email como actor → ves todo lo que pasó “como vos”, incluyendo las acciones del agente.
Ventana temporal de la sesión del agente → todo lo del agente queda agrupado.

No hay un flag via_mcp separado en el audit log porque el agente es vos vía device flow. Si necesitás distinguir, marcá tu workspace de pruebas vs el de prod, y trabajá con agentes solo en el de pruebas hasta que confíes.

Roadmap

Approval queues: para teams donde un agente propone cambios y un humano otro aprueba (no el que está hablando con el agente). En diseño.
Service accounts expuestos como producto: machine keys con scope acotado, expiración explícita, audit actor=key:<id>. Pendiente.
Per-tool fine-grained scopes: hoy el access_token tiene un scope amplio (todo lo que tu cuenta puede ver). Discutiendo si tiene sentido un scope read-only para agentes side-by-side.

Filosofía

El agente es usuario de primera clase. Pero “primera clase” no significa “sin guardrails”. Significa el mismo respeto y la misma desconfianza inteligente que aplicás a un colega nuevo con acceso producción.

Las gates no están para frenarte — están para que cuando un día tu agente alucine, el blast radius sea recuperable, no terminal.