Acceso temporal a producción: permisos que terminan con la tarea

El acceso de producción de un agente de programación de IA debería terminar porque el sistema de autorización indica que ha terminado, no porque alguien pensara volver más tarde. Un propósito, una fecha límite y una comprobación de cierre convierten una excepción arriesgada en un permiso acotado que otro ingeniero puede revisar.

He visto fallar los controles de acceso de la forma más aburrida: el incidente se resuelve, la tarea se cierra y la credencial sigue siendo útil. Ese día no ocurre nada espectacular. Meses después, la misma credencial aparece en un script sin relación, un proceso antiguo del agente se reanuda o alguien la usa porque resulta conveniente. La excepción original se ha convertido por descuido en acceso permanente a producción.

El acceso temporal a producción necesita tres datos que el punto de aplicación pueda evaluar: por qué el agente puede actuar, qué puede tocar y cuándo debe detenerse. La última parte importa tanto como las dos primeras. Si no puedes demostrar un rechazo después de cerrar la tarea, la tarea no ha terminado.

Una fecha límite debe rechazar solicitudes, no adornar un ticket

Una hora de finalización solo tiene fuerza cuando el componente que ejecuta o autoriza la acción la comprueba en cada solicitud. Un gestor de proyectos, una entrada del calendario o un recordatorio en el chat no pueden impedir que un proceso antiguo llame a una API a las 02:00.

Esta diferencia sorprende a los equipos porque su proceso de cambios parece disciplinado. Exigen un ticket, un revisor y un estado de cierre. Después entregan al agente una credencial que sigue siendo válida hasta que alguien la rota manualmente. El flujo de trabajo registra la intención, mientras la credencial conserva la autoridad.

Coloca la caducidad donde la solicitud entra en producción. Según el diseño, puede ser un proveedor de identidad que emita un token de corta duración, una pasarela de acceso que compruebe una base de datos de permisos, un validador de certificados SSH o un intermediario que conserve la credencial y ejecute la acción. El servicio protegido debe recibir una solicitud que pueda rechazar después de la fecha límite.

NIST SP 800-207 plantea una idea útil en su descripción de la arquitectura de confianza cero: las decisiones de acceso deben evaluarse antes de establecer una sesión con un recurso empresarial y el acceso debe concederse por sesión. Eso no significa que cada aplicación tenga que copiar un producto completo de confianza cero. Sí significa que conceder una sesión una vez y suponer que seguirá siendo apropiada para siempre contradice el modelo.

En el caso de los agentes, evalúa al menos el inicio de cada acción. El trabajo de larga duración necesita una decisión adicional: permitir que la operación ya iniciada termine bajo una concesión limitada o cancelarla cuando expire la concesión. Decide ese comportamiento antes de una interrupción, porque un corte imprevisto durante la reparación de una base de datos puede ser tan perjudicial como un acceso sin restricciones.

La fecha límite debe usar una marca de tiempo con una única referencia horaria acordada, normalmente UTC. No escribas «hasta el final del día» esperando que todos los sistemas entiendan lo mismo. Guarda 2025-04-18T16:30:00Z, muestra la hora local a la persona que aprueba y haz que la ruta de solicitud compare con la marca almacenada.

El propósito debe limitar el permiso

Un propósito solo sirve si limita lo que el agente puede hacer. «Ayudar con producción» e «investigar la alerta» describen una intención general, no un límite de autorización.

Escribe el propósito de modo que un ingeniero que no haya aprobado el permiso pueda decidir si una solicitud pertenece a él. Una declaración útil nombra el trabajo que la activa, el objetivo, la operación permitida y la condición esperada de finalización. Por ejemplo:

Investigar el aumento de errores en el checkout del incidente INC-482. Leer los registros y el estado del despliegue del servicio de checkout. Reiniciar el worker de checkout solo si el responsable del incidente aprueba el reinicio. Finalizar el acceso cuando INC-482 se resuelva o a las 16:30 UTC, lo que ocurra primero.

Esa declaración permite tomar decisiones. Leer una base de datos de facturación no encaja. Publicar un cambio de una aplicación sin relación tampoco. Reiniciar el worker requiere una condición de aprobación identificada. El agente puede seguir siendo útil sin recibir un cheque en blanco.

El alcance necesita algo más que una etiqueta de producción. Vincula el permiso a objetivos concretos:

• hosts de API, repositorios o hosts SSH identificados
• métodos o comandos concretos, como GET /health o una consulta del estado de un despliegue
• entornos e identificadores de cuenta concretos
• un número máximo de acciones o una tasa máxima de solicitudes cuando la tarea pueda implicar llamadas repetidas
• una persona responsable que pueda detener el trabajo

