Agentes de IA gestionados por contratistas: elimina correctamente el acceso a producción

Un contratista puede hacer un trabajo excelente con un agente de IA para programar y aun así dejar tu entorno de producción en peor estado que antes. El problema normalmente no empieza con una instrucción maliciosa. Empieza cuando todos suponen que otra persona se encarga del proceso del agente, de las aprobaciones y de la limpieza.

Trata un agente ejecutado por un contratista como un operador temporal de producción. Asígnale un patrocinador interno responsable, una identidad de proceso reconocible, una ruta de autoridad limitada y un procedimiento de retirada que alguien haya ensayado. Si no puedes nombrar al empleado que puede detenerlo hoy mismo, no has delegado el trabajo. Has creado un agente sin responsable.

La identidad de un contratista no puede ser propietaria de un agente de producción

La empresa propietaria del sistema de producción debe ser propietaria de la autoridad del agente, incluso cuando un contratista inicia y supervisa el proceso. La relación laboral del contratista, su cuenta personal, su portátil y su invitación de calendario terminan según condiciones que no controlas directamente. El acceso a producción no puede depender de ninguno de ellos.

Los equipos suelen confundir dos preguntas:

• ¿Quién opera el agente durante este trabajo?
• ¿Quién sigue siendo responsable de todas las capacidades que recibe el agente?

El contratista puede responder a la primera pregunta. Un empleado interno debe responder a la segunda. Esa persona necesita autoridad suficiente para pausar el trabajo, cambiar su alcance, inspeccionar los registros y terminar el acceso sin esperar a que el contratista responda.

He visto que esto sale mal de una forma muy corriente. Un contratista recibe una invitación a un repositorio de código y un token de API de producción porque necesita diagnosticar un problema. Usa un agente desde su propio equipo para inspeccionar el código, consultar la API y preparar una solución. El contrato termina, se deshabilita la cuenta del contratista en el repositorio y todos dan el asunto por cerrado. Semanas después, un perfil automatizado del terminal todavía tiene el token. El antiguo directorio de trabajo del agente aún contiene instrucciones que le indican cómo usarlo. La empresa ha eliminado a una persona de un sistema, pero no ha eliminado una ruta operativa de producción.

No conviertas la cuenta de usuario del contratista en la identidad permanente del trabajo del agente. Crea un registro del trabajo propiedad de la empresa y vincula el acceso a ese registro. El registro debe identificar al patrocinador interno, al custodio técnico, al operador, a los entornos aprobados, a la identidad del proceso y a la condición de finalización. Una persona puede cambiar de trabajo o desaparecer durante un fin de semana. Un registro puede seguir indicando al siguiente ingeniero de guardia qué existe y cómo apagarlo.

Esto no es burocracia por sí misma. Evita la forma más costosa de ambigüedad: un incidente en el que el equipo no puede determinar si una solicitud provino de un agente aprobado, de una configuración antigua de un contratista o de un atacante que reutilizó un acceso olvidado.

Pon a un empleado a cargo de la decisión de delegar

Todo trabajo con un contratista necesita un patrocinador que sea responsable de decidir que un agente puede actuar, no solo de contratar al contratista. Normalmente es el responsable de ingeniería, el propietario del servicio o el responsable del incidente con autoridad sobre el área de producción afectada.

Antes de que el agente reciba autoridad sobre producción, ese patrocinador debe responder cuatro preguntas concretas. ¿Qué trabajo hará el agente? ¿A qué entorno puede acceder? ¿Qué acciones forman parte del trabajo? ¿Cuándo termina el permiso?

Evita alcances vagos como «ayudar a mantener el servicio» o «colaborar en el despliegue». Esas frases se vuelven peligrosas cuando un agente puede interpretarlas a través de herramientas. Describe el trabajo en términos observables: inspeccionar las respuestas de error de este servicio, abrir una solicitud de cambios, ejecutar este comando de diagnóstico aprobado o enviar una solicitud de cambio para un endpoint concreto.

El patrocinador no tiene que estar junto al contratista todo el día. Sí debe ser responsable de los límites. Si un contratista dice que el trabajo ahora requiere escribir en una base de datos, un nuevo rol de infraestructura o acceso a otro servicio, se trata de una nueva decisión de delegación. No permitas que una aprobación anterior se amplíe silenciosamente para cubrir una solicitud nueva.

