Paquete de aprobación de TI del agente

Flujo solo de salida

El agente es un servicio de Windows instalado en el servidor de la empresa, y es él quien abre toda conexión. Nada en la nube se conecta al servidor, y no hay puerto de entrada que abrir en el firewall.

Las consultas están compiladas en el binario. La nube elige solo el dominio de datos y la ventana a leer; nunca envía SQL, script ni comando al servidor.

El agente lee un conjunto fijo de tablas y columnas, declarado en el manifiesto del ERP. No guarda copia de datos de negocio en disco, y sus logs no registran valores de negocio.

Red: nombres y puertos

El agente no necesita ninguna regla de entrada. Toda conexión suya con AutoController sale del servidor por TCP 443, cifrada con TLS, y los datos viajan bajo TLS mutuo: el agente verifica el gateway y el gateway verifica el agente.

La conexión con SQL Server depende de dónde corre el agente. En el propio servidor de la base (el valor por defecto), es local. En otro servidor (vea la sección sobre gMSA), abra entre los dos servidores el puerto TCP de la instancia y, cuando la instancia es nombrada y está configurada sin puerto, también el puerto UDP 1434 de SQL Server Browser. Ese tráfico queda dentro de la red de la empresa y nunca va a la nube.

Permita la salida por nombre, nunca por dirección IP, hacia estos dos destinos, ambos en TCP 443:

• cadastro.ingestao.autocontroller.ai — registro del agente (TLS 1.3, sin certificado de cliente).
• agente.ingestao.autocontroller.ai — envío de los datos, heartbeat y renovación del certificado, bajo TLS mutuo.

Proxy e inspección TLS

Excluya los dos nombres de la inspección TLS. El agente confía solo en el ancla de confianza compilada en él, nunca en el almacén de certificados de Windows: un proxy o firewall que intercepta el TLS presenta su propio certificado, y el agente lo rechaza. El diagnóstico, con el comando de abajo, reporta este caso como inspecao_tls.

Si la salida pasa por un proxy, este se configura explícitamente en el agente, con el formato http://host:puerto, sin usuario ni contraseña. El agente nunca lee el proxy de la configuración del sistema: ni de variables de entorno, ni de WinINet, WinHTTP, PAC o WPAD.

Solo se admite proxy HTTP (HTTPS y SOCKS no), y debe permitir un CONNECT sin autenticación desde este servidor hacia los dos nombres, en el puerto 443. Si el proxy de la empresa exige autenticación (respuesta 407, NTLM o Kerberos), cree una regla que exima a este servidor de la autenticación para esos dos destinos.

agente diagnostico

ejecuta las verificaciones de la instalación, entre ellas la de la salida hacia AutoController.

Permisos en la base: el script de GRANT del manifiesto

El login del agente recibe SELECT solo en las tablas y columnas que leen las consultas del catálogo — nunca db_datareader, nunca escritura.

Esas tablas y columnas están publicadas en el manifiesto de cada ERP, que su DBA aplica y audita. El kit de instalación que entrega AutoController trae el script de GRANT generado para su versión y para la cuenta del servicio; esta página no lo reproduce.

En el servidor, los comandos de abajo muestran de dónde viene ese script, y el diagnóstico verifica que el login tiene SELECT en cada columna del manifiesto y que no tiene ningún rol amplio en la base (como db_datareader o db_owner) ni permiso de lectura, escritura o alteración sobre la base entera. No inventaría concesiones en otras tablas o columnas: auditar una concesión de más sigue a cargo de su DBA.

agente manifesto

lista cada consulta, tabla y columna que lee el agente.

agente manifesto --sql <login>

imprime, para el login indicado, el mismo script de GRANT que trae el kit.

agente diagnostico

verifica, entre otras cosas, que el login tiene SELECT en cada columna del manifiesto y ningún rol amplio en la base ni permiso de lectura, escritura o alteración sobre la base entera; las concesiones en otras tablas o columnas quedan a cargo de la auditoría de su DBA.

Cuenta del servicio y gMSA

