Cómo custodiar la e.firma cuando un agente consulta portales oficiales

En 60 segundos: La e.firma, la llave privada y las claves fiscales permiten actuar bajo la identidad del titular. Guardalas en una bóveda, separadas de documentos, chats y carpetas compartidas. Entregá al proceso el acceso mínimo y temporal, con MFA cuando el portal lo permita, registro de cada uso y revisión humana. Definí “solo lectura” acción por acción: en algunos portales, abrir un documento pendiente genera una constancia de notificación. Si el portal falla o cambia, el agente conserva el último estado confirmado, registra la incidencia y pide revisión. Nunca completa el vacío con una respuesta probable.

Un despacho de litigio quiere revisar movimientos cada mañana. Una empresa necesita descargar acuses y comprobar obligaciones mensuales. Ambos casos parecen una automatización de navegador hasta que aparece la pregunta importante: ¿dónde viven el certificado, la llave privada y la contraseña?

Si están en una carpeta compartida, la integración empieza con un problema de custodia. El agente puede automatizar una consulta, pero las mismas credenciales también pueden autorizar trámites, firmas o accesos que el flujo nunca necesitó.

Estas notas describen controles operativos, no asesoría legal, fiscal ni de ciberseguridad para un caso concreto. Cada organización debe confirmar el efecto de cada acción con el responsable profesional y la normativa de su jurisdicción.

La credencial permite actuar como el titular

En México, la Ley de Firma Electrónica Avanzada establece, para los actos dentro de su ámbito, que los documentos electrónicos con firma electrónica avanzada producen los mismos efectos que los presentados con firma autógrafa y tienen el valor probatorio que les otorguen las disposiciones aplicables. La propia ley excluye las materias fiscal, aduanera y financiera, que se rigen por sus disposiciones específicas. El SAT describe la e.firma como el conjunto de datos que identifica al firmante, creado bajo su exclusivo control y vinculado a él y al documento.

Los términos de la solicitud de e.firma del SAT son todavía más directos: atribuyen al titular los movimientos y documentos firmados con su llave privada y le exigen conservar la confidencialidad del archivo .key y de su contraseña. Por eso, una copia accesible desde Drive, correo o chat no es un detalle de TI. Amplía quién o qué proceso podría actuar con esa identidad.

Conviene inventariar los componentes por separado:

• certificado público, por ejemplo el archivo .cer;
• llave privada, como el archivo .key;
• contraseña de la llave privada;
• contraseña o clave fiscal usada para entrar al portal;
• factores de autenticación, sesiones y mecanismos de recuperación.

El hecho de que un portal pida varios componentes no obliga a guardarlos juntos. La arquitectura debe impedir que una persona, proceso o fuga obtenga el paquete completo sin controles adicionales.

La bóveda es parte del flujo

Guardá la llave privada y las contraseñas en una bóveda o gestor de secretos administrado. El sistema elegido debe cifrar el material, autorizar por identidad, registrar accesos, permitir revocación y limitar la entrega al proceso que lo necesita. No hace falta nombrar un proveedor para fijar esos requisitos.

La guía de gestión de llaves de NIST exige protección de confidencialidad para las llaves privadas fuera de un módulo criptográfico y recomienda controles de acceso, registro y revisión. Una carpeta con permisos generales sirve para colaborar con documentos. No ofrece por sí sola el control de uso que requiere una credencial de firma.

El agente tampoco necesita ver el secreto. Siempre que la tecnología lo permita, un intermediario controlado puede realizar la autenticación o firma autorizada y devolver solo el resultado. Así, el modelo recibe una capacidad concreta durante una tarea, no el archivo y su contraseña dentro del prompt, el navegador o el log.

MFA y privilegio mínimo por portal

Activá MFA donde esté disponible, especialmente en las cuentas con información sensible o permisos administrativos. CISA recomienda exigir MFA para acceso remoto y privilegiado y preferir métodos resistentes al phishing cuando el servicio los ofrece.

MFA no corrige un permiso excesivo. La cuenta del agente debe poder consultar solo las entidades, expedientes y módulos incluidos en el encargo. Si un portal no separa lectura, firma y presentación, la organización debe reducir el alcance de otra forma: una cuenta distinta, una sesión supervisada, una estación controlada o un paso manual.

Documentá cuatro límites antes de conectar el agente:

1. qué identidad usa;
2. qué portales, contribuyentes o expedientes puede consultar;
3. qué acciones están permitidas;
4. cuándo vence o se revoca el acceso.

Una credencial compartida borra la atribución. Si el portal obliga a usarla, el registro interno debe identificar qué persona aprobó la ejecución y qué proceso la utilizó.

Las copias temporales necesitan dueño y final

Algunos portales heredados solo aceptan cargar archivos desde el equipo que ejecuta el navegador. En ese caso puede ser necesaria una copia temporal. Tratala como una excepción documentada:

1. aprobá la tarea y el periodo de uso;
2. copiá únicamente los componentes necesarios a un entorno aislado y descartable;
3. evitá que aparezcan en prompts, capturas, portapapeles, historial del shell o logs;
4. ejecutá la consulta autorizada;
5. registrá el resultado y la evidencia permitida;
6. eliminá la copia y destruí el entorno al terminar;
7. comprobá que no quedó en sincronización, descargas, caché ni copias de respaldo no previstas.

