agent-access-review: revisiones de acceso para agentes de IA y servidores MCP

Qué hace

agent-access-review es una herramienta de línea de comandos de código abierto, publicada bajo licencia MIT por el usuario de GitHub Mihirajmera, que aplica el proceso de revisión de acceso de usuarios a los agentes de IA. Inventaria todos los agentes y servidores MCP que ejecuta una organización, determina qué puede leer, escribir, ejecutar y enviar cada uno, prueba ese acceso contra un catálogo de controles y produce el paquete que espera un auditor: una hoja de aprobación del revisor, evidencia con hash y resultados de evaluación OSCAL mapeados a NIST 800-53, SOC 2, el NIST AI Risk Management Framework y el OWASP Top 10 for LLM Applications.

El autor lo resume como la revisión trimestral de "quién tiene acceso a qué" que las empresas ya realizan para los empleados, aplicada a los agentes de IA. Como caso de estudio real, el proyecto informa lo que resulta de copiar las configuraciones MCP que aparecen en los README oficiales: 8 de 9 paquetes sin versión fijada, 7 de 9 con acceso de escritura, envío o ejecución no revisado, y una ruta de exfiltración una vez que se combinan los permisos.

Inicio rápido

La herramienta requiere Python 3.11 o superior. No necesita cuenta en la nube, claves de API ni acceso a la red.

pip install agent-access-review
agent-access-review demo

La demo revisa cinco agentes de ejemplo y escribe el paquete en review-demo/; el informe es review-demo/access-review.md, y también hay un informe de muestra en el repositorio.

Para revisar una configuración real, se apunta el análisis a un archivo de configuración:

Los secretos encontrados en las configuraciones se enmascaran antes de escribir cualquier cosa, por lo que la salida es segura para compartir.

Términos clave

• Agente de IA: un modelo de IA que puede realizar acciones mediante herramientas: leer archivos, consultar bases de datos, enviar correo electrónico o ejecutar comandos.
• MCP (Model Context Protocol): la forma estándar en que aplicaciones como Claude Desktop, Cursor y VS Code conectan herramientas a una IA. Cada servidor MCP en una configuración es una herramienta que el agente puede usar.
• Revisión de acceso de usuarios (UAR): la comprobación periódica en la que se lista el acceso de cada persona, un responsable confirma que sigue siendo necesario y se revoca el resto; los auditores la prueban bajo SOX y SOC 2.
• ITGC: IT General Controls, los controles básicos (acceso, gestión de cambios, operaciones) que los auditores prueban para la información financiera.
• Identidad no humana: una cuenta usada por software y no por una persona: cuentas de servicio, claves de API y ahora agentes de IA.
• Ruta de exfiltración: una vía para que los datos salgan de la organización; aquí, un agente que puede leer datos sensibles, lee contenido que un atacante puede escribir y puede enviar datos al exterior.
• Inyección de prompt: ocultar instrucciones en contenido que una IA lee (un correo, una página web o un ticket) para que haga algo que su usuario nunca pidió.
• OSCAL: el formato legible por máquina de NIST para controles de seguridad y resultados de evaluación, que permite a las herramientas GRC importar hallazgos automáticamente.

El problema

Todo programa SOX y SOC 2 ejecuta revisiones trimestrales de acceso de usuarios: listar quién tiene acceso a qué, hacer que un responsable confirme que sigue siendo necesario, revocar el resto y conservar la evidencia. Los agentes de IA ahora tienen el mismo tipo de acceso (tokens de API, conexiones a bases de datos, acceso a shell, buzones) y casi nadie los revisa. El README enumera cuatro carencias:

• Sin responsable, sin aprobación. Un desarrollador añade un servidor MCP a su configuración de Claude Desktop o Cursor y el agente obtiene de inmediato el token de GitHub y el directorio personal de esa persona: sin ticket, sin aprobador, y nunca aparece en una revisión de acceso.
• Demasiado amplio por defecto. Las guías de instalación indican conceder todo el directorio personal, el alcance de repositorio con control total o permisos *.All de Microsoft Graph para todo el inquilino.
• Secretos en texto plano. Las configuraciones MCP suelen contener tokens y contraseñas de bases de datos sin cifrar.
• Una nueva vía de ataque. Un agente que puede leer datos sensibles, lee contenido escrito por un atacante (una incidencia de GitHub, un correo, una página web) y puede enviar datos al exterior puede ser inducido mediante inyección de prompt a filtrar esos datos; ningún control de acceso tradicional examina esa combinación.

La premisa del autor es que los agentes son identidades no humanas: necesitan los mismos controles de joiner/mover/leaver y recertificación que las personas, más algunos específicos de la IA.

El catálogo de controles

El texto de presentación describe la revisión como una prueba de acceso contra 12 controles, mientras que el propio catálogo y la arquitectura de la herramienta enumeran 14 comprobaciones, numeradas de AAR-01 a AAR-14:

Cada control se define una sola vez en controls.yaml y se cruza con todos los marcos, de modo que una sola prueba produce evidencia para todos ellos. El autor señala que los mapeos a los marcos son su propio criterio y deben verificarse contra los crosswalks oficiales antes de utilizarse en una auditoría real.

Rutas de exfiltración: el riesgo específico de la IA (AAR-09)

Las revisiones de acceso tradicionales examinan un permiso cada vez. En los agentes de IA, el peligro es una combinación: un agente que puede leer datos sensibles, lee contenido escrito por un externo y puede enviar datos al exterior. Cada tramo es inofensivo por sí solo; juntos, una sola inyección de prompt oculta en un correo, ticket, incidencia o página web puede ordenar al agente filtrar los datos. Un paso de aprobación humana en cualquiera de los tramos rompe la cadena.

El README lo ilustra con dos agentes de ejemplo. finance-ops-agent queda marcado: cualquiera puede escribir a su buzón de cuentas por pagar (entrada no confiable), lee facturas de proveedores restringidas en NetSuite y puede enviar correo a cualquier destinatario sin aprobación humana. support-copilot supera la prueba: lee tickets de clientes e historial confidencial de tickets, pero una persona aprueba cada respuesta redactada antes de enviarse al cliente.

AAR-09 se mapea a OWASP LLM01 (inyección de prompt) y LLM02 (divulgación de información sensible), NIST 800-53 AC-4 (aplicación del flujo de información) y NIST AI RMF MEASURE 2.7 (seguridad y resiliencia de la IA).

Cómo funciona

• Descubrir. Se apunta a archivos o carpetas. Lee dos formatos: configuraciones MCP (Claude Desktop, Cursor, VS Code .vscode/mcp.json), que cubren servidores locales npx, uvx o docker y servidores HTTP remotos (estas configuraciones no llevan responsable ni aprobación, que según el autor es exactamente por qué son el problema de la IA en la sombra), y manifiestos de agentes (agents.yaml), un registro gobernado para agentes LangChain, CrewAI o personalizados con responsable, aprobación, herramientas, alcances, credenciales y fechas de último uso.
• Clasificar. Una configuración MCP dice qué servidor se ejecuta, no qué puede hacer; el catálogo de capacidades convierte el nombre de un servidor en un permiso: acciones, clasificación de datos, si ingiere contenido no confiable y si puede enviar datos al exterior. Los servidores desconocidos se marcan bajo AAR-12 y nunca se asumen seguros.
• Enmascarar y luego hashear. Los secretos se enmascaran durante el análisis, antes de almacenar nada, de modo que la evidencia pueda compartirse con auditores. El inventario de cada agente y su registro fuente enmascarado se hashean con SHA-256 sobre JSON canónico, de modo que cualquier edición posterior de la evidencia sea detectable.
• Revisar. Cada permiso de herramienta recibe una decisión recomendada (Keep, Modify, Revoke o Investigate) más una columna vacía para el revisor, con la misma forma que una hoja de cálculo de revisión de acceso de usuarios.
• Exportar. La herramienta emite resultados de evaluación OSCAL 1.1.2: una observación por agente que apunta a su archivo de evidencia y hash, y un hallazgo por objetivo de control de NIST 800-53.

