Aprobaciones y seguridad

Un asistente que puede cambiar tu instancia no debería poder eliminar cosas por iniciativa propia. Gigantics se asegura de que una persona decida antes de que ocurra nada destructivo.

Primero una simulación

Leer siempre está permitido. Los cambios que no se pueden deshacer fácilmente, como eliminar un proyecto, un datasource o un usuario, cambiar los ajustes de autenticación, restablecer una contraseña o escribir en un destino real, son herramientas destructivas. Una herramienta destructiva nunca se ejecuta en la primera llamada: devuelve lo que cambiaría y no cambia nada.

Algunas herramientas son destructivas solo para ciertas peticiones. Conceder un rol de propietario, actualizar un datasource o un pipeline existente, o ejecutar una regla con un destino piden aprobación; un cambio inofensivo no.

Quién aprueba, y cómo

El asistente no puede aprobar por ti. Escribir "sí, confirmo" en la conversación, o que el asistente ponga confirm: true por su cuenta, no es una aprobación. Lo que ocurre a continuación depende de lo que pueda mostrar tu cliente de IA:

Cuál se aplica depende del cliente que uses y de su versión. Por ejemplo, algunos clientes muestran un panel, otros un diálogo, y algunos ninguno de los dos. No tienes que elegir: Gigantics escoge la opción más segura que tu cliente admite.

Ejemplo: crear un usuario con un panel de aprobación

1. Pides: "Crea un usuario para x@y.com."
2. El asistente prepara el cambio. Todavía no se crea nada. El resultado dice Create user x@y.com has not run yet: it needs the user's approval, y muestra un panel con Cancelar y Crear usuario.
3. Pulsas Crear usuario. El panel muestra Running "Create user"... y después el resultado.
4. El resultado se publica en la conversación (Approved and ran "Create user": User x@y.com created) y el asistente continúa sin que tengas que escribir nada.

Algunos detalles que te protegen:

• El panel ejecuta exactamente el cambio que viste, con los mismos valores. El asistente no puede cambiarlos después de que los hayas mirado.
• Un panel sirve para un solo cambio y es válido durante 5 minutos.
• Un diálogo respondido en menos de medio segundo se trata como una respuesta automática del cliente, no de una persona, y se rechaza.
• Eliminar una organización o un proyecto puede pedirte que escribas su nombre.
• Si el clic del panel nunca llega al cliente, el panel lo indica pasados 60 segundos.

Cuando el asistente no puede preguntarte

Si tu cliente no puede mostrar un diálogo ni un panel, o rechaza los diálogos automáticamente, el cambio se rechaza y no se hace nada. Todavía tienes dos formas de conseguirlo:

• Ejecutar tú mismo la misma operación con gig admin y --yes.
• Con el endpoint remoto, hacerlo en la interfaz de Gigantics.

Al asistente se le indica que no busque una forma de saltarse un rechazo ni que sugiera cambiar el modo de aprobación.

Modo agente

En el modo agente, el asistente puede confirmar sus propios cambios destructivos: no se pregunta a ninguna persona. Existe para clientes que no pueden mostrar un diálogo, para clientes que los rechazan automáticamente y para automatizaciones en las que confías plenamente.

Cómo activarlo:

La decisión siempre la toma la persona que configura la conexión, nunca el asistente.

Qué puede hacer el asistente

• Solo lo que la cuenta puede hacer. El servidor de Gigantics comprueba cada llamada con los roles de la cuenta: un usuario que inició sesión en local, o el usuario Root que hay detrás de una clave MCP. Las descripciones de las herramientas y las instrucciones nunca los amplían.
• Una operación prohibida termina ahí. Si recibe Access denied, el asistente informa de qué rol falta y quién podría concederlo. No prueba con otra cuenta.
• Las acciones de toda la instancia necesitan antes tu palabra. Eliminar organizaciones y proyectos, cambiar los Ajustes Globales, hacer Root a un usuario, eliminar usuarios o restablecer contraseñas también se confirman contigo en la conversación antes de pedir la aprobación.
• Los secretos siguen ocultos. Las contraseñas, las cookies de sesión, las claves de API, los secretos de OAuth, las contraseñas de LDAP y las claves SSH se sustituyen por <redacted> en los resultados. Cuando un secreto está definido, el asistente solo sabe que lo está. Los diálogos y paneles nunca piden un secreto: un secreto tiene que venir de tu propio mensaje.
• Un cambio cada vez. Tras un cambio, el asistente vuelve a leer el estado para comprobar que ocurrió.

Auditar lo ocurrido

Abre Eventos en el menú de usuario para revisar la actividad de la instancia. La creación y eliminación de claves de API de MCP se registra con el origen Auth, y la clave en sí nunca se registra. También puedes pedir al asistente que busque los eventos por ti.

Buenas prácticas

1. Mantén el valor por defecto. Usa Aprueba una persona salvo que tengas un motivo real.
2. Una clave por asistente o por persona, con un nombre que reconozcas y una fecha de caducidad.
3. Usa la caducidad más corta que te sirva, y elimina las claves que ya no uses. La columna Último uso te ayuda a encontrarlas.
4. Lee la simulación. Comprueba la organización y el proyecto que nombra antes de aprobar algo destructivo.
5. Prueba primero en un proyecto de pruebas mientras aprendes lo que puede hacer tu asistente.
6. No compartas las claves en chats, tickets ni repositorios. Si una queda expuesta, elimínala en Ajustes Globales → MCP.

Documentación relacionada

• Administración con IA (MCP)
• Conectar con una clave de API de MCP
• Ejecutarlo en local con gig mcp
• Roles