Conectores y credenciales

Los agentes son mucho más útiles cuando alcanzan las herramientas y datos correctos: documentación, un tracker de incidencias, un diseño en Figma, una cuenta cloud. Chronos los conecta con una garantía simple: el agente nunca ve una credencial.

Cómo llega una conexión a la sesión

Qué conexiones existen lo decide el catálogo firmado del panel, en cascada global y por equipo. En ejecución el agente nunca habla con un endpoint real: toda conexión pasa por un proxy local, el agente solo ve una dirección 127.0.0.1 con un token propio de su sesión y el proxy inyecta la credencial real antes de reenviar cada llamada. El secreto no pasa por las manos del agente, sus prompts ni su salida; tampoco se escribe en el proyecto ni en los logs.

Las entradas sin clave se descartan en cerrado

Una conexión que requiere credencial y no la tiene configurada no se materializa nunca en la sesión. Se descarta y el descarte queda auditado. Nunca aparece como un servidor que falla en cada llamada ni como una vía degradada.

Las conexiones de serie

Chronos siembra ocho conexiones más una entrada especial de proveedor de modelo. Como cualquier entrada del catálogo, puedes acotarlas por equipo o revocarlas desde la pestaña Catalog del panel.

• Playwright: un navegador real, aislado y limitado al servidor de desarrollo de la propia sesión, para verificar cambios web.
• GitMCP: documentación actualizada de librerías y frameworks. Puedes apuntarla a una instancia autoalojada.
• AWS Knowledge: la documentación oficial de AWS. Sin credencial y sin cuenta de AWS.
• AWS: el conector de cuenta. Detalle más abajo.
• Figma: lee diseños (estructura, estilos, assets) para implementarlos en código. Requiere token de empresa.
• Replicate: generación gobernada de imagen y vídeo para los workflows de clonado y diseño. Requiere token de empresa.
• Skills e índice de código: builtins internos que sirven las skills gobernadas y la estructura del código de la sesión.
• Amazon Bedrock: no es un MCP sino el proveedor del modelo: hace que el modelo de Claude Code corra en la cuenta AWS de la organización (facturación, región, CloudTrail y Guardrails propios). Se siembra inerte, sin credenciales ni modelos fijados. Configuración completa en Amazon Bedrock.

Tokens de empresa: Figma y Replicate

Las dos se siembran sin token y quedan dormidas hasta que configuras la credencial de empresa en su entrada del Catalog ("set token"). El token se escribe una vez y no vuelve a mostrarse. Desde ese momento el proxy lo inyecta en cada llamada; el agente solo ve la dirección local.

AWS: rol cross-account con credenciales de corta duración

Para el conector de cuenta puedes pegar unas credenciales estáticas, pero el modelo recomendado es un rol cross-account: guardas en el panel el ARN del rol y un ExternalId y el panel acuña credenciales STS de corta duración al cargar cada sesión.

• Sin secretos de larga vida. Cada sesión recibe credenciales temporales que caducan solas.
• Solo lectura por defecto. Mientras la entrada está en modo read, cada acuñación adjunta una política de sesión ReadOnlyAccess. Pasar la entrada a write queda auditado.
• Atribución en tu CloudTrail. Cada acuñación etiqueta la sesión (chronos_org, chronos_identity, chronos_session), así cada llamada que aparece en tu CloudTrail se une con la sesión de Chronos que la originó. Tu SIEM puede cruzar ambos registros.

El modo de acceso (read o write) y la región viven en la configuración de la entrada. La frontera real es IAM: da al rol la política mínima que quieras y trata las restricciones del conector como defensa en profundidad.

Trackers de incidencias: Jira y Linear

En la pestaña Connectors registras el tracker una vez, para toda la organización o por equipo:

Campo	Jira	Linear
id	por ejemplo jira-acme	por ejemplo linear-acme
endpoint	tu sitio Atlassian, https://acme.atlassian.net	siempre https://api.linear.app/graphql
secret	token OAuth o de API de Jira	API key de Linear (lin_api_…) o token OAuth
scope	global o un equipo	global o un equipo

El secreto se guarda en el panel, no vuelve a mostrarse y se usa por llamada desde el lado de Chronos: nunca llega al cliente ni al agente. El endpoint viene siempre del catálogo firmado y debe ser https://.

Cada workspace enlaza después el conector por su id en su configuración versionada, junto al proyecto o equipo que acota el selector de incidencias. En el repositorio no vive ningún secreto. Ver Configuración.

Con el tracker enlazado, los desarrolladores lanzan sesiones desde un ticket y el agente puede crear o mover incidencias. Cada escritura pide autorización explícita al usuario antes de ejecutarse, solo alcanza el proyecto o equipo enlazado y queda auditada (la incidencia, nunca el token). Para que las escrituras funcionen, la credencial que registraste debe tener permiso de escritura; una clave de solo lectura produce un error claro, no un fallo silencioso.

Qué registra la auditoría

Qué conexión se usó y desde qué sesión, qué credencial se acuñó y para quién, qué entrada se descartó por falta de clave. Nunca el token. Ver Auditoría.