The agent's IT approval package

Outbound-only flow

The agent is a Windows service installed on your company's server, and it opens every connection. Nothing in the cloud connects to the server, and there is no inbound port to open on the firewall.

The queries are compiled into the binary. The cloud chooses only the data domain and the window to read; it never sends SQL, a script or a command to the server.

The agent reads a fixed set of tables and columns, declared in the ERP's manifest. It keeps no copy of business data on disk, and its logs record no business values.

Network: names and ports

The agent needs no inbound rule. Every connection it makes to AutoController leaves the server on TCP 443, encrypted with TLS, and the data travels over mutual TLS: the agent verifies the gateway and the gateway verifies the agent.

The SQL Server connection depends on where the agent runs. On the database server itself (the default), it is local. On another server (see the gMSA section), open the instance's TCP port between the two servers and, when the instance is named and configured without a port, also UDP port 1434 to SQL Server Browser. That traffic stays inside your company's network and never goes to the cloud.

Allow outbound traffic by name, never by IP address, to these two destinations, both on TCP 443:

• cadastro.ingestao.autocontroller.ai — agent enrolment (TLS 1.3, no client certificate).
• agente.ingestao.autocontroller.ai — data upload, heartbeat and certificate renewal, over mutual TLS.

Proxy and TLS inspection

Exempt both names from TLS inspection. The agent trusts only the trust anchor compiled into it, never the Windows certificate store: a proxy or firewall that intercepts TLS presents its own certificate, and the agent refuses it. The diagnostics, run with the command below, report this case as inspecao_tls.

If outbound traffic goes through a proxy, it is configured explicitly in the agent, in the form http://host:port, with no user name or password. The agent never reads the proxy from the system settings: not from environment variables, nor from WinINet, WinHTTP, PAC or WPAD.

Only an HTTP proxy is supported (HTTPS and SOCKS are not), and it must allow an unauthenticated CONNECT from this server to the two names, on port 443. If your company's proxy requires authentication (a 407 response, NTLM or Kerberos), create a rule that exempts this server from authentication for those two destinations.

agente diagnostico

runs the installation checks, among them the one for the outbound connection to AutoController.

Database permissions: the GRANT script from the manifest

The agent's login gets SELECT only on the tables and columns the catalogue's queries read — never db_datareader, never write access.

Those tables and columns are published in each ERP's manifest, which your DBA applies and audits. The installation kit AutoController delivers carries the GRANT script generated for your version and for the service account; this page does not reproduce it.

On the server, the commands below show where that script comes from, and the diagnostics check that the login has SELECT on every column of the manifest and holds no broad database role (such as db_datareader or db_owner) nor any database-wide read, write or alter permission. They do not inventory grants on other tables or columns: auditing any extra grant stays with your DBA.

agente manifesto

lists every query, table and column the agent reads.

agente manifesto --sql <login>

prints, for the given login, the same GRANT script the kit carries.

agente diagnostico

checks, among other things, that the login has SELECT on every column of the manifest and holds no broad database role nor any database-wide read, write or alter permission; grants on other tables or columns stay with your DBA's audit.

Service account and gMSA

When the agent runs on the database server itself (the default), the service uses the virtual account NT SERVICE\AutoControllerAgente, created and managed by Windows, and no gMSA is needed. The installation kit AutoController delivers carries, generated for your version and for that account, the permissions of the installation folder, the service installation and the GRANT script; this page does not reproduce them.

When it runs on another server, the service uses a group managed service account (gMSA). This guide covers only the Active Directory side, and no password is created or handled at any step:

• the domain administrator creates the gMSA with PrincipalsAllowedToRetrieveManagedPassword naming the agent's server, or a group that contains it;
• on the agent's server, IT installs the account and confirms the test returns True, with the cmdlets below;
• the AutoController team picks the gMSA account option when generating the kit, which then carries the service installation and the SQL login FROM WINDOWS for that account.

Install-ADServiceAccount

installs the gMSA on the agent's server.

Test-ADServiceAccount

must return True before you go on.

Integrity: hash, signature and Raiz G1

