Credenciales y motores

Thulu no trae clave de modelo propia: cada workspace usa la suya (BYOK). Esa clave se carga en “Configuración → Motores de IA” como un perfil, y cada agente corre con el perfil predeterminado de su motor o con uno que le asignes. Aparte, la página “Credenciales” guarda las claves de GitHub, AWS, Google Cloud, Figma y de los MCP de terceros que usan los servidores MCP cuando un agente abre un PR, lee logs o consulta un ticket. Las dos guardan los secretos cifrados y ninguna los vuelve a mostrar: sólo una pista enmascarada como …A0eZ. Cada una tiene arriba un link a la otra.

Las dos pantallas están en “Configuración”, que se abre desde el pie de la barra lateral o desde el menú de tu cuenta: “Motores de IA” está bajo “Espacio de trabajo” y “Credenciales” bajo “Integraciones”. Hace falta rol admin.

Flujo recomendado: la clave del modelo

Sin perfil predeterminado para Claude Code, ningún agente de ese motor arranca, y la tarjeta lo dice: “Sin perfil predeterminado: las corridas en Claude Code no van a arrancar hasta que cargues una clave”. Es lo primero que conviene hacer después de crear el workspace; el botón “Configuración inicial” de la barra de arriba lo lista como “Key del modelo (BYOK)”. En una instalación propia, thulu init ya te pide esta clave y crea el perfil.

1. Conseguí la credencial fuera de Thulu. La forma recomendada es una clave de API de Anthropic (empieza con sk-ant-api), que se factura en tu cuenta de la API. También podés correr Claude por Amazon Bedrock o Google Vertex AI (ver Bedrock, Vertex y endpoints propios) o sin guardar ninguna clave, con federación de identidad.

2. Abrí “Configuración” y elegí “Motores de IA”. Cada motor tiene una tarjeta. Sin perfil, la sección “Predeterminado” muestra el botón “Configurar clave predeterminada”.

   

   Un workspace nuevo: ningún motor tiene clave. Claude Code lleva la marca "Motor predeterminado", el que usan los agentes que no eligen motor.

3. Apretá “Configurar clave predeterminada” en Claude Code. El nombre viene puesto (default-claude-code) y “Predeterminado para Claude Code” viene tildado.

4. En “Credencial” elegí “Clave de API” y pegala en “Clave”. Dejá “Modelo” vacío para usar el de la CLI (sonnet) o escribí opus o haiku.

   

   Modelo, esfuerzo y URL base son opcionales.

5. Apretá “Crear perfil”. Aparece el aviso “Perfil "default-claude-code" creado” y Thulu le pregunta al proveedor si acepta la clave: “El proveedor aceptó la clave de …” o “El proveedor rechazó la clave de …: revisala antes de la próxima corrida”. La tarjeta muestra el perfil con la pista de la clave, su estado y qué agentes lo usan. Los agentes de Claude Code que no tienen perfil propio ya corren con esta clave.

La verificación pide la lista de modelos del proveedor, así que sirve para claves de API. Un token de suscripción o una credencial de nube no responde esa lista y su perfil queda “Sin verificar”. Si una corrida recibe un rechazo del proveedor, el perfil pasa a “Rechazada en una corrida” con el código HTTP. “Volver a verificar” repite la prueba.

Token OAuth de Claude Pro/Max

“Credencial” también ofrece “Token OAuth (Claude Pro/Max): sólo el dueño de la instalación, para pruebas”. Lo ve sólo el owner del workspace operador, porque factura la suscripción de una persona. En Kubernetes viene apagado: el operador tiene que poner OCTOPUS_KUBE_ALLOW_CLAUDE_OAUTH_TOKEN=1. Para un equipo usá una clave de API, Bedrock o Vertex.

Perfiles con nombre

Un perfil con nombre sirve cuando un agente necesita otro modelo, otra clave (por ejemplo, la de otro equipo para separar costos) u otro endpoint. Los agentes no lo usan hasta que se lo asignás.