Evita la recomendación habitual de dar a un agente acceso amplio de lectura porque «leer es seguro». El acceso de lectura suele exponer registros de clientes, configuración, topología, historial de despliegues o credenciales incluidas en registros antiguos. También permite que el agente recopile mucho más contexto del que exige el propósito. Dale los endpoints específicos de observabilidad y el intervalo de consulta de registros que necesita la tarea.

Hay otro límite que los equipos suelen confundir: el propósito de una tarea no es lo mismo que un prompt. El prompt indica al agente lo que le pediste intentar. El propósito de autorización indica al punto de aplicación lo que puede permitir aunque el prompt cambie, el modelo haga una inferencia equivocada o la salida de una herramienta contenga instrucciones hostiles. Trata los prompts como entradas no confiables para la decisión de acceso.

Las credenciales y la autoridad caducan de forma distinta

Una credencial demuestra que quien llama posee algo. La autorización decide si esa persona o proceso puede realizar esta solicitud ahora. Ambas partes deben terminar cuando acaba el trabajo.

Un bearer token con una declaración exp puede ser un buen límite temporal si la API receptora valida la firma, la audiencia y la caducidad en cada solicitud. No es una solución universal. Algunos servicios almacenan la autenticación en caché, aceptan tokens opacos validados en otro lugar o autorizan un token contra un estado del servidor que sigue activo. Un token que caduca en 15 minutos también incumple el límite de la tarea si lo emitiste para un trabajo que terminó en cuatro minutos.

El mismo problema aparece con SSH. OpenSSH admite certificados de usuario firmados con un intervalo de validez. El manual de ssh-keygen documenta -V como la opción del intervalo de validez. Un certificado de corta duración es mucho mejor que colocar una clave privada de larga duración en el espacio de trabajo de un agente, pero su caducidad solo responde a la cuestión temporal. También debes restringir las entidades principales, los hosts de destino y el comportamiento de los comandos.

Este comando muestra un certificado válido durante 20 minutos:

ssh-keygen -s ./user_ca -I agent-run-7f3a \\
  -n deploy-readonly -V +20m ./agent-run-7f3a.pub

La salida normalmente indica el archivo de clave pública firmado, por ejemplo:

Signed user key ./agent-run-7f3a-cert.pub: id "agent-run-7f3a" serial 0 for deploy-readonly valid from 2025-04-18T16:00:00 to 2025-04-18T16:21:00

No confundas ese certificado con un permiso completo para una tarea. Si la cuenta remota puede ejecutar comandos arbitrarios, el certificado sigue autorizando comandos arbitrarios hasta las 16:21. Usa una cuenta restringida, un comando forzado o una lista de comandos permitidos en el host cuando el trabajo lo requiera.

La revocación y la caducidad también son distintas. La caducidad es predecible y funciona incluso cuando un servicio central de revocación no está disponible. La revocación termina la autoridad antes de tiempo cuando el incidente se resuelve, el agente se comporta de forma inesperada o una persona que aprobó retira su consentimiento. Un buen diseño admite ambas: una duración máxima corta y una revocación inmediata.

El cierre de una tarea necesita un evento legible por máquinas

Cerrar una tarea debe producir un evento que un componente de acceso pueda consumir. Que una persona cambie el estado de un ticket sin una ruta de revocación conectada crea una falsa sensación de finalización.

Usa dos condiciones de terminación. La primera es una hora de finalización estricta, definida al crear el permiso. La segunda es una señal de cierre anticipado procedente del sistema de trabajo o de la persona responsable. El final efectivo es el primero de esos momentos. Un ticket reabierto no debe restaurar silenciosamente el permiso anterior. Requiere una nueva aprobación y una nueva fecha de finalización.

Esto protege contra un fallo conocido. Un agente recibe acceso para un incidente. El agente informa que ha solucionado el problema y el operador cierra el incidente. Un segundo proceso del agente todavía conserva una conexión autenticada y continúa recopilando diagnósticos. Más tarde, el equipo vuelve a abrir el incidente, pero nadie nota que el proceso antiguo nunca se detuvo. La decisión de acceso quedó vinculada al relato de un ticket, no al ciclo de vida del proceso real.

Vincula la autorización a un identificador de ejecución inmutable además del identificador de la tarea. Una tarea puede tener varias ejecuciones durante varios días. Cada ejecución necesita su propio inicio, final y responsable. Cuando termina la ejecución, revoca el permiso. Cuando se cierra la tarea, revoca todas las ejecuciones que sigan activas y estén asociadas a ella.