v0 (today): the binary carries no code signature. The AutoController team hands IT the file together with its version and its SHA-256. Before running it, IT computes the file's SHA-256 with the first cmdlet below and compares it with the SHA-256 handed over by the AutoController team. Once the installation kit is available, it will be the kit that prints that SHA-256 for your version. The comparison is case-insensitive: the cmdlet prints the hash in uppercase, and the reference value may come in lowercase. If the values differ, run nothing and notify AutoController.

From the first version distributed through the channel, the .exe will carry an Authenticode signature from AutoController's own certificate authority, in three tiers: the Raiz G1 root signs the Emissora G1 issuing CA, and the Emissora G1 issues the signer's certificate. Both CA keys will live in AWS KMS, in an AWS account dedicated to them, and will sign only with the MFA factor of AutoController's operator; the signer's key will be a non-exportable RSA key in AWS KMS, always under the same signer name across renewals, so that a Windows App Control publisher rule survives the certificate's yearly reissue. The agent's supervisor will verify the channel metadata, the hash and the signature before every update.

For that signature to be accepted, IT will install the Raiz G1 once, and only it, in the machine's trusted root store, LocalMachine\Root, and only on the agent's server: never on another server, never through a domain GPO, and nothing in LocalMachine\CA or TrustedPublisher — the Emissora G1 travels inside the signature. The order will be: first the Raiz G1 into LocalMachine\Root, with the second command below; then the third command below checks the installation, before the service is installed; only then will the fourth command below report Valid. An install in the user's store (CurrentUser\Root) does not count: the administrator would see Valid in their own session, but the service runs as NT SERVICE\AutoControllerAgente, which does not see that store, and the agent would not start. The Raiz G1 fingerprint, for IT to check the file it receives, will be published with the first version distributed through the channel.

• What this trust will allow: on this server, Windows will accept every code-signing certificate the Emissora G1 issues, not only the agent's. AppLocker publisher rules match on the signer's name, so an Emissora G1 certificate bearing another publisher's name would pass that publisher's rules on this server; the custody of the Emissora G1 key, described above, is what bounds that reach.
• What it will not allow: the Raiz G1 and the Emissora G1 carry inside them the restriction to code signing (the codeSigning EKU), which Windows CryptoAPI applies down the whole chain below them; a certificate issued under the Raiz G1 will be refused for TLS, for client authentication and for any other purpose. The exception is software with its own trust handling that reads the Windows store, such as Java configured with Windows-ROOT, which ignores that restriction — which is why the Raiz G1 goes only on the agent's server.
• How to withdraw it: deleting the Raiz G1 from LocalMachine\Root will undo the installation, and the agent will no longer start. To refuse the trust even if the root stays in the store or returns to it, IT will place the certificate in LocalMachine\Disallowed with the last command below. That will work for the Raiz G1, the Emissora G1 or the signer's certificate, offline, and will be the answer to a compromise: none of the three tiers has a revocation list or OCSP, and the replacement will come in a new certificate issuance by AutoController.

Get-FileHash -Algorithm SHA256

computes the file's SHA-256 (v0, today).

Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root

will install the Raiz G1 in the machine store, in the elevated console of the agent's server, with -FilePath pointing at the Raiz G1 file (from the first version distributed through the channel).

agente instalar requisitos

will check, before the service is installed, that the Raiz G1 is in LocalMachine\Root, that no certificate of the chain is in Disallowed and that the root is valid for code signing; if anything is missing, it will refuse, naming the reason and the fix (from the first version distributed through the channel).

Get-AuthenticodeSignature

will report Valid once the Raiz G1 is in LocalMachine\Root; before that, it will report UnknownError, because the chain ends in a root Windows does not yet trust (from the first version distributed through the channel).

Import-Certificate -CertStoreLocation Cert:\LocalMachine\Disallowed

will place a certificate of the chain in Disallowed, in the elevated console, with -FilePath pointing at it: Windows will refuse it at once, offline, even with the Raiz G1 still in LocalMachine\Root (from the first version distributed through the channel).

Update policy

v0 (today): v0 does not update itself; it is updated by hand. Replacing v0 with the first version distributed through the channel is the only reinstallation allowed.

