Automatización que respeta tu radio de impacto
Takuto ejecuta agentes de IA sobre repositorios reales, así que el aislamiento es lo predeterminado — no algo de última hora. Esto es exactamente lo que contiene una ejecución, y lo que no.
Isolation
Cada agente corre en su propio container
El trabajo se aísla por workflow: un container aparte, un git worktree aparte y un entorno aparte. Las descripciones de tickets y el contenido enlazado son entrada no confiable incrustada en los prompts, así que la contenerización limita lo que puede tocar una sesión de agente secuestrada — reduce el radio de impacto de un prompt injection en lugar de confiar en que el agente se comporte.
El egress pasa por un firewall con allowlist
El tráfico saliente está en allowlist por diseño: solo es alcanzable un conjunto cuidado de hosts; todo lo demás se deniega por defecto. La lista por defecto va más allá de tus propias herramientas — también habilita los registros de paquetes y los sitios de documentación para desarrolladores que un agente de código necesita legítimamente:
- Tu sistema de ticketing — Jira / Atlassian (incl. developer.atlassian.com) o GitHub (incl. docs.github.com)
- APIs de los proveedores de IA — Claude, Codex (OpenAI) y Cursor quedan habilitados de fábrica para los proveedores que actives; OpenCode es autoalojado, así que en su lugar se habilita su base_url
- Registros de paquetes — npm (más tu .npmrc), crates.io, docs.rs, nodejs.org
- Documentación habitual para desarrolladores — rust-lang.org, MDN, Stack Overflow
- Endpoints de AWS STS / SSO, para ejecuciones autenticadas con AWS
Los hosts de los proveedores de IA siguen a los proveedores que actives en available_providers — recorta esa lista para estrechar el firewall, o añade tus propios hosts con extra_egress_hosts. Considera el firewall como una capa de defensa en profundidad que reduce el radio de impacto, no una garantía absoluta; aún se está reforzando durante la beta.
Defensa en profundidad, no una bala de plata
El aislamiento reduce el riesgo; no lo elimina. Takuto espera que haya unos cuantos valores predeterminados en su sitio para que una ejecución comprometida no pueda causar daño real:
Protección de ramas obligatoria
Los agentes empujan ramas y abren PRs — nunca hacen commit a main. Aplica la protección de ramas en el host de Git para que se sostenga incluso si un agente se descarría: exige una revisión humana aprobada antes del merge.
Credenciales acotadas y de mínimo privilegio
Un agente secuestrado solo puede alcanzar lo que sus credenciales permiten, así que acótalas al máximo — tanto para tu código como para tus tickets. Prefiere un PAT de grano fino de GitHub (o una GitHub App) limitado al repositorio de destino, y una cuenta de servicio de Jira dedicada con permisos solo de Browse / Create / Assign en los proyectos de destino. Evita los logins OAuth amplios y los tokens personales o de admin: suelen conceder mucho más de lo que una ejecución necesita, así que un prompt injection con éxito podría leer o modificar cualquier cosa que esa credencial alcance.
Encuadre de tickets no confiables
El texto de los tickets se trata como contenido suministrado por el usuario que podría intentar anular las instrucciones. La protección de ramas y los tokens acotados son la principal defensa frente a una descripción maliciosa.
Privacidad por defecto
Takuto no rastrea a nadie — ni en el producto ni en este sitio web.
- Sin analíticas de uso, sin reporte de crashes, sin phone-home, sin telemetría.
- Tu código, el contenido de los tickets y los prompts van solo al proveedor de IA que configures — Takuto nunca los recopila.
- La contenerización significa que corre en tu máquina o en tu propio servidor: el despliegue es tuyo.