1. En la tarjeta del motor, apretá “Nuevo perfil”.

2. Completá “Nombre” (por ejemplo opus-revisiones), “Modelo” (opus), “Esfuerzo” (“alto”) y la “Clave”. Dejá sin tildar “Predeterminado para Claude Code”.

3. Apretá “Crear perfil”. El perfil aparece en “Otros perfiles” con “Ningún agente lo usa”.

4. Asignalo desde Agentes: elegí el agente, abrí su pestaña “Configuración” y, en la caja “Modelo y credenciales”, dejá el modo “Perfil”, elegí el perfil en la lista y apretá “Guardar configuración”.

   

   En el agente, el perfil decide motor, modelo y clave. La caja gris de abajo dice con qué corre lo guardado.

El predeterminado lo usan los agentes sin perfil propio; opus-revisiones lo usa revisor. Cada fila muestra modelo, esfuerzo, pista de la clave y último uso.

Cómo elige la clave cada agente

Configuración del agente	Motor y modelo	Clave
“Perfil” → “Por defecto de Claude Code”	Los del perfil predeterminado	La del perfil predeterminado. Si alguien cambia el predeterminado, el agente cambia con él
“Perfil” → un perfil con nombre	Los de ese perfil	La de ese perfil. Editar el perfil cambia a todos los agentes que lo usan
“Personalizado”	Los que elijas en “Motor”, “Modelo” y “Esfuerzo”; vacío toma el predeterminado	Siempre la del perfil predeterminado del motor

Los agentes nunca guardan una clave propia. El detalle de la caja “Modelo y credenciales” está en Agentes. Si la persona que lanza la corrida conectó su sesión personal, esa corrida usa la sesión en lugar de la clave del perfil.

Cambiar el predeterminado, editar o borrar

• “Hacer predeterminado” en otro perfil pide confirmación y dice cuántos agentes cambian (“1 agente sin perfil propio pasa a usar esta clave y este modelo en su próxima corrida”).
• “Editar” deja la clave vacía: si no pegás nada, se conserva la guardada. En el predeterminado, la casilla queda fija; para que deje de serlo hay que hacer predeterminado a otro.
• “Eliminar” no deja borrar un perfil que usa algún agente: primero pasá esos agentes a otro perfil. Borrar el predeterminado deja al motor sin clave, y la confirmación lo dice.

Los cambios valen desde la próxima corrida. Una corrida en curso sigue con lo que arrancó.

Bedrock, Vertex y endpoints propios

En el modal de Claude Code, “Proveedor” ofrece “Anthropic API”, “Amazon Bedrock” y “Google Vertex AI”. Cada uno muestra campos distintos:

Proveedor	Campos	Notas
Anthropic API	“Credencial”, “Clave”, “URL base (opcional)” y “Enviar la clave como” (aparece al escribir una URL base)	La URL base apunta a un proxy como LiteLLM. “Authorization: Bearer” es para gateways que no aceptan el header x-api-key. Con URL base, Thulu no revisa el prefijo de la clave
Amazon Bedrock	“Región”, “Modelo chico (opcional)”, “Access key ID” y “Secret access key”, “Session token (opcional)” o “Clave de API de Bedrock (opcional)”	Con los campos de credencial vacíos usa la identidad de nube de la instalación (IRSA), si el operador la habilitó
Google Vertex AI	“Región”, “ID del proyecto”, “JSON de la clave de la service account”	Igual que Bedrock: vacío usa Workload Identity

Un perfil por Bedrock. En "Modelo" va el id que Bedrock le da al modelo o un inference profile.

Las tarjetas de OpenAI Codex y OpenCode siguen los mismos pasos, con “OpenAI API” o una “API compatible con OpenAI” (DeepSeek, OpenRouter) como proveedor.

Federación de identidad: sin guardar una clave