Cuando el agente corre en el propio servidor de la base (el valor por defecto), el servicio usa la cuenta virtual NT SERVICE\AutoControllerAgente, creada y administrada por Windows, y no se necesita ninguna gMSA. El kit de instalación que entrega AutoController trae, generados para su versión y para esa cuenta, los permisos de la carpeta de instalación, la instalación del servicio y el script de GRANT; esta página no los reproduce.

Cuando corre en otro servidor, el servicio usa una cuenta de servicio administrada de grupo (gMSA). Esta guía cubre solo el lado de Active Directory, y en ningún paso se crea o se manipula una contraseña:

• el administrador del dominio crea la gMSA con PrincipalsAllowedToRetrieveManagedPassword apuntando al servidor del agente, o a un grupo que lo contenga;
• en el servidor del agente, TI instala la cuenta y confirma que la prueba devuelve True, con los cmdlets de abajo;
• el equipo de AutoController elige la opción de cuenta gMSA al generar el kit, que entonces trae la instalación del servicio y el login SQL FROM WINDOWS para esa cuenta.

Install-ADServiceAccount

instala la gMSA en el servidor del agente.

Test-ADServiceAccount

debe devolver True antes de continuar.

Integridad: hash, firma y Raiz G1

v0 (hoy): el binario no tiene firma de código. El equipo de AutoController entrega a TI el archivo junto con su versión y su SHA-256. Antes de ejecutarlo, TI calcula el SHA-256 del archivo con el primer cmdlet de abajo y lo compara con el SHA-256 entregado por el equipo de AutoController. Cuando el kit de instalación esté disponible, será el kit el que imprima ese SHA-256 para su versión. La comparación no distingue mayúsculas de minúsculas: el cmdlet imprime el hash en mayúsculas, y el valor de referencia puede venir en minúsculas. Si los valores no coinciden, no ejecute nada y avise a AutoController.

A partir de la primera versión distribuida por el canal, el .exe llevará firma Authenticode de una autoridad certificadora propia de AutoController, en tres niveles: la raíz Raiz G1 firma la CA emisora Emissora G1, y la Emissora G1 emite el certificado del firmante. Las claves de ambas estarán en AWS KMS, en una cuenta de AWS dedicada a ellas, y solo firmarán con el factor MFA del operador de AutoController; la clave del firmante será RSA no exportable en AWS KMS, siempre con el mismo nombre de firmante entre renovaciones, para que una regla de editor de App Control de Windows sobreviva a la reemisión anual del certificado. El supervisor del agente verificará los metadatos del canal, el hash y la firma antes de cada actualización.

Para que esa firma sea aceptada, TI instalará una sola vez la Raiz G1, y solo ella, en el almacén de raíces de confianza de la máquina, LocalMachine\Root, y solo en el servidor del agente: nunca en otro servidor, nunca por GPO de dominio, y nada en LocalMachine\CA ni en TrustedPublisher — la Emissora G1 viaja dentro de la firma. El orden será: primero la Raiz G1 en LocalMachine\Root, con el segundo comando de abajo; después el tercer comando de abajo comprueba la instalación, antes de instalar el servicio; solo entonces el cuarto comando de abajo reportará Valid. Una instalación en el almacén del usuario (CurrentUser\Root) no cuenta: el administrador vería Valid en su propia sesión, pero el servicio se ejecuta como NT SERVICE\AutoControllerAgente, que no ve ese almacén, y el agente no arrancaría. La huella digital de la Raiz G1, para que TI compruebe el archivo que reciba, se publicará con la primera versión distribuida por el canal.

