What agentless scanning means: read-only data discovery

The most expensive part of data discovery is usually not the scan but the setup that makes the scan possible. Installing an agent on every server, running a process on every endpoint and keeping them all current is a change-management burden that delays discovery projects by months. Agentless scanning removes that burden: it connects to the source remotely over a read-only connection, reads content and permissions, and leaves nothing behind on the scanned system. This entry explains how agentless scanning works, how it connects by source type, how it compares with the agent-based approach, and where its limits lie.

What agentless means

An “agent” is a software component installed on, and running inside, the system that holds the data; it watches the file system, reads content and sends results to a central server. In the agentless approach that component does not exist. The scanning engine runs in the console on the organization’s own infrastructure and connects to each source with the protocol the source already exposes: SMB or NFS for a file server, Microsoft Graph for Microsoft 365, a read-only client connection for a database, the S3 API for object storage.

Three consequences follow directly. First, nothing is written to the scanned system and no process is left behind; the server’s configuration is identical before and after the scan. Second, setup time consists of installing the console and defining the first connection; the first scan can begin the same day. Third, scope depends on connection definitions rather than on an agent rollout plan; adding a source means defining a connection.

Being read-only is the complement of being agentless. Every Seratus connection is limited to read permission: db_datareader on SQL Server, a read-only application permission on Microsoft 365, an account with read rights on file servers. Remediation actions (masking, quarantine, permission removal, disposal) run in a separate, approved flow with separate authority; the scanning account carries no permission to change anything.

Connecting by source type

Agentless scanning is not a single technique but a principle adapted to each source type. Each source reads content and permissions differently.

File servers and local disks. SMB/CIFS and NFS shares are mounted remotely and read; local disks on Windows, Linux and macOS are scanned without agents as well. For each file, content and folder or file ACLs are collected together. Where permissions cannot be read, the content is still scanned and the permission state is reported as a warning; “not scanned” and “permissions unreadable” are distinct states.

Microsoft 365. SharePoint Online, OneDrive and Teams files are scanned through Microsoft Graph with a read-only application permission. Sharing links (anonymous links, “everyone in the organization”) are translated into exposure levels. After the first full scan only changes are processed (delta), which makes continuous discovery feasible in large tenants.

Relational databases. Oracle, SQL Server, PostgreSQL, MySQL and MariaDB are connected read-only. Scanning is sampling-based: the table is the container, the column is the scanned unit; samples are taken per column and identifiers are searched within them. The role-to-table permission graph shows which role reaches which table. Sampling is the price of scanning a production database without burdening it, and it requires naming the result honestly: “not found in the sample” is not a risk verdict.

Object storage. S3-compatible stores such as Amazon S3, MinIO and Ceph are scanned through the S3 API; request signing (SigV4) is implemented in Seratus’s own code, with no third-party SDK dependency. Where the bucket policy or ACL is readable, it is added to the permission graph.

Email archives. PST, OST and MSG files are opened as files; message bodies and attachments are scanned. No live mailbox is connected to. The distinction is not only technical. The Authority’s Decision 2026/2035 of 16 September 2026 on monitoring corporate communication channels stresses separating “technically accessible” from “legally accessible” and avoiding content reviews that are undefined in scope, general and continuous. Discovery over archive files is an inventory exercise with a defined purpose and scope; live mail monitoring calls for a different legal assessment. This entry is not legal advice; the organization’s legal function should evaluate the distinction in its own context.

Source	Protocol	Permission source	Scan mode
SMB/CIFS, NFS, local disks	Remote mount	Folder/file ACL	Full, resumable
Microsoft 365	Microsoft Graph	Sharing links, site permissions	Full, then delta
Oracle, SQL Server, PostgreSQL, MySQL, MariaDB	Read-only client	Role-to-table grants	Sampling-based
S3-compatible object storage	S3 API, SigV4	Bucket policy / ACL	Full, resumable
PST, OST, MSG	File read	ACL of the file’s location	Bodies and attachments

Interrupted scans and continuous discovery

Scanning a large file server takes hours, sometimes days. During that window a network outage, a maintenance slot or a console restart is routine. In agentless scanning the cost of this depends on whether the scan can resume where it stopped. Seratus records every processed file and object; after an interruption, the scan continues from what has not been processed, and nothing already scanned is read again.