La Publicación Especial 800-207 del NIST plantea un punto útil en sus directrices de confianza cero: los sistemas no deben conceder confianza implícita solo porque un actor se encuentre en una red determinada o haya accedido antes a un recurso. Aplica esa lógica al trabajo de los agentes. Que un contratista esté en tu canal de chat, conectado a tu VPN o aprobado anteriormente para una operación de lectura no autoriza a otro proceso a realizar una escritura en producción.

Aquí es donde los equipos suelen elegir una simplificación equivocada. Conceden al contratista un acceso amplio y permanente porque las aprobaciones repetidas parecen lentas. Parecen lentas porque el trabajo no se ha definido con suficiente precisión. Corrige primero el límite del trabajo. El acceso amplio y permanente convierte un problema de planificación en un problema de respuesta a incidentes.

Ofrece al patrocinador un sustituto claro. Si se marcha, transfiere el registro del trabajo y vuelve a aprobar la autoridad bajo el nuevo patrocinador. Un proceso sin patrocinador actual debe perder el acceso automáticamente o deshabilitarse de inmediato de forma manual. No existe una razón legítima para que un trabajo desatendido de un contratista conserve autoridad sobre producción.

La procedencia del proceso debe formar parte de cada aprobación

Aprobar a una persona no es lo mismo que aprobar un proceso. Esta diferencia suele difuminarse y crea aprobaciones que cubren más software del que el revisor pretendía.

Una identidad humana indica quién se autenticó. Una identidad de proceso indica qué ejecutable solicitó una acción, dónde se ejecutó y si coincide con el proceso esperado. Cuando un agente de IA trabaja mediante shells, extensiones, servidores MCP, asistentes en segundo plano y scripts, el proceso es lo que realmente llega a la ruta de la credencial.

Solicita pruebas de que un proceso nuevo del agente es el proceso aprobado. En macOS, la autoridad de firma de código ofrece un punto de partida útil al revisor. Puede identificar la autoridad de firma que presenta un ejecutable. No puede demostrar que una solicitud de producción pertenece a este trabajo del contratista, ni decidir si la acción solicitada es sensata. Úsala como evidencia del proceso, no como un permiso general.

Una tarjeta de aprobación práctica debe mostrar algo más que el nombre visible del contratista. Debe identificar el proceso o lanzador, su autoridad de firma de código cuando esté disponible, el trabajo activo, el entorno de destino y la capacidad solicitada. Si el revisor no puede distinguir un proceso de agente conocido de un script copiado, la aprobación es demasiado débil.

Esto detecta un fallo habitual. Un contratista inicia un agente de programación aprobado en un terminal. Más tarde, un script de shell u otro proceso de agente hereda variables de entorno, lee un archivo de configuración local y realiza la misma solicitud mediante la misma credencial. Una aprobación basada solo en la persona no puede distinguir que se trata de solicitantes diferentes. El segundo proceso puede ser inofensivo, pero nadie lo ha establecido.

La respuesta adecuada no es exigir a los revisores una certeza imposible. Consiste en reducir lo que cubre una sola aprobación. Vincula las aprobaciones a una sesión o ejecución del proceso, identifica claramente esa ejecución y haz que la aprobación caduque cuando termine. Un proceso nuevo debe volver a identificarse.

Conserva un registro local del comando del proceso, el directorio de trabajo, la hora de inicio, el patrocinador y la condición de finalización esperada. No necesitas recopilar cada instrucción privada ni cada archivo que lea el contratista. Necesitas suficiente evidencia operativa para responder a una pregunta básica de un incidente: qué proceso aprobado realizó la acción, bajo qué autoridad y si seguía dentro del trabajo asignado.

La responsabilidad de aprobar debe seguir el impacto potencial

La persona que aprueba una acción del agente debe corresponderse con las consecuencias de esa acción. Un contratista puede aprobar acciones rutinarias dentro de una tarea delegada y limitada. No debe convertirse silenciosamente en la autoridad final para acciones capaces de modificar datos de producción, permisos, comunicaciones con clientes o infraestructura.

Divide la aprobación en dos niveles. El patrocinador autoriza la categoría de trabajo y su duración. El responsable de la acción autoriza una operación concreta cuando su impacto merece una decisión humana. En un equipo pequeño, un mismo empleado puede desempeñar ambas funciones. Aun así, mantén las responsabilidades separadas en el registro, porque más adelante responden a preguntas distintas.

Usa un modelo sencillo de responsabilidades:

• El patrocinador es responsable del propósito, el alcance y la caducidad del trabajo.
• El contratista operador es responsable de la calidad de la tarea y solicita acciones dentro del alcance.
• El responsable de la acción decide si permite una llamada sensible.
• El custodio técnico es responsable de la ruta de la credencial y del procedimiento de apagado.
• Seguridad u operaciones verifica que la revocación se haya completado.

No establezcas un ritual de aprobación para cada lectura inofensiva solo para demostrar que existe control humano. Los revisores harán clic sin leer y después pasarán por alto la solicitud que sí merece atención. Añade fricción cuando la acción cambie el estado, amplíe la autoridad, revele datos restringidos o llegue a un nuevo destino de producción.

La aprobación por llamada funciona mejor para operaciones fáciles de reconocer y difíciles de deshacer: escribir en el registro de un cliente, desplegar en producción, ejecutar un comando SSH con efecto administrativo o solicitar un cambio de permisos. La aprobación por sesión sirve para trabajos de investigación delimitados en los que el proceso necesita realizar varias lecturas relacionadas. El registro debe indicar cuál de las dos aplica antes de comenzar el trabajo.

La pantalla de aprobación también debe indicar el destino. «Permitir que el agente use la API» no ofrece casi ninguna información al revisor. «Permitir que este proceso aprobado envíe una solicitud POST al endpoint de facturación de producción» plantea una decisión que puede asumir. Un buen revisor aún puede rechazarla, solicitar un cambio o exigir que el contratista use staging.

La fatiga de aprobación es un fallo de diseño, no una razón para abandonar las aprobaciones. Si la cola se convierte en ruido, limita las herramientas, agrupa las operaciones seguras en una sesión breve o traslada la investigación a un entorno que no sea de producción. No lo soluciones haciendo permanente la autoridad sobre producción.

Mantén las credenciales fuera del contexto del agente

Un agente debe solicitar una acción, no contener el secreto que la autoriza. Esta es la línea que hace posible retirar el acceso.

Si el agente de un contratista recibe un token de API en texto plano, una clave privada SSH o un secreto copiado en un archivo de configuración, ya has perdido el control sobre dónde puede viajar esa credencial. El token puede acabar en el historial del terminal, la memoria del agente, los registros, archivos temporales, un cambio de código o una instrucción enviada a otro servicio. Rotar la credencial puede limpiar el problema, pero no permite reconstruir adónde llegó.

Usa una pasarela de acciones que conserve las credenciales en el lado controlado por la empresa y ejecute acciones HTTP o SSH aprobadas en nombre del agente. El agente recibe el resultado, no el secreto. Esto no convierte una acción insegura en segura. Proporciona al equipo un lugar donde aplicar la aprobación, registrar la llamada y revocar la autoridad sin buscar en el sistema de archivos del contratista.

Sallyport sigue este modelo para llamadas a API HTTP y comandos SSH: los secretos permanecen en su bóveda cifrada y el agente solicita acciones mediante una conexión MCP en lugar de recibir las credenciales. La propiedad útil aquí es la separación, no la magia. Un agente comprometido o descuidado aún puede solicitar acciones perjudiciales dentro del alcance concedido, por lo que la responsabilidad y las aprobaciones siguen siendo necesarias.

Trata cada ruta de credenciales como un elemento del inventario. Registra el propietario de la credencial, el destino, el tipo de acción permitido, la referencia del trabajo y el método de apagado. No te conformes con una nota que diga «token de producción usado por el contratista». Esa nota no proporciona a quien investiga un incidente ninguna información sobre dónde está el token, si se copió o qué ruta debe deshabilitarse.

SSH merece especial atención porque los equipos suelen suponer que un inicio de sesión en un host es temporal si el contratista también lo es. Comprueba las claves autorizadas, los certificados, el reenvío del agente local, el acceso mediante hosts de salto, los perfiles del shell, las tareas programadas y las copias remotas de scripts de despliegue. Eliminar una clave pública no revoca una clave privada que todavía pueda llegar a otro salto de confianza.

La misma regla se aplica a las credenciales HTTP. Elimina o deshabilita la ruta de acción y después verifica que el destino rechace una solicitud nueva. No lo des por terminado porque una pantalla de gestión de accesos muestre a un usuario deshabilitado. La pasarela de acciones, la cuenta de servicio, la credencial de API y la ruta de red pueden tener ciclos de vida independientes.

Diseña la revocación antes de conceder el acceso