Un perfil de Claude Code contra la API de Anthropic puede autenticarse sin guardar ninguna clave. En “Credencial” elegí “Federación de identidad de carga de trabajo”: cada corrida recibe un token de identidad que firma el daemon, y Anthropic lo cambia por un token de acceso corto según una regla de federación de la Claude Console. Quien lea el entorno de un contenedor se lleva un token que vence con la corrida.

Necesita tres cosas:

• Una dirección https fija para el daemon, que es el emisor de los tokens: OCTOPUS_WORKLOAD_IDENTITY_ISSUER o OCTOPUS_DOMAIN. Sin ninguna de las dos, el perfil no se guarda. Una vez registrada en Anthropic no conviene cambiarla.
• En la Claude Console, registrar ese emisor, crear una service account y una regla de federación que filtre por el prefijo del subject que muestra el formulario, así la regla admite sólo las corridas de este workspace. Si Anthropic no llega al daemon por internet, elegí JWKS inline y pegá el conjunto de claves que muestra el formulario.
• En el perfil, los IDs de la regla (fdrl_…), de la organización, de la service account (svac_…) y, sólo si la regla cubre varios workspaces de Anthropic, del workspace (wrkspc_…).

La vida máxima del token del emisor en Anthropic tiene que cubrir el límite de tiempo de la corrida (ver más abajo). No sirve para Bedrock ni Vertex.

Tu propia sesión de Claude

En una instalación Docker, “Motores de IA” muestra el panel “Tu propia sesión de motor”. “Conectar” abre la página de inicio de sesión de Claude, aprobás con tu cuenta y pegás el código que te muestra. Desde ahí, las corridas que arranques vos usan esa sesión en lugar de la clave del workspace, de a una por vez: las demás esperan en la cola. Las que arrancan automatizaciones, menciones de agentes o claves de API siguen con la del workspace.

Quién puede leer tu sesión

Cualquier contenedor de agente que arranque una corrida tuya puede leer esta sesión. Conectá una cuenta personal sólo en una instalación propia que controles, y dentro de los términos de tu cuenta de Claude. En Kubernetes este panel no existe.

“Desconectar” cierra la sesión y borra su volumen. Si una corrida todavía la usa, esperá a que termine.

Límite de tiempo por corrida

Al final de “Motores de IA”, “Límite de tiempo por corrida” dice cuántos minutos puede durar una corrida de agente en este workspace antes de que Thulu la frene y lo avise en la tarea. Sin un valor propio rige el de la instalación, y el workspace no puede pasar el máximo que fija la instalación. “Usar el de la instalación” borra el valor propio. Sólo un admin lo cambia.

Dónde termina la clave

Con el gateway de LLM encendido (el default en Helm y en los compose), el contenedor del agente recibe un token propio de la corrida y el daemon pone la clave real en cada llamada al modelo: la clave nunca entra al contenedor. Tres casos no pasan por el gateway: el token OAuth de Claude Pro/Max, que viaja como variable de entorno; la federación de identidad, que lleva el token corto de la corrida; y la sesión personal, que se monta en el contenedor.

Credenciales de servicios

La página “Credenciales” guarda las claves que usan los MCP en nombre de un agente: argus-github para PRs y Actions, argus-cloud para logs y métricas, argus-figma para leer diseños, y los MCP de terceros registrados en MCPs. Thulu verifica cada una al guardarla cuando el proveedor lo permite, averigua qué permisos tiene y la ata a los proyectos o entornos que elijas.

Proveedor	Tipos	Para qué
GitHub	“Token de acceso personal”	PRs, Actions y git cuando el proyecto no usa la GitHub App
AWS	“Access keys”	argus-cloud
Google Cloud	“Clave de cuenta de servicio”	argus-cloud
Figma	“Token de acceso personal”	argus-figma, sólo lectura
“Encabezado HTTP (token de API)”	“Token bearer”, “Usuario y token de API (Basic)”, “Encabezado propio”	Un MCP de terceros que acepta un token fijo (Jira con un token de Atlassian, por ejemplo). No hay chequeo genérico: queda “Sin verificar” hasta que una llamada lo usa
“Conexión OAuth (servidor MCP)”	“Conexión a un servidor MCP”	Un MCP de terceros que pide OAuth (Slack, Atlassian, Linear). Se conecta con “Conectar” y el daemon guarda y renueva los tokens