Continuous discovery is built on top of that. In Microsoft 365, delta scanning processes only changed files; on file servers and object storage, rescans can be scheduled and scope widened piece by piece. The result is a process that keeps the inventory alive rather than a one-off project, and “data missing from the inventory” becomes visible as a gap within that process.

Comparison with the agent-based approach

The agent-based approach has legitimate strengths, and they should be named. A component running on the endpoint can see what the user is doing at that moment: a file being copied to a USB drive, pasted into a web form, captured in a screenshot. That is a necessary capability for channel monitoring and blocking (classic DLP), and it is not the subject of agentless scanning.

The cost of the agent-based approach is installation and operation: software on every server and endpoint, an update cycle, a performance debate, a security review, a compatibility matrix (which operating system version, which kernel). Until the rollout is complete, scope is incomplete, and incomplete scope means an incomplete inventory.

Criterion	Agentless scanning	Agent-based approach
Setup	Console and connection definitions	Software rollout to every source
Effect on the source system	Read load, no persistent process	Persistent process, update cycle
Widening scope	A new connection	A new rollout
Discovery of data at rest	Yes	Yes
Real-time user behaviour	No	Yes
Change-management burden	Low	High

The two approaches are not alternatives to each other; they answer different questions. “Where is the data, who can reach it, how risky is it” is a question about data at rest and is answered by agentless scanning. “Which user is moving which file where, right now” is a channel question. Seratus focuses on the first; channel monitoring and blocking are not offered as a current capability.

The limits of agentless scanning

Every method has limits, and stating them openly builds trust in the product.

• A source that cannot be connected to is not scanned. A source without network access, an account and defined permissions is outside scope. The discovery report therefore shows “not scanned” as a distinct state, never confused with “not found”.
• Sampling is not a full scan. In databases, samples are taken per column; a rare identifier may not appear in the sample. The product labels this “not found in the sample” and does not issue a risk verdict.
• Unreadable permissions. On some files the ACL cannot be read; the content is still scanned and the permission state is reported as a warning. In the access graph these files appear as “permissions unknown”.
• Real-time behaviour is not observed. Agentless scanning looks at data at rest; it does not watch what a user is doing at the moment.
• Live mailboxes are not scanned. Only PST/OST/MSG archive files are read; this is both a technical boundary and a design choice the organization should evaluate with its legal function in light of the Decision cited above.
• A scan is a photograph; keeping it current is a process. Without delta and scheduled scans, discovery goes stale.

How Seratus closes these gaps

The value of agentless scanning shows in how honestly those limits are managed. Seratus does so with the following capabilities.

• Agent rollouts delaying discovery for months. The Seratus console is installed on the organization’s own infrastructure from a signed package; scanning starts the moment a read-only connection to the first source is defined. File servers, local disks, Microsoft 365, databases, object storage and email archives are scanned by the same engine (agentless DSPM, integrations).
• The scanning account carrying write authority. Every connection is read-only (db_datareader on SQL Server, a read-only application permission on Microsoft 365). Remediation actions run with separate authority, assigned to an owner and approved by a second person; every step is written to the audit trail (remediation and evidence).
• Long scans restarting from zero after an interruption. An interrupted scan resumes where it stopped; in Microsoft 365, delta scanning processes only changes (Microsoft 365).
• Sampling results being misread. Database findings are shown with a confidence percentage and a masked sample; “not found in the sample” is explicitly marked as a technical finding (Oracle, SQL Server, PostgreSQL/MySQL).
• Files with unreadable permissions being silently skipped. The file is still scanned, the permission state is reported as a warning and shown separately in the access graph (file servers).
• Exporting data in order to discover it. Scanning, classification and reporting happen inside the organization; air-gapped deployment is supported, and optional LLM enrichment runs only with an on-premises model (private LLM and air-gap).

Takeaway

Agentless scanning reduces data discovery from a rollout project to a connection definition: connect to the source remotely and read-only, read content and permissions, leave nothing on the scanned system. The approach answers where data at rest is, who can reach it and how risky it is; it does not observe real-time user behaviour and does not claim to. A scan that names its limits produces evidence an audit can rely on. The next entry looks at which obligations that evidence serves: the operational KVKK duties of a data controller.