Suspicious Access Alerts: Issues for Odd Logins, Role Changes and Big Exports

Last verified on Nov 10, 2026.

Some access problems are not attacks. The login worked, the role was granted, the export finished. What is wrong is the context. The Sazabi agent sets up sensors for your project and keeps them current, and for this category those sensors are written from your own events, because only your logs know what an admin grant looks like.

The live signals

Three signals feed suspicious access. The agent writes all three from your own events:

• Authentication anomalies. Failed-login bursts, impossible travel and session reuse. The same signal also feeds active attacks, where it shows up as credential stuffing.
• Privilege changes. New admins, role escalations and newly created API keys.
• Unusual data egress. A large export or response going to a single actor.

Every one of them is a standing question about a number or an event in your logs. None is a rule you write.

Example: an admin role at 3 a.m.

This is an example, not output from a real project. The service name and people are made up. Your accounts service writes audit lines whenever a role changes:

2026-11-08T03:07:51Z INFO  accounts role_granted actor=j.rivera@example.com target=j.rivera@example.com role=admin ip=198.51.100.23
2026-11-08T03:08:20Z INFO  accounts api_key_created actor=j.rivera@example.com scope=full ip=198.51.100.23
2026-11-08T03:11:02Z INFO  reports export_started actor=j.rivera@example.com dataset=customers rows=412000

The agent writes sensors for these events: "Tell me when a role grant gives someone admin outside their usual hours," and "Tell me when an export is far larger than what is usual for that dataset." The first fires on the grant. Its investigation then looks at what the same actor did next and finds the key and the export.

The resulting issue might be "Self-granted admin followed by a full customer export", with high severity. The evidence lists the three lines, the source address and whether it matches earlier sessions for that account. It arrives already investigated, so the person on call starts with a timeline.

How the agent sets these up

The agent reads your logs, finds the fields that carry the actor, the action and the target, and writes and maintains each sensor. For export size, the question is whether an export is far larger than usual for that dataset, so a monthly finance export that always runs big is not a surprise.

Each actor and each dataset is judged on its own, so one odd export does not hide in the totals.

What you see and how you get told

Issues land in the inbox with severity, component and the agent's analysis. Because the agent has your logs in hand, the thread is where you ask the next question: did this actor ever export before, which other keys were created from that address.

Route the Issue triggered notification by severity. Many teams send high and critical access issues to a shared Slack channel and leave the rest in the in-app feed. Delivery rules can also match on component or owning team.

Resolve or ignore from the dashboard, Slack, Teams or the CLI. The CLI can also list the signals with sazabi signals list --type sensor.

What you need

Audit-style events in your logs. A good start is one line per login, role change, key creation and export, with a stable actor field. If you have not written them yet, a structured logging habit and an audit log go a long way. Ship them with any supported integration.

What it does not cover

• One actor reading far more records than usual, or walking IDs in order. Access anomalies is not covered today.
• Access that never gets logged. If your admin console writes nothing, no sensor can see a grant.
• Intent. The issue shows what happened and why it looks odd. Whether it was a legitimate emergency change is for you to decide, and you can ask the agent in the thread to help gather the context.

For the concepts behind this page, read the glossary on privilege escalation and data exfiltration. For metering, see pricing.