El equipo debe poder revocar un agente gestionado por un contratista sin pedirle colaboración. Si el procedimiento requiere su portátil, su gestor de contraseñas o su memoria, no es un procedimiento de revocación.

Escribe la ruta de apagado antes de la primera acción en producción. Debe cubrir el proceso del agente, la sesión de aprobación, la ruta de la credencial, el acceso al código fuente y a la infraestructura, el trabajo programado y la conservación de la auditoría. Cada elemento necesita un operador designado y una forma de verificar que se ha completado.

La diferencia entre deshabilitar y revocar importa. Deshabilitar detiene el uso futuro de una cuenta o credencial concreta. Revocar termina la relación de autoridad activa y elimina las rutas que podrían restaurarla. La cuenta de un contratista puede estar deshabilitada mientras un proceso que ya estaba en ejecución conserva una sesión activa. Un token puede estar revocado mientras una conexión SSH permanece abierta. Gestiona ambos estados.

Usa esta secuencia cuando termine el trabajo o deba detenerse de inmediato:

1. Bloquea las nuevas acciones del agente en la pasarela de credenciales o el punto de autorización y revoca las sesiones activas vinculadas al trabajo.
2. Detén los procesos conocidos del agente, tanto locales como remotos, incluidos multiplexores de terminal, agentes de lanzamiento, trabajos de CI y tareas programadas.
3. Deshabilita o rota las credenciales de la empresa asignadas al trabajo y elimina el acceso al repositorio, la nube, la VPN, el bastión y el sistema de tickets.
4. Busca en el inventario del trabajo configuraciones copiadas, scripts generados, claves de despliegue y cuentas de servicio temporales, y elimínalos.
5. Verifica el rechazo intentando una comprobación inofensiva de la ruta autorizada y conserva los registros de acciones antes de cerrar el trabajo.

El orden importa. Si empiezas eliminando registros o deshabilitando la cuenta del contratista, puedes perder la información necesaria para localizar las sesiones activas. Detén primero las rutas de acción, conserva las pruebas y después limpia los accesos.

No declares el éxito porque cada casilla tenga un responsable. Prueba el procedimiento durante el trabajo. Pide al custodio que revoque una sesión de no producción mientras el contratista está presente. Confirma que el agente no puede realizar otra llamada, que el contratista entiende qué se detuvo y que el registro de actividad muestra la denegación. La primera vez que el equipo descubra una ruta de apagado inexistente no debería ser durante un incidente de seguridad o una disputa contractual.

Un registro breve del trabajo revela las decisiones pendientes

Un registro pequeño y revisable detecta más problemas reales que una política de acceso extensa que nadie lee. Guárdalo con el ticket de trabajo o en un repositorio de operaciones controlado, no dentro de un hilo privado de chat.

Este ejemplo es deliberadamente sencillo. Sustituye los valores de ejemplo por tus propios identificadores, pero no omitas campos porque el trabajo parezca temporal.

engagement: contractor-search-repair-2025-04
sponsor: employee-ops-owner
technical_custodian: employee-platform-owner
contractor_operator: external-developer
purpose: diagnose production search indexing failures
agent_process:
  approved_launcher: signed-local-agent-process
  allowed_workstation: managed-mac-asset-184
  expires_at: 2025-04-30T17:00:00Z
scope:
  environments: [staging, production-read]
  permitted_actions:
    - GET search-service health endpoint
    - GET indexing queue depth endpoint
  prohibited_actions:
    - production writes
    - credential administration
approval:
  session_owner: employee-ops-owner
  per_call_owner: employee-platform-owner
credential_routes:
  - search-api-read-route
  - bastion-diagnostic-route
revocation_owner: employee-platform-owner
verification_owner: employee-security-owner

El registro separa elementos que la gente suele agrupar bajo una sola etiqueta. contractor_operator no es sponsor. session_owner no es necesariamente per_call_owner. revocation_owner no es la persona que decidió que el trabajo era necesario. Esta separación evita que el contratista termine aprobando en la práctica su propia ampliación de autoridad y evita que un responsable ausente se convierta en la única persona capaz de detener el acceso.

El campo permitted_actions debe usar verbos y destinos. «Solo lectura» es demasiado impreciso cuando un servicio tiene endpoints que activan exportaciones, revelan datos personales o consumen capacidad. «Lectura de producción» también debe interpretarse con cuidado. Una lectura puede exponer datos regulados o detalles operativos que faciliten un ataque.

