Nothing comes in: how AverDesk gets your data

To see your servers, an inventory tool usually asks you to open a door into the network. AverDesk does not. Here is how the data gets out without anything getting in.

The meeting that takes three weeks

Picture a company of two hundred people. The IT lead wants a tool that shows every server and what runs on it. The person responsible for security asks one question: what will the tool need to open from the outside? The IT lead says “just one port”. The security person has heard “just one” before and asks for a written request. The request waits for a committee. Three weeks later nobody remembers why they wanted the tool.

We have been on both sides of that table. So AverDesk follows one rule that keeps the meeting short: nothing comes in. Your network never has to accept a connection from us. Instead, something inside your network sends data out, on a schedule you set, through a connection your own logs can see. The rest of this article is what that “something” can be.

A small program that only talks outward

The first option is a small program you install on a server (the AverDesk agent, for Windows or Linux). It wakes up, connects to AverDesk, hands over what it has collected and hangs up. It never waits for anyone to connect to it. So there is no open door for a scanner to find, nothing to allow through the firewall and nothing to patch in a panic when a listening service turns out to have a hole.

If you are the only administrator, this means you can install it on a Friday afternoon without asking anyone. If you work in a larger company, the security review shrinks to one line: “it connects out to this one address”. That is a review most people finish before lunch.

The agent is also where the product is growing. Collecting more through it and filling the inventory automatically is what we are working on right now. The roadmap says what comes next.

Your people, straight from the company directory

Most companies already keep a list of employees and departments in a directory (Active Directory, or any directory that speaks the LDAP protocol). AverDesk reads that list: who exists and which groups they belong to. It never writes anything back, so there is no way for it to break your directory.

This reading also happens through the agent, from inside your network. One detail matters to anyone who has had to change a service password at 2 a.m.: the account used for reading does not need a password typed into our web form. The agent simply runs under a domain service account on a machine that is already part of your domain. No password is stored on our side, so none can leak.

Once people and groups are in, they become real objects. A department becomes the team that owns a service. A person becomes the owner of a server. When an employee orders a laptop through the portal, the request is tied to a real account from your directory, not a name somebody typed.

Files, when a file is what you have

Not every system has an agent or a directory. Sometimes what you have is a spreadsheet exported from a licence portal, or a data file produced by a script someone wrote years ago. AverDesk imports both (CSV and JSON). You match the columns to fields, run the import, and the records appear in the inventory with their history starting that day.

This is how most teams begin. They load their existing server list on day one and spend the next weeks connecting those servers to the services they carry. The list was never the hard part. The connections are, and those are best drawn by a person who knows them.

A way for your own scripts to talk to AverDesk

For anything that repeats, there is a programming interface (an API, described in the OpenAPI 3.1 format, so any developer can read it and most tools can generate code for it). Every request names the organization it belongs to, so one script can serve several organizations under the same subscription without mixing them up.

One property saves a lot of code: you can send the same batch of records twice and get the same result, not duplicates (in technical terms, bulk writes are idempotent upserts). No checking whether a record already exists, no cleanup after a retry.

In practice this is how people connect a hypervisor, a cloud console or a monitoring system. A short script, or a workflow in n8n, reads from the source and sends the records to AverDesk on a schedule. It runs inside your network and talks outward, exactly like the agent.

Ready-made cloud connectors are not available yet. They are on the list, and they will be built on this same interface. Until then the honest advice is: write a small script. It will keep working when the connectors arrive.

What the security meeting looks like now

With nothing coming in, the meeting is a short list of outbound addresses and one question: what data leaves? The answer is: what you choose to send. Passwords and keys stay on your side. On our side, every organization has its own separate database, and nobody at AverDesk can see inside it. The security page covers the rest.

If you want to see what the agent collects before you talk to anyone, start with the Free plan, install the agent on one test machine and watch the server appear. Then show the security person. It is a much shorter meeting.

Start free

IT inventory, connected services and daily support.

Read next

Guides

Start with one service

The fastest way to fail at an inventory is to import everything on day one. Here is how to start with a single service and grow from something that already works.

· 5 min read