Privacy Policy
This is the one privacy policy for everything Agito Technologies runs online: the agitotechnologies.com website, Estrella (estrella.agitotech.com, its agent and its apps), Watchfloor, Oxcart, Firewatch, AirCheck (aircheck.agitotechnologies.com), and the Service Portal at cactus.agitotech.com. It says what each of them collects, how long it is kept, and who else ever sees it. It is written against how these services actually behave; where the answer is uncomfortable it says so rather than rounding it off.
1 Who is responsible
Agito Technologies, LLC operates every service named above and is responsible for the data in them. Nothing collected by any of them is sold, rented, or used for advertising.
2 agitotechnologies.com
This section covers the main website. AirCheck, at aircheck.agitotechnologies.com, keeps a record of each check and is covered separately in section 7.
2.1 Hosting and server logs
The website is hosted by DreamHost. Like any web server, DreamHost's records each request made to the site: the IP address, the time, the page asked for, the page that linked to it, and the browser's user-agent string. DreamHost keeps these logs for 7 days by default and builds site statistics from them — totals of requests, browsers, operating systems and referring pages — which Agito Technologies can see. AirCheck is hosted the same way (section 7).
2.2 Cookies and scripts
The site sets no cookies and stores nothing in your browser. (AirCheck stores one random identifier in your browser; see section 7.2.) It uses no analytics or tracking scripts and no advertising, and its fonts and images are served from the site itself. So there is no consent banner to click past.
2.3 The contact form
The contact form asks for your name, your email address and a message, and, only if you fill them in, your company and a phone number.
What you send is emailed straight to Agito Technologies at web.request@agitotechnologies.com, through DreamHost's mail service, with your address set as the one to reply to. The email also says when it was sent and from which page. The website itself does not store it. It is kept in that mailbox for as long as it is needed to answer you and to do business with you, and deleted on request (section 9).
2.4 Asking for early access to Watchfloor
The Watchfloor forms ask for your email address and, only if you choose one, how many screens you run or how many computers you look after. The request is emailed to Agito Technologies the same way as the contact form (section 2.3) and is not stored by the website.
Agito Technologies uses it to send your invitation and to follow up with you about Watchfloor, and for nothing else. There is no newsletter and your address is not shared or sold.
2.5 Asking for early access to Estrella
The Estrella form asks for your email address and, only if you choose one, roughly how many computers you look after. Your answers are sent straight to Estrella, not to the website's host, and are kept with the IP address the request came from and when it was made.
They are kept on the same list as Estrella demo sign-ups (section 4.2.5), with the status and notes Agito Technologies keeps against each. Asking again with the same address updates the record you already have rather than adding a second one, and an address that already tried the demo stays one record.
Agito Technologies uses these details to send your invitation and to follow up with you about Estrella, and for nothing else. There is no newsletter and your address is not shared or sold.
2.6 Keeping the forms free of spam
Each form has a hidden field that people never see and automated spam fills in; a submission with it filled is quietly dropped. To stop the same visitor sending many messages in a row, the website keeps a one-way hash of your IP address with the times of your submissions from the last ten minutes. It is used for nothing else, and older times are dropped the next time you submit.
2.7 Asking for early access to Oxcart
The Oxcart form asks for your email address and, only if you choose one, how many computers you look after. The request is emailed to Agito Technologies the same way as the contact form (section 2.3) and is not stored by the website.
Agito Technologies uses it to send your invitation and to follow up with you about Oxcart, and for nothing else. There is no newsletter and your address is not shared or sold.
What Oxcart itself keeps, once you use it, is in section 6.
2.8 Asking for early access to Firewatch
The Firewatch form asks for your email address and, only if you choose to answer, roughly how many computers you look after and whether you already use Estrella. The request is emailed to Agito Technologies the same way as the contact form (section 2.3) and is not stored by the website.
Agito Technologies uses it to send your invitation and to follow up with you about Firewatch, and for nothing else. There is no newsletter and your address is not shared or sold.
Firewatch itself is in development and switched on only for accounts Agito Technologies has invited. What it collects from a machine is in section 4.3.6, and what the Firewatch server keeps is in section 4.12.
3 The Service Portal (cactus.agitotech.com)
The Service Portal is Agito Technologies's sign-in service. It runs on a server Agito Technologies operates, and it is the identity provider that Estrella and other Agito services hand sign-in to — which is why those services never see your password.
For each account it holds your username, name and email address, the groups you belong to, a securely hashed password, and any second-factor methods you set up, such as an authenticator app. It records sign-ins, failed sign-in attempts and account changes, with the time, the IP address and the browser's user-agent string. It sets cookies to keep you signed in and to carry a sign-in in progress; they are needed for signing in and are not used to track you.
Records of sign-ins, failed attempts and account changes are kept for one year.
Estrella can manage Service Portal accounts on a customer's behalf: it can create accounts and groups, add people to groups and remove them, and ask the Service Portal to send a password-reset email (section 4.7.2).
For now, accounts are created by Agito Technologies for clients and staff, and there is no public sign-up. Before public sign-up opens, this section will say what it collects.
4 Estrella
Estrella is fleet-monitoring software. It watches computers and tells somebody when one of them stops working. This part covers the Estrella web application, the agent installed on monitored machines, and the mobile apps.
4.1 Who this part is about
There are two groups of people in this document and they are not the same group. People who sign in are administrators and technicians who use Estrella. Monitored machines are the computers an agent is installed on; the people who use those computers may never sign in to Estrella and may not know it is there. Section 4.3 is about them, and it is the section worth reading twice.
Somebody who only tries the demo is neither: they get a private copy of a fictional customer for a few hours and never have an account. Section 4.2.5 is what is kept about them.
If you are being monitored by an employer or an IT provider, they chose to install the agent and they decide what happens with what it reports. This document tells you what the software is capable of collecting. It cannot tell you what your organization does with it.
4.2 What we collect about people who sign in
4.2.1 Your account
Your email address, your name if your identity provider supplies one, the identifier your identity provider uses for you, your role, and when you last signed in.
Estrella does not hold a password for you. Sign-in goes through a separate identity provider — the Service Portal, section 3 — and this software never sees what you type there. There is a column in the database for a password and nothing in the software has ever written to it.
4.2.2 Your sessions
Each time you sign in, a row is written recording when, from what IP address, and with what browser user-agent string. The session cookie itself is a random value, not a token containing facts about you, and only a hash of it is stored — the cookie in your browser is the only copy.
A session ends after 12 hours of inactivity, or 7 days absolutely, whichever is first. Your identity provider's identity token is stored on the session row until you sign out, because signing you out of the identity provider as well requires handing it back. Signing out clears it in the same operation that ends the session. A session that simply times out keeps it until the row is deleted.
These rows are also the sign-in log that administrators can read under System. Once a session has ended, its row is deleted 90 days after the sign-in it records.
4.2.3 Phones
| What | Kept |
|---|---|
| A login token for the app, and the IP it was issued from | The token works for 365 days, unless revoked. The record of it is kept after that. |
| The device name you gave it, the platform, and the app version | Kept with the login record |
| Apple's push token, the app's bundle id, the iOS version, and whether it is a test or production build | Indefinitely, unless the phone is removed |
| The one-time code used to sign a phone in | Deleted by the daily cleanup (section 4.6) once it has been used or has expired |
A phone login deliberately has no idle timeout. A phone nobody has opened for a week still has to be able to wake somebody at three in the morning.
4.2.4 What you type into it
Notes on alerts, reasons for pausing or un-monitoring something, notes attached to a restart or shutdown, customer contact and billing details, and anything submitted through the feedback button. Free text is kept as typed; nothing rewrites it and nothing analyses it.
A feedback report also carries a diagnostic bundle: the address of the page you were on (without anything after a #), the Estrella build, your browser's user-agent string, your operating system, your browser's languages, your screen and window size, your light-or-dark setting, your time zone, and short lists of recent errors, recent failed requests and the screens you moved through. Request and response bodies are deliberately excluded. You may also attach a file, and a screenshot is the usual one. Any picture is shrunk and re-encoded as a JPEG in your browser before it is sent; other files are stored in the database exactly as uploaded.
4.2.5 Trying the demo
The demo page offers up to three ways in, and each keeps something different:
| Way in | What is kept |
|---|---|
| The sign-up form | Your name, your company and your email address; and, only if you fill them in, a phone number, your job title, roughly how many computers you look after, what you use today and how you heard about us. Signing up again with the same address updates what you gave before. |
| An emailed link | Your email address, when you asked for the link, when it was sent or declined, and whether it was used. The link goes to that address through the mail server in section 4.7.2. |
| An invite code | Nothing you enter. The code counts how many times it has been used and when it was last used, and those visits are recorded under the label Agito Technologies gave the code, which may be the name of the person it was made for. |
With the form and the emailed link, the IP address of the first request is kept too, as is how many times you have entered the demo and when you last did. Agito Technologies uses these details to follow up with you about Estrella, and for nothing else.
The demo itself is a copy made for you alone. It lasts at most 3 hours, and ends sooner if you leave or after 30 minutes with nothing happening — and when it ends, the copy is deleted along with everything done in it, including the temporary login it ran under, its sessions and its entries in the audit log. The one exception is a note sent with the feedback button from inside the demo: it is kept, under whatever name and address you gave, and it cannot carry attachments.
4.3 What the agent collects from a monitored machine
The agent runs as a system service with administrative privileges, checks in about once a minute, and collects the following on the schedule in section 4.4.
| Category | Fields |
|---|---|
| Performance | Processor load, memory and swap used, uptime, last boot, bytes sent and received, whether the internet was reachable and how quickly, processor temperature, and how many processes are running. |
| Disks | Mount point, device, filesystem type, and how full each one is. |
| Network | Each interface's name, MAC address, IP addresses — private and, where one is present, public — whether it is up, its gateways and DNS servers, and whether it uses DHCP and from which server. |
| Sensors | Each temperature sensor's name, label and reading. |
| Processes | Name, process id, the full path to the program, an application name where one can be determined, state, processor and memory use. No process owner is collected. |
| Services | Name, display name, whether it is running, its state, start mode, process id, its description and the full path to the program, arguments included. |
| Installed software | Name, version, publisher, and where the entry was read from. |
| Hardware | Machine name, domain, chassis type, whether it is a virtual machine, manufacturer, model, serial number; operating system name, version, build and install date; processor, memory modules, graphics, audio, network adapters and storage devices — including motherboard, BIOS and disk serial numbers, and the last five characters of the Windows product key, never the key itself. |
| Updates | Which operating-system updates and packages are installed and which are outstanding, with title or package name, version, category, severity, size and whether a reboot is pending. |
| Security posture | Antivirus products and their state, including Microsoft Defender's definition version and age, its last quick and full scans and whether tamper protection is on; firewall state; and disk-encryption status per volume. On Windows: whether Remote Desktop is on, its port, whether it requires network level authentication, which kinds of network can reach it and the state of its service; and the effective security settings — password length and age rules, account lockout, the guest account, User Account Control, how long before the screen locks, USB storage, AutoPlay, SMBv1, what the power menu offers, and sleep and hibernate. On Linux: the SSH daemon's port and its root-login and password-authentication settings, fail2ban (whether it runs, its rule sets and how many addresses it is currently blocking) and the state of automatic updates. |
| Administrators | On Windows, the members of the local Administrators group: each one's name (such as DOMAIN\jsmith), whether it is a user or a group, whether it comes from a domain, and whether a local account is disabled. See section 4.3.1. |
| Domain and policy | On Windows, whether the machine is joined to a domain, the domain's name, the computer's location in Active Directory, the names of the Group Policy objects applied to it, and when policy was last applied. |
| Regional settings | The machine's system locale and time zone. |
| The agent itself | A one-way hash of a hardware identifier (the BIOS serial number on Windows; the board's UUID or serial number on Linux), sent with every check-in, and at enrollment a one-way hash of the operating system's own machine id, so that a reinstalled machine keeps its record; which features this agent supports; and its own error log, including the last lines written before an unclean stop, scrubbed as section 4.8 describes. |
4.3.1 Where a person's name can appear
The agent enumerates every process on the machine and records the path to each program. A program launched from somebody's profile has that profile in its path —
C:\Users\jsmith\AppData\...or/home/jsmith/.local/bin/.... So a username, and a path inside a home directory, can and does end up in what is collected. The same is true, less often, of a service's program path.
This is a consequence of collecting program paths at all, and program paths are what make it possible to tell two identically-named processes apart. We would rather say it plainly than describe the collection in a way that hides it. Where an account has Firewatch, the same is true of the security agent's file-change records (section 4.3.6), which carry each file's path, owner and group.
On Windows the agent also lists who has administrator rights on the machine, and that list is made of account names —
DOMAIN\jsmith. It is collected so that a machine somebody was given administrator rights on, and never had them taken away, can be found. An organization that names its Active Directory locations or Group Policy objects after people will see those names collected too.
4.3.2 What the agent does not collect
Subject to section 4.3.1, the agent does not collect: the contents of any file, document names, browsing history, screen contents, keystrokes, clipboard contents, email, messages, webcam or microphone input, or which person is logged in. It does not list user accounts, apart from the members of the Windows Administrators group described in section 4.3.1. There is a field named locale.user and it holds a regional setting such as en-US, never a person. Firewatch, where an account has it, is a separate program that does collect some of these things; see section 4.3.6.
The agent has no ability to run arbitrary commands. It accepts six instructions — restart, shut down, update itself, reinstall itself, install updates, and preview updates — each of which maps to a fixed operation compiled into it. Nothing in an instruction is ever run as a command.
Installing and previewing updates are the only two instructions that carry any detail from the server: the list of updates to install or preview. Every update on the list has to be on the machine's own list of available updates, or Estrella refuses to send the instruction. The list is handed to the machine's own update tool as data. Installing changes the software on the machine, and it can be sent by a schedule nobody is watching. A preview changes nothing. Section 4.3.4 describes both in full.
Screen contents: the agent never captures them. A person signed in to Estrella can attach a screenshot to a feedback report, and that file is stored. Those are different things and only the second one is under anybody's control.
4.3.3 Location
No GPS, no geolocation lookup, no coordinates, no IP-to-location database. A machine's time zone and regional settings are collected and are a coarse signal of where it is; section 4.2 covers the IP addresses recorded when somebody signs in.
4.3.4 Installing updates, including on a schedule
Estrella can install updates on Windows and Linux machines. This changes the software on a customer's computer, so here is exactly what it does:
- What gets installed on Windows. Only updates that Windows Update, or the organization's own update server, is already offering that machine. A person chooses categories (operating-system updates, security updates, Microsoft Defender definition updates, and other software updates) and each machine installs the matching updates from its own waiting list. These updates come from Microsoft or the organization's update server, not from Agito Technologies.
- What gets installed on Linux. The machine's own package manager (apt, dnf or zypper) installs packages from the repositories already set up on that machine, which can include repositories other than the distribution's own. A person chooses operating-system updates, security updates, or both. Each package asked for has to be on the machine's list of available updates, but the package manager installs the version the repository holds at that moment, together with any other packages it needs. These come from whoever runs those repositories, not from Agito Technologies.
- Previewing, on Linux. A person can ask a Linux machine what an install would change before installing anything. The machine runs its package manager's dry run and reports what would change: with apt, which packages and from which version to which; with dnf or zypper, the dry run's own output. Nothing is installed. The answer, up to its first 400 characters, is kept with the machine's command record (section 4.6.2).
- When. When a person asks, for one machine or many, or unattended on a schedule: weekly, or a set number of days after Microsoft's monthly release, at a chosen time, in the account's time zone unless another is chosen. A schedule can roll out in stages, a few machines first and the rest days later, and one person can set the same schedule across several customer accounts they look after. Separately, an account can switch on keeping Microsoft Defender definitions current: as soon as a machine's definitions are older than the account's limit (between 1 and 24 hours, 4 by default), it is sent a definitions-only install, at any time of day and with no restart.
- On whose authority. A schedule acts as the person who created it. Every install it starts is recorded under that person's name, and their access is checked again each time it runs. If they no longer have access, it stops reaching those machines. Definition installs are recorded under one of the account's administrators, who is not necessarily the person who switched them on.
- Restarts. Installing updates never restarts a machine by itself. The person asking, or the schedule, can choose to restart machines that need it once their updates have installed. On Windows, no restart is sent to a machine where nothing installed. On Linux, a machine that cannot say whether it needs a restart is treated as needing one, and the agent cannot yet always tell a failed install from a successful one, so a restart can follow a failed install.
- Warnings. Before any restart or shutdown, the agent tries to give whoever is at the machine 60 seconds' warning: an on-screen notice on Windows, and a message to signed-in terminal sessions on Linux and macOS, which somebody at a graphical desktop will not see. If the warning cannot be given, the restart goes ahead without it.
- Other systems. Installing and previewing updates are not available on macOS. The agent there refuses both instructions and says so.
- Records. Every install and preview, what it installed or failed to install, and every restart are kept as described in section 4.6.2.
4.3.5 What the agent changes and shows on the machine itself
- Remote Desktop. The Windows installer has a Remote Desktop box. On a first install it is ticked, and installing turns Remote Desktop on, allowed from private and domain networks (the installer does not open it to public networks, though it does not close a public-network rule that is already there) and with network level authentication required. Installing over an existing agent shows the machine's current setting and leaves it as it is unless somebody changes the box. Unticking the box turns Remote Desktop off; running the installer with
--no-rdpleaves it as it is, and--enable-rdpturns it on. - The desktop panel. If an account switches it on (it is off unless it does), Windows machines show a small panel in a corner of the desktop, or a bar across it, with the fields the account chose: for example the computer's name, who is signed in, its addresses, its processor, memory and disk use, the support contact details the account entered, and how many alerts are open and what they are. Anyone at the machine can see it. To draw it, the agent writes the chosen fields, and only those, to a file on the machine that any local account can read. Who is signed in is read on the machine for the panel and is not sent to Estrella.
- The status file and tray icon. Whether or not there is a panel, the agent keeps a small status file on every machine that any local account can read, holding the machine's name, its Estrella account's name, its machine id, the server's address, the agent's version, its last error and the titles of open alerts. On Windows the tray icon shows the same.
- Machines waiting for approval. An account can require new machines to be approved. A machine waiting for approval still enrolls and reports everything in section 4.3, so that it can be seen before anyone decides. It raises no alerts and takes no instructions until it is approved.
4.3.6 Firewatch: the security agent Estrella can install
Firewatch is a security monitoring add-on to Estrella. It is off unless an account has it. Where an account has it, the Estrella agent downloads and installs a second program on each of the account's machines that can take it — a security agent — and reports whether it is installed and connected. This changes the software on a customer's computer, so here is exactly what it does:
- What is installed. One specific security agent on Windows, Linux (Debian- and Red Hat-based) and macOS. The installer's download address and a fingerprint of the file are fixed inside the Estrella agent; a download that does not match is deleted unopened, and the Estrella server cannot name a different program, version or source. It is downloaded from its publisher's servers, not from Agito Technologies (section 4.7.2). It runs as a system service with full administrative rights.
- Where it reports. Only to Agito Technologies' own Firewatch server, which runs alongside Estrella in the United States. That address is also fixed inside the Estrella agent, which refuses to set the security agent up for anywhere else.
- What it collects. Security information about the machine, sent to the Firewatch server as it happens: security-relevant events from the machine's own logs (for example sign-ins and failed sign-ins, with the account names involved, and software being installed or changed); changes to watched system files and folders, with each file's path, fingerprint, size, owner and when it changed; the results of checks against security configuration benchmarks; and an inventory of the machine's hardware, operating system, network interfaces, installed software, running processes, open network ports, and local user accounts and groups, which is used to find software with known vulnerabilities. Unlike the Estrella agent (section 4.3.2), it therefore collects the names of user accounts and of files on the machine. It does not collect the contents of documents, email, messages, screens or keystrokes. Exactly which of these are switched on is set by Agito Technologies on the Firewatch server for each account.
- What it can do to the machine: automatic response. Where an account enables it, the security agent may act automatically on a machine in response to a detection, from a fixed list of responses that Agito Technologies ships. In this release that list contains one entry: temporarily blocking network traffic from a source address, which expires by itself. We do not add responses to this list without describing them here first, the list cannot be extended by an account, and no response can be triggered by hand from Estrella; responses fire only from the fixed detection rules. Those responses run with full administrative rights on the machine. This setting is off unless an account administrator turns it on.
- Removing a security agent that is in the way. Firewatch cannot install over a security agent that is already present. Where an account has enabled it, a machine may remove a security agent it finds already installed, and only when that machine determines the existing installation to be abandoned: that it was never enrolled with any security manager, or is already enrolled with ours, or has shown no sign of activity for thirty days. An installation that is still reporting to a security manager is never removed. That determination is made on the machine, from files on the machine, and cannot be overridden by Agito Technologies: the server sends only permission, never an instruction, and never names a file or a path. At present only macOS machines can remove one; on other systems an existing agent is left alone and Firewatch is not installed there. This setting is off unless an account administrator turns it on.
- What Estrella keeps about it. On each machine's record: whether the security agent is installed, its version, its identifier and name on the Firewatch server, whether an install is in progress, the last install error, and when an enrollment token was last sent. The name it is given is the machine's hostname followed by part of its Estrella id. Findings themselves are kept on the Firewatch server.
- Turning it off. Switching Firewatch off for an account stops new installs. It does not remove the security agent from machines that already have it; uninstall it from those machines. An installed security agent is not upgraded by Estrella.
4.4 How often
| What | How often |
|---|---|
| Check-in, performance, disks, network, sensors | About every 60 seconds |
| Processes and services | About every 10 minutes |
| Installed software | About every 6 hours |
| Operating-system updates | About every 6 hours |
| Security posture | About every 2 hours |
| Hardware inventory | About every 24 hours |
An administrator can ask for a fresh inventory at any time, and a check that watches a particular service or process causes that category to be collected more often. Only the latest snapshot of each category is kept; there is no history of what was running last Tuesday. Hardware is the exception — see section 4.6.
4.5 Why
To tell somebody when a machine stops responding or a check fails; to install updates, or preview them, when a person asks, a schedule says to, or an account has switched on keeping antivirus definitions current; to show what a fleet looks like now and how available it has been; to make it possible to ask a question like "which machines are missing this update" and get a true answer; where an account has Firewatch, to find signs of intrusion, malware, weak configuration and known-vulnerable software on its machines and tell somebody (section 4.12); to run the product commercially, which means counting machines for billing; and to keep a record of who did what, which is section 4.8.
Nothing collected is sold, rented, or used to build a profile of anybody. There is no advertising in this product and no data leaves it for an advertiser.
4.6 How long it is kept
A few things expire on a schedule. Everything else is kept until it, or the record it belongs to, is deleted. That is the honest summary and the tables below are the detail.
A job runs once a day, at 04:00 UTC, and deletes exactly this:
| What | Kept for |
|---|---|
| Performance measurements | 90 days |
| Individual check results | 30 days |
| Sessions that have ended — the sign-in log | 90 days from the sign-in |
| One-time codes used to sign in a phone | Until used or expired |
4.6.1 Capped by count rather than age
| What | Cap |
|---|---|
| Agent log events | The newest 200 per machine, and nothing older than 30 days |
| Records of the agent stopping | The newest 50 per machine, with no age limit |
| Inventory — processes, services, software, hardware | The latest snapshot only; each collection overwrites the last |
| Local backup files | The newest 14 dumps |
| Saved copies of an account's settings, including its contact and billing details, kept so a change can be undone | The newest 20, plus one a day for 30 days |
| Firewatch findings on the Firewatch server (section 4.12; the raw events behind them go sooner) | No longer than 90 days |
4.6.2 Kept indefinitely
Nothing deletes these on a schedule. Feedback reports and their attachments, demo sign-ups, registered phones and update schedules can each be deleted in the product. Everything else stays unless Agito Technologies erases it on request (section 9).
- Alerts, including who acknowledged one, when, and any note they left.
- The audit log — every action taken in the product, who took it, their email address, whether they were acting inside a customer's account at the time, and the values a change replaced, so that it can be undone.
- Commands sent to machines — restarts, shutdowns, agent updates, update installs and previews — including the email address of whoever issued one, any reason they gave, and a short summary of the result.
- Update schedules, and a summary of each run, including the names of any machines it skipped.
- The hardware-change history: a permanent before-and-after record of hardware facts, kept deliberately so that "this machine had 32 GB in August" is still answerable months later.
- A record of every notification sent, including the email addresses it went to.
- Feedback reports, their diagnostic bundles, and any files attached to them.
- Demo sign-ups and early-access requests: what was given on the demo page or the website's form (section 4.2.5 and section 2.5), and the status and notes Agito Technologies keeps against each. Either can be deleted on request — section 9.
- Registered phones and their push tokens, and phone logins after they expire or are revoked.
- Customer contact and billing records, and the daily count of machines that billing is worked out from.
- Notes written about machines.
- Links for wall displays, and when each was last used.
- Records of errors in the Estrella server itself, which can name the account, machine or page involved.
- Checks and notification channels that were deleted. They leave every view, and the "Recently deleted" list after 30 days, but the records, including a channel's email addresses, are kept.
Deleting an account in the interface archives it: it stops alerting and drops out of every view, and everything above is retained and restorable. Agents in an archived account keep reporting until they are uninstalled, and what they report keeps being stored. An account cannot be permanently deleted in the product. If you want its data actually erased, ask (section 9) and Agito Technologies will do it.
4.7 Who else ever sees it
Everything that can leave the Estrella server or a monitored machine:
4.7.1 The connectivity probe — every monitored machine
To answer "is this machine's internet working", the agent requests a small page from Cloudflare and from Google on every collection pass. Two providers, so one having a bad day does not read as a machine losing the internet. Each request necessarily tells that company the machine's public IP address and the time. No fleet data, no identifier and nothing about the machine is sent. The addresses are configurable, and an installation that would rather probe something it runs itself can point them anywhere.
4.7.2 Other services
| Who | What reaches them | When |
|---|---|---|
| Anthropic, whose Claude service answers "What is this?" about a program | Three lines: whether it is a process, a service or an application; its name; and its publisher if the machine reported one. No hostname, no machine identifier, no account, no path, no IP. | Only when somebody signed in, other than a read-only viewer, asks what an unfamiliar program is. The answer is saved and shown to anyone who asks about the same program, so a program is usually looked up once; one without a confident answer is asked about again later. Agito Technologies has this turned on. |
| Apple | The push notification itself, which carries the machine's name, the alert's text, the site or customer it belongs to, and Estrella's own identifiers for the alert and machine. An acknowledgment notice includes the email address of the person who acknowledged it. | Only if push notifications are configured and somebody has registered a phone. |
| The mail server | Alert emails (opened, acknowledged and resolved), and their recipients. Links to the demo, and the address each was asked for. Demo requests waiting for approval, sent to Agito Technologies with the name and company given. Notices about Estrella's own health, to Agito Technologies. Test emails, to the address they are sent to. If the email logo is set to a web address, each recipient's mail program fetches the logo from there. | Whenever there is something to send. |
| The identity provider (the Service Portal, section 3) | Sign-in and sign-out. Estrella also manages people there for a customer: it looks people up by email, creates accounts and groups, adds people to groups and removes them, and asks for password-reset emails to be sent. | Always — it is how signing in works. |
| Agito Technologies' billing system | For each customer account: its name, billing email and reference, plan and prices, how many machines were watched each day and at the month's peak, and the charges worked out from them. The billing system can also mark a month as invoiced and change an account's payment status, which can limit what the account can do (Estrella Terms section 6.7). | For every account billed through it. The billing system is run by Agito Technologies. |
| Update sources | The ordinary requests a machine makes when it updates itself: to Microsoft or the organization's update server on Windows, and to its configured package repositories on Linux. | When updates are installed or previewed. |
| The security agent's publisher | The ordinary request a machine makes to download the security agent's installer, which tells them the machine's public IP address and the time. Nothing else. | Only for machines in an account that has Firewatch (section 4.3.6), when the security agent is first installed. |
| VirusTotal, a malware reputation service | The cryptographic hash of a file that changed on a machine, never the file itself (section 4.12). | Only in an account whose administrator has switched reputation lookups on. Off unless they do. |
| An uptime monitor | A periodic signal that the Estrella server is still running, with no data in it. | Only if one is configured. |
Estrella has no payment processor connected and holds no card details of any kind. Billing is done by Agito Technologies' own billing system, above. If a payment processor is added there, it will be named on the Subprocessors tab first.
4.7.3 The web interface
No analytics, no tracking, no external fonts, no content-delivery networks, no third-party scripts. The page loads one script and it comes from this server. Nothing you do in the interface is reported anywhere.
4.8 Logs and the audit trail
The web server keeps an access log: the client IP address, the time, the request, the response code, the referring page and the browser user-agent. Every sign-in and every agent check-in passes through it. It lives outside the database and outside every retention window in section 4.6 — how long it is kept is set by the machine it runs on, not by this software.
The server's application logs also record some events with details, such as a machine enrolling with its IP address, hostname and account. Like the access log, how long they are kept is set by the machine they run on.
The application's own audit log records every action taken in the product with the email address of whoever took it. Nothing in the software updates or deletes a row in it, with one exception: when a demo ends, its rows go with it (section 4.2.5). Nothing expires it. Actions taken by the billing system are recorded under the name of its key rather than a person.
When Agito Technologies works inside a customer's account for support, the session records which account and, when we view the product as one of that customer's users to see what they see, which user. Every action taken that way is in that account's audit log as ours.
Agent log lines are scrubbed of anything resembling a credential before they are stored or transmitted. Error reports exclude request bodies, headers and query strings.
4.9 Backups
A complete database dump is taken nightly. The application can read backups and hand one over; it cannot write to, alter or delete one — the store is mounted read-only to it, which is a boundary rather than a detail. The newest 14 are kept locally.
Each night a copy is pulled to Agito Technologies' own storage, and from there copied to a cloud storage provider in the United States (see the Subprocessors tab). The Firewatch server's data (section 4.3.6) is backed up the same way.
A dump is the whole database, so it contains everything in this document — and, because the mail server's password is stored as typed so it can be set from a screen, it contains that password too. Treat a backup file as a credential.
4.10 Cookies and browser storage
| Name | What it is for | Lifetime |
|---|---|---|
| estrella_session | Keeps you signed in. A random value; readable only by the server. | Up to 7 days — 3 hours in the demo |
| estrella_demo | Marks this browser as being in the demo, so that leaving it — or a visit that has already ended — goes back to the demo page. It holds the number 1 and nothing else. | Up to 3 hours |
| estrella_oauth | Holds the sign-in handshake while it is in progress. | 10 minutes |
| estrella_signed_out | Tells the sign-in screen you meant to sign out, so it does not send you straight back. | 2 minutes |
The interface also remembers, in your browser and nowhere else, your light-or-dark preference, which account you were last looking at, and which banners you have dismissed. None of it is sent to the server and none of it identifies you.
There are no advertising cookies, no tracking pixels and no cross-site identifiers, so there is no consent banner to click past.
4.11 Keeping it safe
- Everything travels over HTTPS.
- Session, agent, phone, enrollment and wall-display tokens, and billing-system keys, are stored as hashes. The only copy of the value itself is the one held by whoever it was issued to.
- People sign in through a separate identity provider, so this software never handles your password.
- Access is scoped per customer account: a person who administers one account cannot see another, and an administrator acting inside a customer's account is recorded as doing so on every action.
- The agent cannot be made to run arbitrary code; it accepts six fixed instructions and refuses anything else. The two that carry detail from the server, installing and previewing updates, accept only updates already on the machine's own list. Installs run only when a person asks, on a schedule a person set up, or to keep antivirus definitions current where an account has switched that on (section 4.3.4).
- Where an account has Firewatch, the Estrella agent installs only the one security agent whose download address and fingerprint are built into it, and sets it up only with Agito Technologies' own Firewatch server. That security agent can act on the machine with full administrative rights (section 4.3.6).
No system is perfectly secure and this document does not promise that one is.
4.12 Firewatch: what the server keeps
Where an account has Firewatch, the security agent described in section 4.3.6 sends its reports to Agito Technologies' Firewatch server, which runs alongside Estrella in the United States. This section is about that server.
What arrives. The security events, file changes, benchmark results and machine inventory listed in section 4.3.6, labelled with the machine's Firewatch name and the time, as they happen.
What is made from it. The server matches those reports against rules to produce findings, each rated from Low to Extreme. A finding records which machine, which rule matched, the events behind it, when it was raised, and what was done about it, including any automatic response Firewatch took on the machine. The same reports also feed the per-machine inventory of installed software and its known vulnerabilities, and the machine's score against the security benchmark.
Who sees it. The people who can see a machine in Estrella can see its Firewatch findings, in Estrella and on the Firewatch server's own console. Agito Technologies' own access is the same as for Estrella (section 4.8): recorded against the account, and against the user where we view as one. Nobody else sees it, and nothing in it is shared or sold.
Alerts. Findings at the higher ratings go out as alerts through the same email and push channels an account has set up in Estrella (section 4.2), so an alert carries the finding's title, rating and machine to whatever address or phone receives Estrella's alerts.
How long. Findings are kept for no longer than ninety days; the stream of security events they are made from for no longer than one hour, and events still waiting to be classified for no longer than ten minutes; the record of each automatic response taken on a machine for no longer than three days; and the security agent's own health metrics for no longer than thirty days. These are ceilings rather than guarantees: deletion runs by the age of the store a record sits in, not the age of the record, so a finding can be deleted sooner than ninety days after it was raised, never later. The machine's inventory, vulnerability list and benchmark score are kept as current state for as long as the machine is in Firewatch, each report replacing the last, and go when the machine does. Removing a machine from Firewatch, or switching Firewatch off for the account, stops new reports; what has already been kept ages out on the same schedule.
Other services it uses. Firewatch compares source addresses appearing in a machine's logs against lists of known-malicious addresses, and matches installed software against published vulnerability catalogues. Both reach Agito Technologies through its security-monitoring software's publisher and are held on Agito Technologies' own infrastructure. No information about a customer's machines is sent to that publisher, or to the original compilers of those lists, in order to use them. Separately, and only where an account enables it, the cryptographic hash of a changed file may be sent to VirusTotal, a third-party malware reputation service, to ask whether that file is known to be malicious. Only the hash is sent; file contents never leave the machine. A hash cannot be reversed into the file it describes, but it can identify a file that somebody else already holds a copy of. That setting is off unless an account administrator turns it on.
Backups. The Firewatch server's data is backed up the same way as Estrella's (section 4.9), so a finding can survive in a backup for as long as that section says.
What it does not do. The Firewatch server does not receive the contents of documents, email, messages, screens or keystrokes, because the security agent does not collect them. It does not watch network traffic.
5 Watchfloor
Watchfloor is in early access and not yet generally available. Today the only thing Agito Technologies collects about Watchfloor is an early-access request, described in section 2.4.
This section will describe exactly what Watchfloor collects before it collects anything more.
6 Oxcart
Oxcart carries files and text between computers, to the people on your team you share them with, and to and from people you choose through private links. It is in early access. This section says what it keeps today, and it will be updated before Oxcart is generally available and before Oxcart collects anything more.
6.1 Who this part is about
Account holders sign in to Oxcart with a Service Portal account (section 3) and send, receive and keep articles. An account holder's team is the other people in their organization who sign in with their own Service Portal accounts. People who use a private link do not have an account. They open a file or note someone sent them, or send files and text to someone through a drop link.
6.2 What is kept for account holders
- Your account: your email address, your name and the identifier the Service Portal uses for you. Oxcart never sees your password.
- Your sessions: when you signed in, from what IP address, and with what browser user-agent string.
- Your articles: each file or piece of text, its name, the note you gave it, its size, its burn time, when it was sent and when it was opened, and the private links made for it.
Text you mark as hidden is stored like any other article. It is hidden on screen, not kept anywhere else.
6.3 People who use a private link
When you open a private link, or send something through a drop link, Oxcart records the time, your IP address and your browser's user-agent string with that link. If the account holder set the link to ask for your name and email address, Oxcart keeps those with the link record too, and the account holder can see them. If you send through a drop link, Oxcart also keeps what you send: the files or text, and any name or note you add.
What you send through a drop link goes to the account holder who made the link. It is theirs, and they decide what happens to it. If you want something you sent removed, ask them first. We will help them answer.
6.4 Where it is kept
Oxcart runs on a DreamHost virtual server in the United States that Agito Technologies operates.
Files and text are never copied into backups. The database that lists articles is backed up nightly. It holds names, notes, sizes, times and link records, but not the files or the text itself.
6.5 How long it is kept
An article is kept until its burn time runs out or someone deletes it, whichever comes first. A note set to burn after reading is deleted when it is first opened. An article set to never burn stays until it is deleted or the account closes.
When an article burns, it goes all at once: the file or text, its name, its note, its links, and the records of who opened or sent through them. Nothing about it is kept in Oxcart. Database backups taken before then can still hold its name, note and times until those backups are replaced; the file or text itself was never in one.
Closing an account deletes all of its articles and links the same way.
The web server also keeps an access log of requests to Oxcart: the IP address, the time, the request and the browser user-agent. How long it is kept is set by the server, not by Oxcart.
6.6 Who can see it
The account holder can see their own articles. People on their team can see the articles shared with them, and anyone holding a private link can see what that link opens. Agito Technologies does not look at what is in an article, except when you ask us to help with it, when we investigate abuse reported under the Oxcart Terms, or when the law requires it.
Nothing in Oxcart is sold, used for advertising, or used to train anything.
6.7 How it is protected
- Everything to and from Oxcart goes over HTTPS.
- Files and text are encrypted on the server's disk.
- Each private link carries a random 16-character code that cannot be guessed or listed. The account holder can also require a PIN, and a name and email address, before a link opens.
- You sign in through the Service Portal, so Oxcart never sees your password.
No system is perfectly secure. If you think something is wrong, write to technologysecurity@agitotechnologies.com.
7 AirCheck
AirCheck is the connection checker at aircheck.agitotechnologies.com. It shows you how your internet connection looks from the outside, and unlike the rest of agitotechnologies.com, it keeps a record of each check.
7.1 What a check records
Opening the page looks up your address and shows you the results, but nothing is stored until the check finishes. Each finished check is stored as one record containing:
- the date and time;
- the public IP address your browser used to reach us (IPv4 or IPv6), and whether your connection has both;
- a keyed one-way hash of that address, used to group checks from the same connection and to limit how often one connection can record a check;
- your internet provider, their network number (ASN) and domain, and the reverse DNS name of your address, if it has one;
- an approximate location derived from your IP address — city, state or region, country, postal code, approximate coordinates and time zone. This is the location of your provider's equipment and is often some distance from where you actually are;
- latency and jitter, and download and upload speeds if you ran the speed test. These are measured by your browser and reported back to us: latency against our own server when the page loads, and all four figures against Cloudflare's network when you run the speed test (see 7.6). If the Cloudflare test cannot load, the speed test runs against our own server instead;
- your browser and version, operating system, type of device (desktop, mobile or tablet), screen size, language and the time zone your browser reports;
- whether your browser's time zone matched your IP address's time zone, and whether your browser exposed a local network address through WebRTC. The address itself is shown to you on the page but is not sent to us;
- the protocol and TLS version your browser used to reach us;
- the identifier described in 7.2.
We do not record anything you type, and AirCheck has no form to type into.
7.2 The identifier stored in your browser
The first time you open AirCheck, it generates a random identifier and stores it in your browser's local storage. It is not a cookie, it is not shared with anyone, and it contains nothing about you. It lets us tell checks from the same browser apart from other checks on the same connection, and it is what we will use to show you your own past checks once that view exists.
You can remove it at any time by clearing site data for aircheck.agitotechnologies.com in your browser. Doing so means a future visit looks like a new browser to us, and earlier checks can no longer be matched to you.
7.3 Why we keep it
To see whether AirCheck is working and being used, and to investigate abuse of the page. For our Managed IT clients, a record of what a connection looked like at a particular moment is often what settles a dispute with an internet provider.
7.4 How long we keep it
Check records, including the full IP address, are kept indefinitely. We may delete them at any time, and you can ask us to delete yours — see section 9.
Provider lookups from ipinfo.io (see 7.6) are cached on our server for one day, filed under a one-way hash of the address.
7.5 Who can see it
Agito Technologies staff, through a private page that requires a sign-in. We do not sell it, we do not share it with advertisers, and there is no analytics service on the page.
7.6 Other services involved
- DreamHost hosts AirCheck and keeps its own server access logs, as described in section 2.1.
- Approximate location and your provider's name come from MaxMind GeoLite2 databases stored on our own server. No request about you leaves the server for these.
- ipinfo.io is asked about your IP address so we can show your provider's domain. They receive the IP address, not your identifier or your readings.
- ipify.org is contacted by your browser to find out whether your connection has both an IPv4 and an IPv6 address. They see the request and your address.
- Cloudflare runs the speed test. When you start it, your browser transfers test data directly to and from Cloudflare's servers at speed.cloudflare.com; the data is meaningless filler, not anything of yours. When the test finishes, your browser also sends the resulting measurements to Cloudflare, as the Cloudflare speed test does on its own site. Cloudflare sees your IP address, the test traffic and those measurements, but not your identifier or anything else in 7.1. We send Cloudflare nothing. Their handling of it is covered by Cloudflare's own privacy policy.
7.7 Accounts
AirCheck has no accounts today. If we add the ability to sign in and see your history, we will update this policy before it goes live.
8 Managed IT clients
When Agito Technologies looks after your computers, network, cameras or backups, we may see data on those systems in the course of the work. What we may access, and what we do with it, is set by the service agreement between us, which governs where it says more than this policy.
The tools we use for that work are covered above. Monitoring your machines with Estrella, for example, is described in section 4.
9 What you can ask for
Write to LPCRadministrator@agitotechnologies.com and you can ask us for a copy of what is held about you, a correction, deletion, or an explanation of anything above. For Estrella, tell us if you want a record archived or genuinely erased, because they are different operations and section 4.6 explains why that matters.
For AirCheck, tell us your IP address or the identifier stored in your browser (section 7.2), so we can find your checks.
If you are monitored by an employer or an IT provider rather than by us directly, the data about your machine belongs to them and a request for it should start with them. We will help them answer it.
10 Changes, and how to reach us
The date at the top is when this was last changed. A change that alters what is collected or who it reaches will be noted on this page, and for Estrella and Oxcart announced in the product, rather than made quietly.
Questions about privacy, or anything legal: LPCRadministrator@agitotechnologies.com.