Establece una fecha de caducidad aunque el contrato no tenga una fecha exacta de finalización. Amplíala mediante una nueva decisión si el trabajo continúa. Una renovación explícita obliga al patrocinador a comprobar si el trabajo todavía necesita acceso a producción y si el proceso original sigue siendo el proceso utilizado.

Los registros de auditoría deben responder preguntas operativas

Un registro de auditoría del trabajo de un agente debe responder quién autorizó la acción, qué proceso la solicitó, a qué destino llegó, si tuvo éxito y cuándo alguien revocó la autoridad. Una transcripción de chat no puede responder de forma fiable a todo eso.

Siempre que sea posible, conserva dos vistas. Una sigue la ejecución o sesión del agente, de modo que quien investiga pueda ver el ciclo de vida de la autorización y detener una ejecución activa. La otra sigue las acciones individuales, para que un operador pueda inspeccionar una llamada de API o un comando SSH concreto. Vincula ambas vistas al mismo registro de eventos subyacente en lugar de mantener historias separadas manualmente.

Protege el registro de auditoría frente al proceso que registra. Un proceso que pueda modificar su propio historial puede ocultar las pruebas más relevantes. El almacenamiento de solo anexado, el acceso de escritura restringido y el encadenamiento criptográfico ayudan, pero cada mecanismo tiene una función. Una cadena puede revelar que los registros fueron alterados o eliminados. No puede decirte si la solicitud original era una buena idea.

Sallyport mantiene diarios de sesiones y actividad proyectados desde un registro de auditoría cifrado y encadenado mediante hashes. Su comando sp audit verify puede verificar la cadena sin conexión sobre el texto cifrado, algo útil cuando el equipo que contiene la bóveda está bloqueado o cuando quien investiga no debe leer los secretos.

Para cada trabajo, decide quién revisa los registros y cuándo. Una escritura sensible en producción puede requerir una revisión antes de que el contratista continúe. Una tarea breve de diagnóstico puede requerir revisión solo al cerrarse. Aun así, el equipo debe saber cómo localizar los eventos durante un incidente.

Conserva también las denegaciones. Una acción denegada puede revelar que el agente intentó superar su alcance, que el contratista entendió mal la tarea o que un proceso obsoleto sigue activo después de la desvinculación. Si solo conservas las llamadas exitosas, eliminas las pruebas que a menudo explican el siguiente incidente.

El contrato debe coincidir con el diseño de acceso

Un contrato no puede revocar un token de API, pero sí puede eliminar la ambigüedad que lleva a los equipos a dejar accesos activos. Redacta las obligaciones operativas de forma que correspondan a los controles reales que usa tu equipo.

Indica que la empresa es propietaria de las credenciales, los registros de procesos, los registros de auditoría y cualquier configuración de acceso creada para el trabajo. Indica que el contratista debe usar rutas aprobadas y controladas por la empresa para las acciones de producción, y que no puede copiar credenciales en archivos locales, instrucciones, repositorios ni servicios de terceros. Si el trabajo necesita una excepción, exige una aprobación escrita del patrocinador antes de que se produzca.

Incluye la obligación de devolver y eliminar los materiales del trabajo, pero no dependas de una declaración como único control. Los contratistas pueden actuar de buena fe y aun así pasar por alto un archivo del historial del shell, una variable de entorno almacenada en caché o una copia de seguridad. La revocación técnica gestiona lo que puedes controlar. Las condiciones contractuales cubren las obligaciones que quedan fuera de tus sistemas.

Define el final del trabajo operativamente: el patrocinador cierra el trabajo, el custodio deshabilita las rutas de acción, el responsable de verificación confirma la prueba de denegación y el equipo conserva el registro de auditoría según sus reglas normales de retención. Si el contratista necesita acceso de soporte más adelante, abre un trabajo nuevo en lugar de reactivar el antiguo.

Evita cláusulas que digan que el contratista es «responsable de la seguridad» sin nombrar decisiones y controles concretos. Esa redacción parece firme, pero deja sin respuesta las preguntas difíciles cuando alguien solicita un cambio en producción a las seis de la tarde. Especifica quién puede aprobar el cambio, quién lo ejecuta y quién puede detenerlo.

El primer documento que debes preparar no es una política general de IA. Es el registro del trabajo del próximo contratista que necesite un agente cerca de producción. Complétalo junto con el patrocinador y el custodio, en la misma sala. Cada campo vacío señala directamente una tarea que el equipo aún debe resolver antes de conceder el acceso.