El evento de cierre necesita un receptor idempotente. Los sistemas reintentan los webhooks y los operadores pulsan dos veces los botones. Una solicitud de revocación debe aceptar entregas repetidas y conservar la primera marca de tiempo efectiva, en lugar de tratar un duplicado como un error que alguien acabará ignorando.

Registra el origen del cierre. Un cambio de estado procedente de un sistema de tickets, una detención manual del responsable del incidente, la salida de un proceso y una caducidad estricta tienen significados distintos durante una investigación. El resultado para el acceso es el mismo, pero el registro de auditoría debe conservar el motivo de la finalización.

No concedas una ampliación automática solo porque un agente emita más llamadas a herramientas cerca de la fecha límite. Ese patrón recompensa a un proceso ocupado con más autoridad. Exige que una persona tome una decisión nueva y que revise el propósito si el trabajo ha cambiado.

Un registro estructurado evita aprobaciones imprecisas

Un registro estructurado del permiso convierte la aprobación en algo que el sistema puede aplicar y un ingeniero puede revisar. También revela las decisiones que faltan antes de que el agente toque producción.

El siguiente ejemplo es deliberadamente sencillo. Es un formato de registro, no un lenguaje de políticas. Sus campos impiden que una ejecución del agente herede un permiso vago y reutilizable.

grant_id: grant_01JQ7P8V6R
agent_run_id: run_7f3a2c
purpose: "INC-482: inspect checkout worker failures"
owner: "on-call engineer"
created_at: "2025-04-18T16:00:00Z"
ends_at: "2025-04-18T16:30:00Z"
ends_on_task_close: "INC-482"
targets:
  - "https://ops.example.internal/checkout/status"
  - "ssh://checkout-worker-03.internal"
allowed_actions:
  - "GET /checkout/status"
  - "journalctl -u checkout-worker --since 20m"
closure_required: true
verification_action: "GET /checkout/status"

El registro no dice «acceso a producción: sí». Ese campo ocultaría las decisiones importantes. Indica quién es responsable de la decisión, qué ejecución recibe el permiso y qué solicitud usarás para demostrar que el permiso ha desaparecido.

Mantén el alcance lo bastante claro para que un aprobador pueda rechazarlo. Una lista enorme de rutas con comodines hace que la gente apruebe automáticamente porque no puede entenderla bajo presión. Si el agente necesita veinte objetivos sin relación, divide el trabajo en permisos separados o admite que el propósito es demasiado amplio.

No pongas un secreto en este registro. Un identificador de permiso y una descripción del objetivo son suficientes. El ejecutor puede resolver una credencial protegida después de comprobar el permiso. Este diseño también permite conservar datos de auditoría útiles sin conservar el material con el que se podría recrear el acceso a producción.

El registro debe sobrevivir a un reinicio y ser de solo adición desde la perspectiva de la persona que ejecuta el agente. Si el agente puede editar ends_at, modificar sus objetivos o borrar una señal de cierre, has delegado la decisión de seguridad al proceso que pretendías limitar.

Define explícitamente qué ocurre con las operaciones ya iniciadas. Una consulta de registros puede terminar después de la caducidad sin mucho riesgo. Un despliegue, una migración o un reinicio pueden necesitar una regla de cancelación, un límite transaccional o un procedimiento para que una persona tome el control. Lo peor es dejar ese comportamiento sin definir y descubrirlo durante la recuperación.

Demuestra la caducidad con una solicitud negativa

Demuestras que el acceso terminó enviando, a través de la misma ruta que usó el agente, una solicitud que ahora debería fallar. Un ticket cerrado, una credencial caducada en una consola de administración y una fila revocada en una base de datos son pruebas de apoyo. No son la demostración.

Programa la comprobación inmediatamente después del primero de estos momentos: el cierre de la tarea o la caducidad. Usa un endpoint inofensivo que siga requiriendo el permiso, como una solicitud de estado del servicio. No hagas la prueba con una comprobación de salud pública, porque un endpoint público tendrá éxito tanto si el acceso terminó como si no.

Una secuencia sencilla de prueba sería esta:

# This call succeeded while the grant was active.
agent-action --grant grant_01JQ7P8V6R \\
  GET https://ops.example.internal/checkout/status

# After task closure, repeat the exact protected operation.
agent-action --grant grant_01JQ7P8V6R \\
  GET https://ops.example.internal/checkout/status

El segundo comando debería producir una salida con este formato:

request_id=req_92a1
status=403
reason=grant_ended
ended_at=2025-04-18T16:12:09Z

