RBAC para agentes de IA: es la mitad de la respuesta

En pocas palabras: RBAC es necesario pero no alcanza para agentes de IA: define qué puede hacer una identidad, no si una acción puntual debe ejecutarse ahora. Como el agente suele usar el kubeconfig del desarrollador, hereda sus permisos; Aegis-DevOps 0.3.2 suma una verificación previa que bloquea lo que tu política prohíbe.

RBAC para agentes de IA es necesario pero no alcanza: controla qué puede hacer una identidad, no si una acción puntual del agente debe ejecutarse ahora. Según el mantenedor de Aegis-DevOps, falta una verificación previa a la ejecución que entienda qué hace el comando y de dónde salió la regla.

RBAC (control de acceso basado en roles) es un modelo que asigna permisos a identidades, como usuarios o cuentas de servicio, según su rol. Aegis-DevOps es un chequeo open source, en alpha (v0.3.2, según el README consultado el 2026-10-08), que corre antes de los comandos de shell de un agente de código y bloquea los que tu política prohíbe. El tema salió a la luz cuando varios le respondieron “usá RBAC” a ese enfoque.

¿Por qué los permisos de Claude Code no son un límite de seguridad?

Porque las reglas Bash de Claude Code comparan el texto del comando que escribe el modelo, no lo que ese comando hace. Según el post, la documentación lo admite: una regla deny “isn’t a security boundary around the program”. El ejemplo es claro: Bash(git push *) frena git push origin main, pero deja pasar git -C . push origin main.

Eso sí: las reglas de permisos sirven para lo que fueron pensadas, que es decidir qué corre sin preguntarte. Nadie dice que sean un motor de políticas. Para inspeccionar el comando completo antes de que corra, el post cuenta que la documentación remite a un hook PreToolUse, un punto de enganche que se ejecuta antes de que la herramienta actúe y puede frenarla.

Una aclaración de método: de la página de permisos de Claude Code solo revisamos el comienzo, y la cita textual la tomamos del post del autor. No la contrastamos contra la documentación completa.

¿Alcanza el RBAC para agentes de IA que ejecutan comandos?

No. RBAC e IAM deciden qué puede hacer una identidad, y un agente de código en una laptop suele correr con el kubeconfig y las credenciales cloud del desarrollador. Para el API server, el agente es el desarrollador, con cada permiso que ese desarrollador tenga.

La salida parcial es darle al agente identidades propias, y conviene hacerlo. Si tus servidores corren en un proveedor local como donweb.com, el criterio es el mismo: una credencial para vos y otra, más acotada, para el agente.

Pero incluso con identidad propia, RBAC es una concesión estática. Puede decir “esta cuenta puede borrar deployments en prod”. No puede decir “este agente no, salvo que un humano lo apruebe, y menos durante el freeze de release”, y tampoco sabe de dónde vino una regla. Ya lo cubrimos antes en reescritura de código a Rust con IA.

Un escenario hipotético, no probado por nosotros: le pedís al agente que limpie recursos viejos, el agente arma un comando con variables, el comando llega al clúster con tus credenciales, el RBAC ve a un desarrollador con permiso de borrado, lo deja pasar y nadie se entera hasta que el deploy de producción desaparece.

¿Cómo bloquea Aegis-DevOps un comando antes de ejecutarlo?

Aegis intercepta la acción que el agente propone y la compara con un almacén de restricciones antes de que corra. Devuelve ALLOW, BLOCK o ESCALATE, con citas de la regla aplicada, según el README del proyecto. Cubre 20 destinos de línea de comandos y planes, entre ellos Kubernetes, Terraform/OpenTofu, las tres nubes grandes, Helm, Git y SQL.

El autor corrió aegis-devops 0.3.2 contra su política de ejemplo (“no deletes en el namespace prod”). Estos resultados son autoinformados, nadie los replicó de forma independiente:

Comando que escribe el agente	Resultado
kubectl delete deploy web -n prod	BLOCK
kubectl -n prod delete deploy web	BLOCK
kubectl delete deploy web -nprod	BLOCK
/usr/bin/kubectl ..., sudo kubectl ..., env kubectl ...	BLOCK
bash -c 'kubectl delete deploy web -n prod'	BLOCK
K=kubectl; $K delete deploy web -n prod	Rechazado: no se puede verificar estáticamente