• Lo que esta confianza permitirá: en este servidor, Windows aceptará todo certificado de firma de código que emita la Emissora G1, no solo el del agente. Las reglas de editor de AppLocker coinciden por el nombre del firmante, así que un certificado de la Emissora G1 con el nombre de otro editor pasaría las reglas de ese editor en este servidor; es la custodia de la clave de la Emissora G1, descrita arriba, lo que limita ese alcance.
• Lo que no permitirá: la Raiz G1 y la Emissora G1 llevan dentro la restricción a la firma de código (EKU codeSigning), que CryptoAPI de Windows aplica a toda la cadena por debajo de ellas; un certificado emitido bajo la Raiz G1 será rechazado para TLS, para autenticación de cliente y para cualquier otro propósito. La excepción es un software con manejo propio de la confianza que lea el almacén de Windows, como Java configurado con Windows-ROOT, que ignora esa restricción — por eso la Raiz G1 va solo en el servidor del agente.
• Cómo retirarla: borrar la Raiz G1 de LocalMachine\Root deshará la instalación, y el agente dejará de arrancar. Para rechazar la confianza aunque la raíz siga en el almacén o vuelva a él, TI colocará el certificado en LocalMachine\Disallowed con el último comando de abajo. Eso valdrá para la Raiz G1, para la Emissora G1 o para el certificado del firmante, funcionará sin red y será la respuesta a un compromiso: ninguno de los tres niveles tiene lista de revocación ni OCSP, y el reemplazo llegará en una nueva emisión de certificados de AutoController.

Get-FileHash -Algorithm SHA256

calcula el SHA-256 del archivo (v0, hoy).

Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root

instalará la Raiz G1 en el almacén de la máquina, en la consola elevada del servidor del agente, con -FilePath apuntando al archivo de la Raiz G1 (a partir de la primera versión distribuida por el canal).

agente instalar requisitos

comprobará, antes de instalar el servicio, que la Raiz G1 está en LocalMachine\Root, que ningún certificado de la cadena está en Disallowed y que la raíz vale para firma de código; si falta algo, rechazará indicando el motivo y la corrección (a partir de la primera versión distribuida por el canal).

Get-AuthenticodeSignature

reportará Valid una vez que la Raiz G1 esté en LocalMachine\Root; antes de eso, reportará UnknownError, porque la cadena termina en una raíz en la que Windows aún no confía (a partir de la primera versión distribuida por el canal).

Import-Certificate -CertStoreLocation Cert:\LocalMachine\Disallowed

colocará un certificado de la cadena en Disallowed, en la consola elevada, con -FilePath apuntando a él: Windows pasará a rechazarlo de inmediato, sin red, aun con la Raiz G1 todavía en LocalMachine\Root (a partir de la primera versión distribuida por el canal).

Política de actualización

v0 (hoy): la v0 no se actualiza sola; se actualiza a mano. El reemplazo de la v0 por la primera versión distribuida por el canal es la única reinstalación admitida.

A partir de la primera versión distribuida por el canal, las actualizaciones seguirán estas reglas:

• Anillos: cada versión nueva pasará primero por un tenant interno de prueba, luego por los conectores en homologación (la ola 0), por un cliente canario, por los clientes que opten por recibirla antes y, por último, por todos. La promoción de un anillo al siguiente exigirá un período sin señal mala.
• Ventana de mantenimiento: cada cliente declarará el día, la hora y el huso horario de su ventana, y una actualización interrumpida se retomará en la ventana siguiente. Una corrección de seguridad podrá saltarse la ventana.
• Clases de cambio: la clase de cada release se deducirá de la propia release, nunca se declarará a mano. Manifiestos idénticos serán un cambio estándar, preautorizado y distribuido automáticamente en la ventana, después de la ola 0; un cambio de manifiesto será un cambio normal, que pasa por el CAB y el DBA y nunca se distribuye automáticamente; una corrección de seguridad será un cambio de emergencia.
• Reversión automática: el supervisor del agente cambiará la versión después del lote en curso y solo la confirmará si, dentro del período de gracia, el proceso sigue vivo, el heartbeat es aceptado y las verificaciones del diagnóstico pasan; si no, volverá solo a la versión anterior.

Política de soporte

Las reglas de abajo rigen a partir de la primera versión distribuida por el canal: las ventanas de soporte cuentan desde esa versión, y la v0 piloto es reemplazada una única vez por ella.