From the first version distributed through the channel, updates will follow these rules:

• Rings: each new version will go first to an internal test tenant, then to the connectors in acceptance testing (wave 0), to a canary client, to the clients who opt in to receive it early and, finally, to everyone. Promotion from one ring to the next will require a period with no bad signal.
• Maintenance window: each client will declare the day, hour and time zone of its window, and an interrupted update will resume in the next window. A security fix may bypass the window.
• Change classes: each release's class will be derived from the release itself, never declared by hand. Identical manifests will be a standard, pre-authorized change, distributed automatically in the window, after wave 0; a manifest change will be a normal change, going through the CAB and the DBA and never distributed automatically; a security fix will be an emergency change.
• Automatic rollback: the agent's supervisor will switch versions after the batch in progress and confirm the new one only if, within the grace period, the process stays alive, the heartbeat is accepted and the diagnostics checks pass; otherwise it will roll back to the previous version on its own.

Support policy

The rules below apply from the first version distributed through the channel: support windows count from that version, and the v0 pilot is replaced once by it.

Minor releases ship roughly monthly. The two previous minors or six months, whichever is shorter, are supported; the upgrade path is guaranteed from the previous major.

Deprecation and sunset have published dates; a tenant's pin holds at most until the end of the pinned version's support window. The pin is the version a client asks to keep fixed in its environment.

Supported operating systems: Windows Server 2016 to 2025 (2016, 2019, 2022, and 2025).

Data residency

The gateway that receives the agent's connections runs on AWS, in the sa-east-1 region (São Paulo), and AutoController's central database sits in the same region, as do its backups. What the agent sends is stored in Brazil.

Removal

What stays on the server: removing the service keeps the agent's keys in the service's profile and the log-on-as-a-service right granted at installation, and deleting the folders removes neither. What ends the agent's identity is revocation in the console: once its certificate is revoked, the key left on the server is useless.

If IT applied the optional certificado-sql step, what it wrote also stays, and only that: a self-signed certificate in LocalMachine\My; its key container in the Microsoft RSA SChannel Cryptographic Provider, with a single read entry for the service SID of the instance; and the instance's SuperSocketNetLib\Certificate value, pointing at that certificate. It is the agent's only write to the SQL Server configuration, made by IT in the elevated console, never by the agent's service nor at the cloud's request. That certificate belongs to the instance, not to the agent: neither removing the service nor revocation in the console touches it, and the step does not renew it.

To remove the agent:

• on the server, IT stops and unregisters the service with the first command below;
• if IT applied the certificado-sql step, IT uses the second command below to revert the step before deleting %ProgramFiles%\AutoController, because the agente.exe in that folder is what undoes it. While SQL Server uses the step's certificate, the revert does not finish in a single run: it says to run it again after the instance's next restart, in the DBA's window, or with the instance stopped; the folder stays until a run ends ok and without any sobras row;
• optionally, if you will not reinstall, delete the folders %ProgramData%\AutoController and %ProgramFiles%\AutoController;
• in SQL Server, the DBA drops the database user and the login (DROP USER and DROP LOGIN), which also removes the permissions granted;
• ask AutoController to revoke the agent in the console.

agente servico remover

stops the service, unregisters it and removes its source from the Windows event log.

agente instalar certificado-sql --reverter

reverts the certificado-sql step, in the elevated console, undoing only what the step created: clears the Certificate value when it points at the step's certificate, removes the read on the key, and deletes the certificate and the key container — these two only once the instance no longer uses the step's certificate, or is stopped. It never stops, starts or restarts SQL Server. On a server with more than one instance, it refuses without changing anything and lists the instances: run it naming each instance the step was applied to; on an instance the step was not applied to, it ends without changing anything.

Vulnerability disclosure

Report vulnerabilities privately to security@autocontroller.ai, never in a public issue, with the description, the impact, the steps to reproduce and the affected version.

First response within 48 business hours. A fix plan within 5 business days of confirmation.

After the fix, disclosure is coordinated, through a security advisory and a direct notice to the affected clients when there is impact. Researchers who report in good faith are credited, if they wish.