La última fila es la que más me gusta. Un guardia que no entiende un comando tiene que decir que no, no “ninguna regla coincidió, adelante”. Cualquiera que haya escrito filtros por regex sabe cuántas veces el “no coincidió” terminó siendo la puerta de atrás.

Para probarlo en local, el README propone aegis check command --pretty -- "kubectl delete namespace prod", que da BLOCK con código de salida 3, y kubectl get pods -n prod, que da ALLOW.

¿Qué pasa si una regla llega dentro de un ticket de Jira o un mensaje de Slack?

Una prompt injection es texto plantado en contenido que el agente lee, como un ticket o un mensaje, para que lo trate como una instrucción. Si el agente además levanta reglas de ahí, un atacante podría fabricarse permisos. Aegis lo ataca así: una regla solo vota si nadie la modificó desde que se firmó y si su autor tenía permiso para escribir ese tipo de regla. Una línea plantada en un ticket no vota. En malware que llega por repositorios aparentemente limpios profundizamos sobre esto.

El README trae un benchmark propio: 500 restricciones etiquetadas y 120 intents reservados, puntuados contra un oráculo que no importa el código de Aegis. En la columna de susceptibilidad al envenenamiento por autor no autorizado, Aegis marca 0.000 y opa-signed marca 1.000. Según el mismo README, seis de siete modelos de lenguaje actuaron sobre todas las reglas envenenadas que vieron, y gpt-6-luna sobre 15 de 19. Tomalo con pinzas: lo diseñó y lo corrió el propio autor, y los modelos vieron solo 100 reglas.

Otro límite, que figura en el material de apoyo del encargo y que no pudimos confirmar en el fragmento del README que tuvimos a mano: las fuentes basadas en archivos usan secretos de firma compartidos, todavía no hay conectores de Slack ni Jira y solo las reglas de Git tienen procedencia de identidad verificada. Revisalo en el repo antes de apoyarte en esa promesa.

¿Qué hace cada capa: RBAC, permisos del agente y verificación previa?

Cada capa responde una pregunta distinta, y por eso el autor propone usar las tres (“yes, and”, dice él). Ninguna reemplaza a las otras.

Capa	Qué decide	Límite
RBAC / IAM	El techo de lo que puede hacer cualquier identidad	Es estático y no distingue al agente del desarrollador si comparten credenciales
Permisos del agente	Qué corre sin preguntarte	Comparan texto del comando
Verificación previa a la ejecución	Si esta acción puntual debe ocurrir, con reglas confiables	Aegis es alpha y no ve llamadas que no pasan por el hook

Para ese último hueco, Aegis compila la misma política hacia la capa de plataforma: aegis compile aws genera Service Control Policies y aegis compile kubernetes genera ValidatingAdmissionPolicies. Cubre llamadas que nunca pasan por el hook, como un script con boto3. Ambas funciones son preview.

Tampoco está solo en el rubro. El propio README admite que nah, claude-code-safety-net y destructive_command_guard cubren más agentes y más tipos de comando que Aegis. Lo que Aegis dice aportar es la procedencia de las reglas. La comparación se chequeó contra los README de cada proyecto el 27/09/2026. Cubrimos ese tema en detalle en el enfoque de Meta con sus agentes.

¿Qué límites y fallas conocidas tiene este enfoque hoy?

Aegis-DevOps es alpha (v0.3.2 en PyPI) y el autor pide no ponerlo delante de nada importante sin leer antes los gaps abiertos. Lectores encontraron dos fallas esta semana, ambas en proceso de corrección según el autor:

• Una regla por namespace no coincide con comandos que dependen del contexto. Si el comando usa el namespace del contexto kube actual, la regla no lo ve.
• kubectl apply -f - se permite. El manifiesto llega por stdin y nunca se lee.

