Data Egress Alerts: Issues When One Actor Pulls Far More Data Than Usual

Last verified on Nov 10, 2026.

What it catches

Data leaves a company through ordinary doors: an export button, an API list endpoint, a report download, a storage bucket read. When that goes wrong, the door works. An account with real credentials pulls far more than it ever has, or a tool pages through an endpoint nobody scripted before.

Unusual data egress is the Sazabi detection for that. You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. Sensors are standing questions about your logs. For this one, the agent reads your logs to find which exports, responses and downloads you record, then asks about their size and who triggered them. There is no export list for you to define.

The questions the agent's sensors can ask:

• Is one actor pulling far more records or bytes than usual?
• Is a single export or response much larger than that kind of export normally is?
• Is an account downloading at an hour or from a place that is new for it?
• Is a bulk read of stored files happening that does not match normal access?

Example: a report that is fifty pages of customers

This is an example, not output from a real project. A service called reports-api records a line for every export, with the size and who asked:

2026-11-08T19:44:10Z INFO reports-api export actor=u_5510 type=usage_report rows=312 bytes=48210 ip=192.0.2.31
2026-11-08T19:52:33Z INFO reports-api export actor=u_5510 type=full_customer_list rows=1204880 bytes=412009344 ip=192.0.2.31
2026-11-08T19:53:01Z INFO reports-api export actor=u_5510 type=full_customer_list rows=1204880 bytes=412009344 ip=192.0.2.31

The first line is the actor's ordinary use. The next two are the same export, the largest of its type, run twice within a minute. The sensor asks whether an actor's export is far above what is usual for that kind of export, and Sazabi opens an issue. An example of what it could say:

• Name: Repeated full customer list export by one account
• Description: u_5510 usually exports small usage reports. At 19
  they ran the full customer list export, over a million rows, twice in one minute.
• Severity: high

The evidence is the export lines. The analysis says what that account usually does, which is how you can tell a one-off job from a pull of customer data.

Telling normal from not

A large export is often legitimate. A finance analyst closes the quarter; a customer migrates away. The agent writes and maintains the sensors so that routine exports are not the point. When a sensor does fire, an agent investigation decides whether it is a real problem, and harmless firings close without an issue.

The agent's reading is only as good as your logs. If the export line carries the actor and the size, each actor is judged against their own usual exports. If it carries neither, there is nothing to judge.

You can ask support for a specific sensor in plain words, for example "tell me when any export is much larger than usual". sazabi signals list --type sensor lists the sensor signals.

How you get told

The issue sends an Issue triggered notification to in-app, email, Slack DM or SMS, or to a shared Slack or Microsoft Teams channel when a delivery rule matches severity, component or owning team. In the thread, ask the agent follow-up questions, such as what else that account downloaded in the last day. sazabi issues agent-prompt hands a fix, such as a per-user export cap, to a coding agent. You can resolve, ignore or mute the issue from the dashboard, Slack, Teams or the CLI. Recurrences fold into an open or ignored issue.

What it needs

Logs that record the size and the actor. Application exports can arrive through OpenTelemetry. Network and storage views come from cloud logs such as AWS VPC flow logs and CloudTrail, and gateway logs add the response sizes for API routes.

What it does not cover

• Stopping a transfer or revoking access. Sazabi reports.
• Data that leaves through a channel you do not log, such as a screenshot or an email you do not send logs from.
• Deciding whether a download is permitted. It sees volume and context, not your data-sharing agreements.
• Slow, small extractions that stay within what is usual for the actor.

For measuring and baselining egress by hand, read the data exfiltration detection guide. The term is defined in the data exfiltration glossary entry. Issue volume is metered; see pricing.

A pull like this often follows a privilege change.