Tres credenciales con su identidad, estado y a qué alcanzan. Abajo, cada vez que un agente usó (o quiso usar) una, con el motivo si se rechazó.

1. Creá la clave en el proveedor. Para GitHub, un token de acceso personal. Los clásicos informan sus scopes y Thulu los mapea a tools: con repo habilita PRs y Actions, con public_repo sólo PRs en repos públicos; sumá workflow si los agentes editan .github/workflows. Los fine-grained se aceptan, pero GitHub no informa sus permisos y todas las tools quedan habilitadas. Para Figma, un token con current_user:read, file_content:read, file_comments:read y projects:read.

2. En “Credenciales”, apretá “Nueva credencial”.

3. Poné un “Nombre” (los agentes lo ven, por ejemplo github-tienda), elegí el “Proveedor” y pegá los campos que pide: “Token” para GitHub o Figma, “Access key ID” y “Secret access key” para AWS, “Archivo de clave (JSON)” para Google Cloud. Para un MCP de terceros, el nombre tiene que ser el mismo que pide su registro en MCPs.

4. En “Qué tareas pueden usarla”, tildá los proyectos o entornos. Un entorno marcado “producción” se ve en rojo. “Todas las tareas de este espacio de trabajo” alcanza a todo, y en la lista se muestra en amarillo.

   

   Un token de GitHub va atado al proyecto (tienda-web). Una clave de nube conviene atarla a su entorno: atada al proyecto, la puede usar cualquier tarea de ese proyecto.

5. Apretá “Verificar y guardar”. El modal muestra el resultado: estado, identidad, cuántos permisos encontró y cuántas tools quedan disponibles. “Listo” cierra; “Agregar otra” vuelve al formulario.

6. Si es un token de GitHub para clonar y pushear, el resultado lo recuerda: “Usarla en un proyecto: abrí Repositorio → Acceso a GitHub y elegila.” (Git y GitHub).

Guardar sin tildar ningún acceso es válido, pero la credencial no sirve hasta que elijas algo: el aviso y la columna “Acceso” dicen “Sin acceso todavía”. Si Thulu no llega al proveedor, la credencial se guarda igual como “Sin verificar” (ver Problemas comunes).

Qué tools habilita y quién la usa

Hacé clic en una fila para abrir el detalle. Arriba están “Volver a verificar” y “Desactivar”; debajo, la identidad, la pista de la clave, el vencimiento y la última verificación.

Las filas en gris piden un permiso que el token no tiene (acá github:actions:write). Las demás las prendés o apagás vos; "Guardar cambios" aplica.

• La lista de tools está agrupada en “Lectura”, “Escritura” y “Actions”, con un buscador (“Buscar tools”) y un tilde por grupo para prender o apagar todas.
• Para que ningún agente use una tool con esta clave (por ejemplo pr_merge), destildala y apretá “Guardar cambios”.
• “Qué tareas pueden usarla”, al final del detalle, cambia el acceso.
• “Rotar clave” reemplaza el secreto sin tocar quién puede usarla ni qué tools quedan prendidas. “Renombrar” cambia el nombre.
• “Desactivar” apaga la credencial entera sin borrar nada. Las tareas siguen arrancando, sin esas tools.
• “Eliminar credencial” borra el secreto, el acceso y la configuración de tools. La clave sigue valiendo en el proveedor: revocala allá también.

El panel “Decisiones recientes” lista cada llamada a una tool que pidió credencial: cuándo, “Permitida” o “Rechazada”, la tool, la credencial, la tarea y el motivo (“a la clave le falta el permiso”, “no hay credencial alcanzable para ese recurso”, “varias candidatas; el agente tiene que nombrar una”). “Sólo rechazos” filtra.