Las releases minor son aproximadamente mensuales. Tienen soporte las dos minors anteriores o seis meses, lo que sea menor; la ruta de actualización está garantizada a partir de la major anterior.

La deprecación y el sunset tienen fecha publicada; el pin de un tenant vale como máximo hasta el fin de la ventana de soporte de la versión fijada. El pin es la versión que un cliente pide mantener fija en su entorno.

Sistemas operativos soportados: Windows Server 2016 a 2025 (2016, 2019, 2022 y 2025).

Residencia de los datos

El gateway que recibe las conexiones del agente corre en AWS, en la región sa-east-1 (São Paulo), y la base central de AutoController está en la misma región, igual que sus respaldos. Lo que envía el agente se almacena en Brasil.

Retiro

Qué queda en el servidor: la remoción del servicio mantiene las claves del agente en el perfil del servicio y el derecho de inicio de sesión como servicio concedido en la instalación, y borrar las carpetas no elimina ninguno de los dos. Lo que pone fin a la identidad del agente es la revocación en la consola: con el certificado revocado, la clave que quedó en el servidor no sirve para nada.

Si TI aplicó la etapa opcional certificado-sql, queda también lo que ella grabó, y solo eso: un certificado autofirmado en LocalMachine\My; el contenedor de su clave en el Microsoft RSA SChannel Cryptographic Provider, con una única entrada de lectura para el SID de servicio de la instancia; y el valor SuperSocketNetLib\Certificate de la instancia, que apunta a ese certificado. Es la única escritura del agente en la configuración de SQL Server, hecha por TI en la consola elevada, nunca por el servicio del agente ni a pedido de la nube. Ese certificado es de la instancia, no del agente: ni la remoción del servicio ni la revocación en la consola lo tocan, y la etapa no lo renueva.

Para retirar el agente:

• en el servidor, TI detiene y da de baja el servicio con el primer comando de abajo;
• si TI aplicó la etapa certificado-sql, usa el segundo comando de abajo para revertir la etapa antes de borrar %ProgramFiles%\AutoController, porque es el agente.exe de esa carpeta el que la deshace. Mientras SQL Server usa el certificado de la etapa, la reversión no termina en una sola ejecución: indica ejecutarla de nuevo después del próximo reinicio de la instancia, en la ventana del DBA, o con la instancia detenida; la carpeta queda hasta que una ejecución termine ok y sin ninguna línea sobras;
• opcionalmente, si no lo va a reinstalar, borre las carpetas %ProgramData%\AutoController y %ProgramFiles%\AutoController;
• en SQL Server, el DBA elimina el usuario de la base y el login (DROP USER y DROP LOGIN), lo que elimina también los permisos concedidos;
• pida a AutoController que revoque el agente en la consola.

agente servico remover

detiene el servicio, lo da de baja y elimina su origen del registro de eventos de Windows.

agente instalar certificado-sql --reverter

revierte la etapa certificado-sql, en la consola elevada, deshaciendo solo lo que ella creó: limpia el valor Certificate cuando apunta al certificado de la etapa, retira la lectura de la clave y borra el certificado y el contenedor de la clave — estos dos solo cuando la instancia ya no usa el certificado de la etapa, o está detenida. Nunca detiene, inicia ni reinicia SQL Server. En un servidor con más de una instancia, se niega sin cambiar nada y lista las instancias: ejecútelo indicando cada instancia en la que se aplicó la etapa; en una instancia en la que no se aplicó, termina sin cambiar nada.

Divulgación de vulnerabilidades

Reporte vulnerabilidades de forma privada a security@autocontroller.ai, nunca en un issue público, con la descripción, el impacto, los pasos para reproducirla y la versión afectada.

Primera respuesta en hasta 48 horas hábiles. Plan de corrección en hasta 5 días hábiles después de la confirmación.

Tras la corrección, la divulgación es coordinada, mediante un aviso de seguridad y una comunicación directa a los clientes afectados cuando haya impacto. Los investigadores que reporten de buena fe reciben crédito, si lo desean.