Un agent personalitzat a GitHub Copilot CLI és un perfil configurat amb un rol, un conjunt acotat d'eines i regles de permisos que decideix què pot executar sense supervisió i què ha de demanar aprovació. Per a auditories de seguretat, l'objectiu és que l'agent pugui escanejar codi o infraestructura i generar troballes, però sense capacitat de llegir secrets, variables d'entorn completes o credencials emmagatzemades al sistema.
Què és realment un agent personalitzat a Copilot CLI
Copilot CLI permet definir agents amb un nom, una descripció de propòsit i un conjunt d'eines associades: execució de comandes, lectura i escriptura d'arxius, accés a servidors MCP per a integracions externes. La diferència respecte a usar Copilot CLI en mode genèric és que l'agent queda encapsulat: no hereta automàticament tot el context ni tots els permisos de la sessió del desenvolupador que l'invoca.
Els camps que defineixen el rol de l'agent
Un agent d'auditoria ben definit especifica com a mínim quatre coses: el rol, les eines permeses, l'abast del sistema de fitxers i el model assignat a la tasca. Com més d'aquests camps deixis per defecte, més ampli és el permís implícit que l'agent acaba tenint.
- Rol: què audita i sobre quin repositori o entorn
- Eines: comandes de shell explícites, no accés genèric a terminal
- Filesystem: rutes de només lectura per al codi, ruta separada per als informes
- Xarxa: accés desactivat excepte als endpoints estrictament necessaris
El permís d'eina no és el mateix que l'aïllament real
Restringir eines una a una no elimina el risc si aquestes eines es poden combinar. Un agent amb permís de llegir arxius i, per separat, permís de fer peticions HTTP, no té individualment cap permís perillós, però la combinació sí permet llegir un secret i enviar-lo a un destí extern en una sola cadena d'accions.
Per què la llista d'"allowed tools" no és un guardrail suficient
L'estudi de fatiga de seguretat del NIST (Stanton et al., 2016) va documentar un patró que aplica aquí: quan un sistema demana aprovació repetidament per accions similars, les persones comencen a aprovar per costum en lloc d'avaluar cada sol·licitud, cosa que anul·la el propòsit del control.
Com evitar exposar credencials en automatitzar auditories
Executa l'agent en un usuari o contenidor sense accés a variables d'entorn de producció, munta només els directoris de codi necessaris com a només lectura, i treu qualsevol credencial real cap a un gestor de secrets al qual l'agent no té accés directe.
- Executar l'agent en usuari/contenidor separat, sense variables de producció
- Muntar el codi com a només lectura; separar la carpeta d'informes
- Substituir credencials personals per tokens de servei d'abast mínim
- Auditar la combinació d'eines permeses, no només cada eina per separat
Quan NO convé automatitzar l'auditoria amb un agent
Si el teu equip és petit i fa una auditoria trimestral, muntar un agent amb aïllament complet pot ser més esforç de manteniment que el problema que resol. Un script programat més revisió manual segueix sent l'opció més senzilla en aquest cas.
La fallada que més vegades reparem no és un agent mal configurat, és un agent configurat per a un cas que no ho necessitava.
Passos pràctics per desplegar el teu primer agent d'auditoria
- Defineix el rol en una frase concreta
- Llista les eines mínimes i revisa combinacions de risc
- Aïlla l'entorn d'execució
- Substitueix credencials personals per tokens de servei
- Defineix quines accions requereixen aprovació manual sempre
Si vols automatitzar auditories de seguretat amb agents IA sense arriscar credencials de producció, a Blurtek dissenyem l'aïllament i els guardrails abans d'escriure cap configuració.
Solicitar diagnóstico