Tu implementación puede devolver 401, 403 o un rechazo de conexión. Elige un significado y documéntalo. La entrada de auditoría debe indicar que la capa de acceso rechazó la solicitud porque el permiso terminó, no porque fallara DNS o el objetivo no estuviera disponible.

Prueba las rutas que la gente suele olvidar. Si un agente puede usar HTTPS y SSH, verifica ambas. Si el servicio emite una cookie después de un intercambio de API, comprueba que la cookie no sobreviva al permiso. Si un worker pone acciones en una cola local, verifica que el ejecutor compruebe la autorización al enviar la acción en cola, no solo al aceptar el trabajo.

Ejecuta una prueba programada de caducidad en un entorno que no sea de producción antes de confiar en el diseño en producción. Crea un permiso con una duración muy corta, realiza una solicitud permitida, espera a que caduque y repite la misma solicitud. Después revoca anticipadamente un segundo permiso activo y repite la solicitud. Esas dos comprobaciones detectan defectos distintos: problemas con el reloj y fallos en la revocación anticipada.

La disciplina del reloj merece atención. El componente que evalúa la fecha límite debe usar un reloj de sistema fiable y registrar la hora en que hizo la evaluación. Si un portátil puede atrasar su reloj y prolongar así el acceso, la fecha límite no se puede aplicar. Un intermediario central reduce este riesgo porque un único componente siempre activo toma la decisión, pero aun así debes vigilar su fuente horaria.

Los procesos del agente necesitan su propio límite

Una tarea puede continuar entre reintentos, terminales y turnos del modelo, pero un proceso del agente sigue siendo una unidad práctica para el control de acceso. Conceder autoridad por ejecución ofrece un lugar claro para solicitar aprobación, observar el comportamiento y revocar de inmediato.

No confundas una conversación con un proceso. Una persona puede decirle a un agente «sigue investigando» después de reiniciar el modelo o de que una herramienta lance un proceso hijo. Si el acceso sigue a la conversación sin un nuevo evento de autorización, el operador pierde la pista de qué ejecutable tiene el permiso.

Registra la identidad del proceso que inició la ejecución. En macOS, la autoridad de firma de código ofrece al aprobador información más útil que un nombre de proceso proporcionado por el usuario. Un proceso llamado agent no dice casi nada. Una identidad de firma registrada, la ruta del ejecutable, el proceso padre y la hora de lanzamiento permiten revisar lo ocurrido más tarde.

Sallyport usa de forma predeterminada una aprobación de sesión para cada proceso nuevo del agente, y su tarjeta de aprobación muestra primero la autoridad de firma de código del proceso. Ese es un límite de proceso razonable, pero la aprobación de sesión debe seguir formando parte de un permiso de tarea con una fecha de finalización.

Revoca o detén el acceso cuando el proceso termine normalmente, pero nunca dependas solo de esa salida. Los procesos fallan, los equipos entran en reposo y las relaciones entre procesos padre e hijo se complican. La fecha límite estricta y el evento de cierre de la tarea siguen siendo las protecciones de respaldo. Si el proceso sobrevive al cierre de una tarea, la ruta de solicitud debe rechazarlo incluso antes de que el sistema operativo lo elimine.

Separa el acceso de terminal de una persona del acceso del agente. Es tentador permitir que el agente herede el shell autenticado del operador porque facilita la configuración. También destruye la atribución y puede dar al agente todos los privilegios que el operador acumuló ese día. Dale al agente una identidad distinta y haz que solicite acceso a través de su propia ruta.

Las solicitudes de aprobación no eliminan la necesidad de limitar el alcance

Una persona que pulsa «aprobar» puede detectar una solicitud evidentemente incorrecta, pero las aprobaciones pierden fuerza cuando llegan demasiado a menudo o describen demasiado poco. Un aviso que solo dice «permitir llamada a la API» obliga al humano a adivinar sus consecuencias.

Muestra al aprobador el propósito, el objetivo, el método o comando, la fecha de finalización del permiso y la identidad del agente. Si el sistema no puede explicar la solicitud en esos términos, no ha reunido suficiente información para pedir aprobación de forma responsable.

La aprobación por llamada tiene sentido para operaciones con efectos irreversibles: borrar datos, rotar una credencial, activar un proceso de pagos o desplegar un cambio sin revisar. No debería convertirse en el control habitual para cada lectura de registros. Las personas aprueban solicitudes repetitivas por reflejo, sobre todo durante un incidente.

Para una llamada marcada con la opción de aprobación por llamada, Sallyport solicita aprobación en cada uso, pero esa configuración debe complementar una fecha de finalización, no sustituirla. Una persona puede aprobar una solicitud válida a las 16:29, mientras la ruta de acceso debe rechazar cualquier solicitud posterior al final del permiso.

