Kiro en modo desatendido: agentes de IA que trabajan por ti mientras duermes
Kiro ya te hace la vida más fácil. Pero cuando aprendes a exprimir el modo desatendido, das un salto: pasas de reaccionar a ser proactivo… incluso mientras descansas. El verdadero poder está en delegar tareas específicas a agentes que trabajan por ti. Tú solo revisas los resultados y pones el ojo donde de verdad importa.
El problema: el ruido de seguridad no espera a que tengas tiempo
Cualquier equipo de DevOps o plataforma vive la misma tensión: cada día se publican decenas de CVEs, avisos de CISA, boletines de AWS y ataques de supply chain, pero solo un puñado afecta realmente tu stack. Revisar TheHackerNews, los reportes de seguridad de AWS, el feed de Kubernetes y media docena de fuentes más, todas las mañanas, filtrando manualmente lo relevante… no escala. Y lo que no escala, tarde o temprano se deja de hacer.
La respuesta clásica sería un script con reglas y regex. El problema es que la seguridad no es un problema de keyword matching: entender si un "path traversal en la API de commits de GitLab" te afecta requiere contexto y criterio, no una lista de palabras.
Ahí es donde entra Kiro en modo desatendido.
¿Qué es el modo desatendido de Kiro?
Kiro puede trabajar de dos formas:
- Modo interactivo (Vibe - SDD): conversas con el agente en tu terminal o editor, iteras, revisas y apruebas cada paso. Ideal para desarrollo y exploración.
- Modo desatendido (autónomo/headless): el agente recibe una instrucción, ejecuta todo el flujo de principio a fin sin intervención humana, y entrega un resultado. Ideal para tareas repetibles y programadas.
El modo desatendido se activa con dos flags al invocar el CLI:
1
2
3
4
5
kiro-cli chat \
--agent security-news-monitor \
--no-interactive \
--trust-all-tools \
"Escanea los feeds de seguridad de las últimas 24 horas y envía el resumen al canal de Slack"--no-interactive: no espera input humano; el agente decide y actúa.--trust-all-tools: no pide confirmación antes de usar cada herramienta (leer feeds, ejecutarcurl, etc.).
La clave: sigue siendo el mismo agente que usarías interactivamente. La misma definición, el mismo prompt, las mismas skills. Solo cambia cómo lo invocas. Esto significa que puedes desarrollar y depurar el agente de forma conversacional, y luego "soltarlo" en un cron sin reescribir nada.
Anatomía de un agente Kiro: separación de responsabilidades
Lo que hace robusto al modo desatendido es que el comportamiento del agente no vive en el prompt del cron, sino en archivos versionados en
.kiro/. El agente security-news-monitor se compone de:1
2
3
4
5
6
7
8
9
.kiro/
├── agents/security-news-monitor.json # Definición: tools, permisos, recursos
├── prompts/security-news-monitor.md # System prompt: responsabilidades y reglas
├── steering/
│ ├── shared/ # Reglas compartidas por TODOS los agentes
│ └── security-news-monitor/
│ └── feeds-configuration.md # Feeds, keywords, config de Slack
└── skills/security-news-monitor/
└── scan-and-notify/SKILL.md # El pipeline paso a paso
Esta separación es lo que hace que el agente sea predecible en modo desatendido:
agent.jsondefine qué puede hacer — sus límites de seguridad.prompt.mddefine cómo razona — sus responsabilidades y criterios.steering/aporta el contexto del negocio — qué stack te importa.skills/define el procedimiento — los pasos exactos a ejecutar.
Cuando lo lanzas sin supervisión, el agente no improvisa: sigue un flujo documentado y opera dentro de barreras explícitas.
Seguridad primero: barreras aunque nadie mire
--trust-all-tools suena peligroso: ¿un agente ejecutando comandos sin supervisión? Aquí está lo interesante — el agent.json restringe qué puede hacer, de modo que "confiar en todas las herramientas" solo confía en las que ya están explícitamente permitidas:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"allowedTools": ["read", "write", "grep", "glob", "shell", "web_fetch"],
"toolsSettings": {
"web_fetch": {
"trusted": [
".*aws\\.amazon\\.com.*",
".*www\\.cisa\\.gov.*",
".*slack\\.com/api.*"
// ...solo dominios de feeds de seguridad y Slack
]
},
"write": { "allowedPaths": [".kiro/**"] },
"shell": {
"allowedCommands": ["curl.*slack\\.com.*", "curl.*api.*", "echo.*", "date.*"],
"deniedCommands": ["rm -rf.*", "git push.*--force", "git reset.*--hard"]
}
}
}
Aunque corra a las 8am sin nadie mirando, el agente:
✓ Solo puede consultar los feeds de seguridad y la API de Slack (web_fetch allowlist).
✓ Solo puede escribir dentro de .kiro/**.
✓ Solo puede ejecutar curl a Slack/APIs, echo y date.
✗ No puede ejecutar rm -rf, forzar push, ni resetear el repo.
Y los secretos nunca tocan el código: el SLACK_BOT_TOKEN se inyecta como variable de entorno, nunca hardcodeado.
✓ Solo puede escribir dentro de .kiro/**.
✓ Solo puede ejecutar curl a Slack/APIs, echo y date.
✗ No puede ejecutar rm -rf, forzar push, ni resetear el repo.
Y los secretos nunca tocan el código: el SLACK_BOT_TOKEN se inyecta como variable de entorno, nunca hardcodeado.
El flujo completo: de feed RSS a alerta en Slack
El agente ejecuta un pipeline de 6 pasos, definido en su skill
scan-and-notify:- Fetch —
web_fetchsobre 9 feeds RSS (TheHackerNews, CISA, AWS Security Bulletins, Kubernetes Blog, Snyk, etc.). - Parse — extrae cada ítem (título, link, descripción, fecha).
- Analiza — aquí está la magia: no es keyword matching, es el agente razonando sobre si cada noticia impacta el stack específico (EKS, IAM, Spring Boot, Next.js, Kafka, Aurora…).
- Clasifica — asigna severidad:
- ● CRITICAL: CVEs en dependencias directas, zero-days activos, supply chain en paquetes que usan.
- 🟠 HIGH: vulnerabilidades en stack secundario (Grafana, Redis, GitHub Actions…).
- ✗ SKIP: ruido irrelevante (Azure-only, cripto, mobile-only, Fortinet…).
- Formatea — arma un único mensaje de Slack agrupado por severidad.
- Notifica — lo envía vía
curla la API de Slack.
El resultado es un digest diario limpio y accionable como este:
Cada línea es un CVE real, correlacionado con un componente concreto de la infraestructura, con un resumen de una línea que dice por qué te importa. Ese "por qué" es lo que un script de regex jamás te daría.
Ponlo en piloto automático: GitHub Actions + cron
El paso final del modo desatendido es programarlo. Un workflow de GitHub Actions lo ejecuta cada mañana:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
name: SECURITY NEWS MONITOR (SCHEDULED)
on:
schedule:
# 06:00 Colombia (UTC-5) = 11:00 UTC
- cron: '0 11 * * *'
workflow_dispatch: {} # también lanzable a mano
jobs:
security-news-scan:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- uses: actions/checkout@v5
- name: Install Kiro CLI
run: |
curl -fsSL https://cli.kiro.dev/install | bash
echo "$HOME/.local/bin" >> $GITHUB_PATH
- name: Run Security News Monitor Agent
env:
KIRO_API_KEY: ${{ secrets.KIRO_API_KEY }}
SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
SLACK_CHANNEL_ID: ${{ vars.SLACK_CHANNEL_ID }}
run: |
kiro-cli chat \
--agent security-news-monitor \
--no-interactive \
--trust-all-tools \
"Escanea los feeds de seguridad de las últimas 24 horas y envía el resumen al canal de Slack usando SLACK_BOT_TOKEN y SLACK_CHANNEL_ID"
Con esto tienes un analista de seguridad virtual que cada día a las 6am (Colombia) lee todo internet por ti, filtra el 90% de ruido y te deja en Slack solo lo que debes revisar antes del café.
Slack es solo el principio: cualquier canal
Aunque el ejemplo usa Slack, el patrón es agnóstico del destino. Como el agente envía la notificación con
curl sobre un cuerpo JSON que él mismo construye, cambiar de canal es cambiar el endpoint y el formato del payload:- Slack —
chat.postMessagecon Block Kit (el ejemplo actual). - Microsoft Teams — un Incoming Webhook con tarjeta adaptativa.
- Discord — webhook con embeds.
- Email — vía AWS SES.
- PagerDuty / Opsgenie — para escalar los ● CRITICAL como incidentes.
La lógica de qué alertar (el criterio de seguridad) queda separada de dónde alertar (el canal). Cambias uno sin tocar el otro.
Por qué esto importa: las bondades del modo desatendido
Recapitulando, el modo desatendido de Kiro te da:
| Bondad | Qué significa en la práctica |
|---|---|
| Mismo agente, dos modos | Desarrollas conversando, despliegas sin reescribir |
| Criterio, no reglas | El agente razona sobre relevancia; no mantienes regex frágiles |
| Seguro por diseño | Allowlists de tools/dominios/comandos aunque nadie supervise |
| Versionado y auditable | Todo el comportamiento vive en .kiro/, en git |
| Programable | Un cron + GitHub Actions lo convierte en un servicio 24/7 |
| Canal-agnóstico | Slack, Teams, email, PagerDuty… solo cambia el curl final |
El resultado no es "un bot que manda mensajes". Es trabajo de conocimiento delegado: una tarea que antes requería a un humano con criterio, ahora la ejecuta un agente con criterio, todos los días, sin fallar.
Qué viene en la serie
Este fue el primer artículo. En los próximos veremos:
- Agente de auditoría desatendida — cómo
identity-and-access-audit-agentevalúa IAM Identity Center y GitHub contra CIS Benchmarks y genera un reporte HTML por email. - Agente de revisión de código en cada PR — cómo un agente empieza a examinar el código que los desarrolladores cambiaron en cada pull-request, dejando comentarios y sugerencias.
- Steering y skills — cómo enseñarle a un agente el contexto de tu negocio para que sus decisiones sean tus decisiones.
- Y mas...
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article