El ciclo de revisión refleja la revisión trimestral de acceso de usuarios que los auditores SOX y SOC 2 ya prueban para las personas: descubrir configuraciones y manifiestos, clasificar mediante el catálogo de capacidades, probar los controles, dejar que cada responsable revise cada permiso de herramienta, conservar la evidencia hasheada y la salida OSCAL para los permisos marcados como Keep, abrir un ticket de remediación y volver a analizar en caso de Modify o Revoke, y recertificar cada 90 días.

Ejecución de muestra

Los ejemplos incluidos son la configuración de Claude Desktop de un desarrollador, una configuración MCP de VS Code y tres agentes gobernados; la salida completa está en sample-output/: el paquete del revisor, la hoja de decisiones, la evidencia hasheada y el OSCAL. Al ejecutar la demo se obtiene:

$ agent-access-review demo
AGENT                        TOOLS  HIGH   MED   LOW
support-copilot                  2     0     0     0
finance-ops-agent                4     4     3     0
devops-agent                     2     6     1     1
claude-desktop-config            6    12     5     1
vscode-mcp                       3     6     2     3
5 agents · 17 tool grants · 44 findings

Por severidad, los hallazgos se reparten en 28 high, 11 medium y 5 low. Los controles que más fallan entre los cinco agentes:

Un extracto del paquete del revisor para finance-ops-agent:

En los hallazgos de muestra, finance-ops-agent lee facturas de proveedores en NetSuite (datos restricted), lee un buzón al que los proveedores pueden escribir (entrada no confiable) y puede enviar correo (salida) sin aprobación humana: una ruta AAR-09, lo que significa que un solo correo de factura manipulado podría hacer que el agente enviara los datos bancarios de los proveedores. Su aprobación tiene 216 días de antigüedad y su herramienta OCR no se usa desde hace 164 días, por lo que se marca como Revoke. El ejemplo claude-desktop-config otorga a un agente todo el directorio personal /Users/dev, un terminal sin sandbox, un token de GitHub y una contraseña de base de datos en texto plano, y ejecuta cuatro paquetes sin fijar. support-copilot supera todas las comprobaciones: escribe en tickets, pero una persona aprueba antes de que se envíe nada. CI regenera sample-output/ en cada push y falla si difiere de lo confirmado en el repositorio, de modo que la muestra siempre coincide con el código actual.

Cómo leer los resultados

Cada permiso de herramienta recibe una decisión recomendada, registrada en el paquete y en el CSV:

La severidad se define así: high significa corregir antes del próximo uso del agente (un agente sin responsable, secretos en texto plano, una ruta de exfiltración); medium significa corregir dentro del ciclo de revisión (una aprobación caducada, un paquete sin fijar); low significa una laguna en la evidencia más que un riesgo (sin registros de uso, sin fecha de rotación). El revisor completa la columna vacía de decisión y la tabla de aprobación; el paquete completado más los archivos de evidencia hasheada constituyen la evidencia de auditoría de la revisión.

Ejecución

Además de instalar una versión con pip, la herramienta puede ejecutarse desde el código fuente, con dependencias fijadas exactamente en requirements.txt:

git clone https://github.com/Mihirajmera/agent-access-review.git
cd agent-access-review
python -m venv .venv && source .venv/bin/activate     # Windows: .venv\Scripts\activate
pip install -r requirements.txt
python -m agent_access_review demo                    # escribe review-demo/
pytest -q

El comando scan admite --out DIR (por defecto review/), --as-of YYYY-MM-DD (la fecha usada para recertificación, rotación e inactividad) y --fail-on high|medium|low (sale con código 1 si un hallazgo alcanza o supera esa severidad). agent-access-review --help lista ejemplos.

Como barrera de CI