Conserva una parada de emergencia rápida que no exija localizar al aprobador original. El ingeniero de guardia necesita una forma de terminar una ejecución cuando el agente entra en un bucle, interpreta mal una salida o empieza a tocar el objetivo equivocado. Registra quién usó la parada y por qué. Un control de emergencia sin responsabilidad puede convertirse en otra ruta de acceso sin revisión.

El registro de auditoría debe responder a las preguntas incómodas

Después de un incidente de producción, la gente pregunta cuándo comenzó el acceso, quién lo permitió, qué proceso lo usó, qué solicitudes tuvieron éxito y si realmente se detuvo. Los registros que solo guardan los éxitos no pueden responder a la última pregunta.

Registra también las llamadas rechazadas, especialmente los rechazos posteriores a una caducidad o revocación. Un rechazo demuestra que el punto de aplicación recibió una solicitud y aplicó el límite. Puede revelar que un agente atascado sigue intentando actuar después del cierre de la tarea, algo que merece atención aunque el control haya funcionado.

Conecta la decisión del permiso y las acciones individuales mediante identificadores. Un revisor debería poder pasar de grant_01JQ7P8V6R a su responsable aprobador, la tarea asociada, la identidad de la ejecución, el alcance permitido, el origen del cierre y cada solicitud. Si esos registros viven en sistemas independientes sin un identificador compartido, reconstruir lo ocurrido se convierte en una cuestión de conjeturas.

La evidencia de manipulación importa porque los registros de acceso suelen cobrar importancia cuando alguien tiene motivos para editarlos. Sallyport genera sus diarios de sesiones y actividad a partir de un registro de auditoría cifrado y encadenado mediante hashes, y sp audit verify puede verificar esa cadena sin conexión sobre el texto cifrado. Esta propiedad no decide si una solicitud era apropiada, pero hace más difícil ocultar una alteración silenciosa de la secuencia registrada.

No recopiles cada prompt ni cada pensamiento del modelo como sustituto de los registros de acciones. Esos datos crean problemas de privacidad y conservación, y aun así quizá no identifiquen la solicitud de red real. Empieza por la decisión de autorización y el resultado de la acción. Añade el contexto del prompt solo cuando tus reglas operativas y de privacidad lo justifiquen.

Ofrece a los revisores un registro de cierre fijo. Debe indicar el identificador del permiso, la marca de tiempo del final efectivo, el origen de la terminación, el número de acciones correctas, el número de acciones rechazadas después del final y el resultado de la solicitud de verificación. Ese registro convierte la afirmación imprecisa de «acceso eliminado» en algo que un revisor de cambios puede cuestionar.

Construye el control en una secuencia pequeña y comprobable

No necesitas un motor de políticas general para aplicar el acceso temporal. Necesitas un mecanismo limitado que todas las acciones del agente deban usar y una ruta de rechazo que puedas probar.

Empieza por enumerar las acciones que los agentes realizan actualmente en producción. Separa las operaciones de lectura, las escrituras reversibles y las acciones que pueden causar efectos irreversibles o amplios. Para cada acción, identifica quién posee realmente la credencial y cuál es el punto de aplicación. Este ejercicio suele revelar credenciales almacenadas en variables de entorno, perfiles de shell, registros de CI o archivos de configuración copiados.

Después construye el ciclo de vida mínimo:

1. Crea una identidad de ejecución distinta y un permiso estructurado con un propósito y una fecha de finalización estricta.
2. Dirige cada acción HTTP o SSH protegida a través de un ejecutor que compruebe el permiso antes de usarlo.
3. Acepta una señal de cierre anticipado o de revocación y registra su marca de tiempo efectiva.
4. Envía una solicitud protegida e inofensiva después de la terminación y conserva el resultado del rechazo.
5. Revisa periódicamente los permisos caducados y revocados para detectar intentos posteriores al fin del acceso.

No empieces con reglas elaboradas que clasifiquen todos los comandos posibles. Los equipos pasan semanas debatiendo la sintaxis mientras sus agentes siguen teniendo credenciales de larga duración. Empieza con objetivos identificados, duraciones cortas, identidad por ejecución y una prueba de rechazo. Añade restricciones más precisas cuando el historial de acciones demuestre que se solicitan alcances amplios.

El criterio de calidad es sencillo y exigente: cuando la tarea se cierra, un proceso antiguo del agente debe fallar en el límite de producción y debes poder mostrar por qué falló. Hasta que puedas ejecutar esa comprobación, el acceso solo es temporal sobre el papel.