Además, aegis init escribe reglas de ejemplo firmadas con una clave pública de demo, y el README avisa que hay que reemplazarla antes de confiar en el resultado. Es una advertencia deliberada, y la CLI la imprime cada vez.

Qué está confirmado y qué no

• Confirmado por el autor: los resultados de la tabla de comandos, las dos fallas abiertas, el estado alpha y que la compilación a SCP y ValidatingAdmissionPolicies es preview.
• Confirmado en la documentación citada: que una regla deny de Claude Code no es un límite de seguridad (según el post, con revisión parcial nuestra).
• Sin verificación independiente: el benchmark, la cobertura de variantes y la robustez frente a ofuscaciones que no están en el post.
• Sin confirmar: el alcance real de los conectores de Slack y Jira y de la procedencia de identidad.

¿Cómo verificar si tu guardia de comandos es confiable?

Esta es una propuesta editorial, no un procedimiento del autor ni algo que hayamos probado. Armá una lista de diez variantes del mismo comando prohibido (orden de flags distinto, ruta absoluta, sudo, bash -c, una variable). Pasalas todas por tu guardia. Si alguna da ALLOW, el guardia compara texto y no intención.

Sumá una variante que el guardia no pueda analizar. La respuesta correcta es rechazarla, no dejarla pasar.

Errores comunes

• Tratar las reglas deny del agente como seguridad. Son comodidad. Corrección: sumá un hook o un control de plataforma.
• Dejar que el agente use tu kubeconfig. Corrección: dale una identidad propia con permisos mínimos.
• Dejar pasar lo que no se entiende. Un “no matcheó” no es un “está permitido”. Corrección: que el guardia rechace lo no verificable.
• Dejar la clave de ejemplo. Las reglas de demo de Aegis se firman con una clave pública. Corrección: reemplazala antes de usarlo en serio.

Preguntas Frecuentes

¿RBAC alcanza para proteger la infraestructura de un agente de IA?

No. RBAC fija el techo de lo que puede hacer una identidad, pero no distingue la acción puntual de un agente que usa las credenciales de un desarrollador. Mantenelo ajustado y sumá permisos del agente y una verificación previa. Complementá con comparación entre n8n y Activepieces.

¿Cómo evito que un agente de IA ejecute kubectl delete en producción?

Combiná tres capas: credenciales propias y acotadas para el agente, permisos del agente para lo que corre sin preguntar y un hook previo a la ejecución que entienda el comando. En la prueba del autor, Aegis bloqueó siete variantes de un kubectl delete en prod.

¿Las reglas de permisos de Claude Code son un límite de seguridad?

No. Según el post, la documentación dice que una regla deny “isn’t a security boundary around the program”: compara el texto del comando, por eso git -C . push origin main esquiva una regla sobre git push *.

¿Qué es un hook PreToolUse en Claude Code?

Es un punto de enganche que corre antes de que Claude Code use una herramienta, y desde donde se puede inspeccionar el comando completo y frenarlo. El post indica que la documentación lo recomienda para ese fin, y es el mecanismo que usa el plugin de Aegis.

¿Qué es una prompt injection en un ticket de Jira o un mensaje de Slack que lee un agente?

Es texto plantado en contenido que el agente lee, escrito para que lo trate como una instrucción o como una regla nueva. Aegis intenta neutralizarlo exigiendo que cada regla esté firmada sin cambios y que su autor tuviera autoridad para escribirla.

Conclusión

“Usá RBAC” es la mitad correcta de la respuesta. Mantené el techo de IAM ajustado, dale identidades propias a tus agentes y no confundas las reglas de permisos del agente con un control de seguridad. La otra mitad, la verificación previa, hoy la ilustra bien Aegis-DevOps, pero es alpha, con dos fallas abiertas y un benchmark del propio autor.

Mi recomendación: probá la propuesta de las diez variantes contra tu guardia actual, sea cual sea, y leé los gaps abiertos del repo antes de poner cualquier herramienta de este tipo cerca de producción.

Fuentes

• Documentación de Claude Code – permisos
• dev.to – “Just use RBAC” is half right, post del mantenedor de Aegis-DevOps
• GitHub – repositorio y README de Aegis-DevOps