NIST incluye distribución, almacenamiento, uso y destrucción dentro de los eventos que deben quedar registrados en la gestión de llaves. “Temporal” describe el ciclo de vida, no un directorio llamado tmp.

Si el entorno no permite verificar la eliminación o conserva perfiles de navegador, no lo uses para material de firma. La alternativa es mantener ese paso en una estación administrada y bajo control humano.

Solo lectura debe describir acciones concretas

Entrar al portal y leer una pantalla no siempre es una operación neutra. El Consejo de la Judicatura Federal explica que, en su Portal de Servicios en Línea, abrir una resolución genera automáticamente una constancia con fecha y hora de notificación. En el Buzón Tributario del SAT, el flujo para notificarse incluye seleccionar el acto pendiente, ingresar la e.firma y generar el acuse.

El permiso “consultar” debe convertirse en una matriz por portal:

Acción	Agente	Persona responsable
Comprobar disponibilidad del portal	Permitida	Revisa excepciones
Consultar datos públicos o expedientes autorizados	Permitida, con registro	Supervisa muestras
Ver que existe un elemento pendiente sin abrirlo	Permitida si el portal lo separa	Decide el siguiente paso
Abrir una resolución o acto pendiente	Bloqueada	Confirma efecto y autoriza
Generar acuse, aceptar, firmar o presentar	Bloqueada	Ejecuta o aprueba el flujo específico

Esta separación no elimina los plazos que la ley o el portal puedan activar automáticamente. Evita que una automatización añada un acto no autorizado y obliga al equipo a mantener su propio control de avisos y vencimientos.

Cuando el portal falla, el estado queda sin confirmar

Un timeout, un CAPTCHA nuevo, un cambio de selector o una página vacía no significan “sin movimientos”. El agente debe devolver un estado explícito: consulta fallida, resultado ambiguo o requiere revisión.

El registro mínimo incluye portal, identidad técnica, expediente o contribuyente consultado, hora con zona horaria, acción intentada, respuesta observada y último estado confirmado. Nunca guarda contraseñas, llaves ni tokens. Conservá la evidencia operativa permitida y escalá según la urgencia del asunto.

El PJF dispone de un canal para reportar fallas técnicas y su guía indica cómo registrar una incidencia. Ese mecanismo sirve de ejemplo: el flujo debe usar el canal oficial del portal y dejar que la autoridad confirme la falla. Una captura interna ayuda a investigar, pero no sustituye los requisitos formales aplicables.

Si cambia la interfaz, detené la automatización hasta validar de nuevo las acciones permitidas. Un selector que antes descargaba un documento puede apuntar mañana a “aceptar” o “enviar”.

Revisión humana y bitácora de acceso

Cada ejecución debe responder quién la solicitó, quién la aprobó, qué identidad y portal usó, cuándo ocurrió, qué acción realizó, qué archivo descargó y cuál fue el resultado. También registra accesos fallidos y la eliminación de material temporal.

La bitácora debe estar separada del entorno que usa la credencial y protegida contra cambios. CISA recomienda registrar actividad de usuarios, inicios de sesión y acciones administrativas, centralizar los logs y alertar sobre eventos de riesgo.

La revisión humana no se limita a aprobar una frase. La persona debe ver el portal, la identidad, la acción exacta y el efecto esperado. Para descargas, valida asunto, origen y archivo. Para una notificación o trámite, conserva la decisión y la ejecución fuera del alcance autónomo salvo que exista un procedimiento específico aprobado.

El artículo sobre el second brain de litigio cubre el paso siguiente: relacionar documentos descargados, estados observados, responsables y próximas actuaciones sin delegar el criterio jurídico.

Checklist antes de conectar el agente

• Inventariamos certificado, llave privada, contraseñas, MFA, sesiones y recuperación.
• La llave privada y las claves viven en una bóveda, fuera de Drive, chat y documentos.
• El agente recibe una capacidad temporal y acotada; no recibe secretos en el prompt.
• Definimos acciones permitidas y bloqueadas para cada portal.
• Confirmamos cuáles acciones generan acuse, notificación, firma o presentación.
• Activamos MFA y limitamos identidades, expedientes, módulos y horarios cuando es posible.
• Documentamos creación y eliminación de cualquier copia temporal.
• Registramos accesos, descargas, fallos, aprobaciones y resultado.
• Existe una cola humana para cambios de interfaz, ambigüedad y caída del portal.
• Probamos revocación, rotación y respuesta ante exposición antes del piloto.

Fuentes oficiales verificadas el 11 de octubre de 2026. Las reglas y funciones pueden cambiar por jurisdicción y portal; comprobá la versión aplicable el día de cada implementación.

Kiia puede ayudar a diseñar el mapa de permisos, la custodia y el piloto de consulta antes de conectar una credencial real. El primer hito es simple de comprobar: el agente obtiene solo la capacidad necesaria y cada acceso deja una evidencia revisable.