Las configuraciones MCP y agents.yaml pueden vivir en el repositorio para bloquear pull requests que den a un agente acceso sin fijar, archivado, vulnerable o excesivamente privilegiado:

# .github/workflows/agent-access.yml
on: pull_request
permissions:
  contents: read
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Mihirajmera/[email protected]   # or a commit SHA
        with:
          paths: .mcp.json .vscode/mcp.json agents.yaml   # files or folders; default "."
          fail-on: high                                    # high | medium | low | never

El paquete de revisión se incluye en el resumen del trabajo y el paso falla ante hallazgos iguales o superiores al umbral fail-on. Un repositorio sin configuraciones recibe un aviso en lugar de un fallo. La salida report contiene la ruta del paquete, de modo que la carpeta (por defecto agent-access-review/) puede subirse como artefacto. El autor recomienda fijar la acción a una etiqueta de versión o a un SHA de commit en lugar de main para que una versión nueva no pueda cambiar la barrera sin revisión, algo que describe como el control AAR-10 aplicado a la propia herramienta. Sin la acción, pip install agent-access-review seguido de agent-access-review scan ... --fail-on high hace lo mismo.

Decisiones de diseño

• Los agentes son identidades, no aplicaciones. La revisión se modela sobre las revisiones de acceso de usuarios de ITGC (responsable, aprobación, recertificación, inactividad, higiene de credenciales) porque ese es el marco de control que los auditores ya prueban; los riesgos específicos de la IA se añaden encima, no en su lugar.
• AAR-09 mira combinaciones, no permisos aislados. Cada tramo de una ruta de exfiltración es inofensivo por sí solo; el riesgo solo aparece cuando un agente reúne los tres, razón por la que las revisiones de permisos tradicionales lo pasan por alto. Un paso de aprobación humana en el tramo de entrada no confiable o de salida rompe la cadena.
• Fallar cerrado ante herramientas desconocidas. Un servidor MCP no clasificado es un hallazgo, no un aprobado; como el catálogo es datos, un equipo de GRC puede ampliarlo sin tocar código.
• Enmascarar antes de hashear. La evidencia que contiene secretos no puede compartirse, y enmascarar después rompería el hash, por lo que el enmascarado ocurre en el analizador.
• Las etiquetas de Docker cuentan como no fijadas. Solo un digest de imagen es inmutable; :v1.0 puede volver a publicarse.

Limitaciones

• Revisa la configuración, no el comportamiento en tiempo de ejecución: ve que un agente puede enviar correo, no lo que realmente envió. Las fechas de uso provienen del manifiesto, que en producción se alimentaría de registros de llamadas a herramientas.
• El catálogo de capacidades es aproximado: describe lo que un servidor puede hacer por defecto, y los alcances reales de un token (por ejemplo, un PAT de GitHub de grano fino) pueden ser más estrechos; el formato de manifiesto permite registrar los alcances exactos.
• Las configuraciones JSON con comentarios se omiten con una advertencia.

Lo que el autor haría a escala empresarial

• Descubrir desde endpoints, no desde archivos: recopilar configuraciones MCP de portátiles gestionados mediante MDM o EDR, e identidades de agentes desde el IdP (service principals, aplicaciones OAuth), de modo que los agentes en la sombra afloren automáticamente.
• Alimentar el uso desde registros: rellenar last_used a partir de registros de gateway o proxy MCP para que AAR-08 se base en evidencia y no en autodeclaración.
• Ejecutar la revisión en la plataforma GRC: enviar la hoja de decisiones a ServiceNow GRC o SailPoint como campaña de certificación con responsables, plazos y escalado, y revocar automáticamente los permisos no certificados.
• Cerrar el ciclo: convertir los hallazgos OSCAL no satisfechos en elementos POA&M con responsables y plazos.

Según el README, la forma más sencilla de contribuir es añadir un servidor MCP al catálogo de capacidades (ver CONTRIBUTING.md); los cambios se listan en el CHANGELOG y el proyecto se publica bajo licencia MIT.