Producto: Credenciales

OPS Center permite guardar credenciales para agentes y servidores sin exponer el secreto despues de crearlo.

Tipos

• api_key
• oauth_token
• access_token
• refresh_token
• cli_session
• env_bundle
• other

Scopes

• personal: asociada a un usuario del workspace.
• workspace: disponible para automatizaciones del workspace.
• account: disponible para automatizaciones de los workspaces de la misma empresa/cuenta.

Credenciales Para Agentes

Las automatizaciones pueden autenticarse de tres formas:

• sesion local del runtime en el host del worker, por ejemplo OAuth de OpenCode o login de Codex;
• variable global del servicio en el worker, por ejemplo OPENAI_API_KEY en /etc/ops-center/auth.env;
• credencial de workspace guardada en OPS y resuelta por el launcher justo antes de ejecutar la tarea.
• credencial de account guardada en OPS cuando varios workspaces de la misma empresa deben compartir el mismo runtime sin duplicar secretos.

Regla de producto:

• BYOK significa traer una clave propia y guardarla cifrada como workspace o account.
• BYOS significa traer una suscripcion o sesion propia ya autenticada en el runner local; OPS no guarda usuario/password ni token personal del proveedor.
• Las credenciales personal no se inyectan en dispatch autonomo. Sirven para uso asistido o futuro flujo con consentimiento explicito.
• Si el runtime depende de BYOS, el SaaS solo coordina. La ejecucion real y el preflight ocurren en el runner local autorizado.

Para OpenCode con OpenAI, crear una credencial con:

• agente: opencode
• proveedor: openai
• tipo: api_key
• scope: workspace
• uso: agent

OPS inyecta esa credencial como OPENAI_API_KEY solo durante la ejecucion de la tarea. Para Minimax usar proveedor minimax; OPS la inyecta como MINIMAX_API_KEY. Para otros proveedores se puede definir metadata.env_var si el runtime espera un nombre concreto.

El launcher tambien acepta bundles env_bundle con varias claves, por ejemplo OPENAI_API_KEY=... y OPENROUTER_API_KEY=....

Usos disponibles:

• agent: runtimes y proveedores usados por agentes.
• deployment: despliegues o targets tecnicos.
• server: procesos de servidor.
• provider: integraciones externas.
• other: caso especial documentado.

Para instrucciones paso a paso por caso de uso, ver Recetas de credenciales.

Tokens API

Los tokens API sirven para que integraciones externas, como n8n, llamen a la API de OPS sin usar una sesion de usuario.

No deben mezclarse con OPS_SERVICE_TOKEN:

• OPS_SERVICE_TOKEN: token interno del sistema, definido en /etc/ops-center/auth.env, usado por workers y servicios propios.
• Tokens API: tokens por integracion, creados desde Gestion -> Credenciales -> Tokens API o desde Gestion -> Configuracion -> Tokens API.
• service_api_token: compatibilidad legacy. Debe evitarse para integraciones nuevas.

Al crear un token API, OPS muestra el valor completo una sola vez. Despues solo conserva el hash, la huella, el alcance, el estado, la expiracion y el ultimo uso.

Alcances disponibles:

• workspace actual: la integracion solo puede operar en ese workspace.
• empresa: la integracion puede operar en los workspaces de la misma empresa/cuenta. Para seleccionar un workspace concreto debe enviar X-OPS-Workspace-Id.

Regla de permisos:

• los tokens API no son tokens internos del sistema;
• el scope service permite operar automatismos del workspace/empresa, pero no administrar la configuracion global;
• los tokens API no pueden crear, listar, editar ni revocar otros tokens;
• revocar o desactivar un token corta la autenticacion de forma inmediata.

Para n8n, usar el token API con el header:

X-OPS-Service-Token: <token-generado>

Tambien se acepta como Bearer token:

Authorization: Bearer <token-generado>

Reglas De Seguridad

1. El secreto se cifra antes de guardarse.
2. La API de listado no devuelve secret.
3. El launcher resuelve secretos solo en runtime.
4. Las credenciales se filtran por workspace_id y, si son account, por account_id.
5. Las credenciales personales no se usan en resolucion automatica de tareas.
6. Cada uso sensible debe dejar auditoria.

UX Esperada

El usuario debe poder ver:

• alias
• proveedor
• tipo
• scope
• uso
• estado activo
• ultimo uso
• expiracion

No debe poder ver el valor secreto ya guardado.

Inventario Runtime

GET /api/security/runtime-inventory

Devuelve un inventario seguro del workspace:

• totales de credenciales locales y compartidas visibles para el workspace
• credenciales por proveedor, scope, uso y tipo
• targets de despliegue con alias de credencial
• avisos de credenciales expiradas, proximas a expirar o inactivas
• targets activos sin credencial asociada

El endpoint no devuelve secretos ni material sensible.

Catalogo Runtime, Modelo Y Credencial

GET /api/security/runtime-catalog

Devuelve la resolucion tecnica por workspace:

• profile o perfil de trabajo;
• agente logico, por ejemplo opencode o codex;
• runtime, como CLI local o HTTP remoto;
• proveedor inferido o configurado;
• modelos disponibles o anunciados por runners;
• credenciales usables, expiradas o ausentes;
• modo de autenticacion: BYOK, BYOS, modelo local, personal-only o faltante;
• runner local fresco cuando aplica.

Estados principales:

• ready: se puede explicar como se ejecutaria.
• needs_runner: falta runner local fresco.
• needs_credential: falta credencial activa.
• inactive: agente desactivado.

Esta vista no muestra secretos. Sirve para evitar promesas ambiguas: si una tarea no tiene runner, modelo o credencial suficiente, debe verse antes de automatizarla.