Estados

Estado	Qué pasa
“Válida”	El proveedor la aceptó
“Por vencer” / “Vence 20 oct”	Tiene fecha de vencimiento cercana (credenciales temporales de AWS, tokens de GitHub con vencimiento)
“Vencida” / “Inválida”	Una tarea que necesita esta credencial para sus tools no arranca: queda un comentario “Lanzamiento bloqueado” con la credencial y las tools afectadas
“Sin verificar”	Thulu no pudo preguntarle al proveedor, o el tipo no tiene chequeo (encabezado HTTP). El detalle avisa: “No se pudo saber qué permite esta clave: todas las tools quedan habilitadas.”
“Desactivada”	La apagaste vos. No bloquea: la tarea corre sin esas tools

Thulu vuelve a verificar cada credencial sola cada 6 horas. Para lanzar una tarea con una credencial vencida, rotala o desactivala: desactivada, la corrida arranca sin las tools que dependían de ella.

GitHub App

El panel “GitHub App” de esta página conecta una App que reemplaza los tokens personales para git: emite un token de vida corta por operación, limitado a un repositorio. Sirve a todos los workspaces de la instalación, así que conectarla o quitarla es de un admin del workspace operador. En la SaaS la App ya viene conectada y sólo la instalás en tu organización. En una instalación propia, “Crear la App en GitHub” abre el formulario de GitHub con los permisos, el webhook y las URLs ya cargados, y vuelve con la App conectada; “Conectar una App existente” pide el “App ID” y el .pem de una App registrada a mano. Los pasos completos están en Git y GitHub.

Si la App se configuró con variables de entorno (OCTOPUS_GITHUB_APP_ID y las demás), el panel la muestra como “Desde el entorno” y no deja cambiarla desde la UI.

Problemas comunes

Síntoma	Causa y salida
La corrida no arranca: “no hay credencial de LLM para … cargá un perfil predeterminado para … en Configuración → Motores de IA”	El motor del agente no tiene perfil predeterminado. Cargalo en Motores de IA
“El motor de IA rechazó la credencial (HTTP …)” en la tarea	El proveedor no aceptó la clave en la corrida. El perfil queda “Rechazada en una corrida”: editalo y pegá una clave nueva
“Clave de API empieza con sk-ant-api” al crear un perfil	Pegaste un token de otro tipo. Cambiá “Credencial” o la clave y volvé a apretar “Crear perfil”
La caja del agente dice que la configuración no tiene clave, o el selector muestra “sin clave: no arranca”	Ese motor no tiene perfil predeterminado
“"opus-revisiones" lo usan revisor. Pasá esos agentes a otro perfil primero.”	El perfil tiene agentes asignados. Cambialos en Agentes y volvé a eliminar
Una credencial nueva queda “Sin verificar” con “No se pudo contactar a …”	Thulu no llegó al proveedor (red, proxy, DNS). Apretá “Volver a verificar” cuando haya salida a internet
Un agente dice que no puede disparar un workflow	Mirá “Decisiones recientes” con “Sólo rechazos”: “a la clave le falta el permiso” es el token (un clásico necesita el scope repo, no sólo public_repo); “no se ofrece en esta etapa” es la configuración de MCP del agente (MCPs)
Un perfil federado no se guarda	Falta OCTOPUS_WORKLOAD_IDENTITY_ISSUER u OCTOPUS_DOMAIN en el daemon

Lo que ves si Thulu no llega a GitHub al guardar: la credencial se guarda igual, sin permisos averiguados y con todas las tools habilitadas.

Relacionado

AgentesLa caja Modelo y credenciales de cada agente.

MCPsQué tools recibe cada agente en cada etapa, y cómo registrar un MCP de terceros.

Git y GitHubQué credencial usa cada proyecto para clonar, pushear y abrir PRs.

Uso y costosCuánto gastó cada agente y cada corrida.

Seguridad y auditoríaEl registro de quién creó, cambió o borró cada credencial.