Privilege Change Alerts: Issues for New Admins, Role Escalations and API Keys

Last verified on Nov 10, 2026.

What it catches

A privilege change is rarely a break-in on its own. It is the step that makes the break-in matter. Someone with a stolen session grants themselves admin. A script creates a long-lived API key that nobody remembers. A contractor's role quietly widens. Each change is a normal-looking audit event, and the question is whether anyone meant it.

Privilege changes is the Sazabi detection for those events. You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time: it reads your logs, finds the audit and admin events your system emits, and writes sensors that ask about them. It keeps those sensors current as your system changes, so you do not maintain a list of events to watch.

The agent's sensors can ask about:

• A new administrator, or an existing user granted an admin role.
• A role escalation, such as a read-only member becoming an editor.
• A new API key or access token, particularly a broad or long-lived one.
• A change that happens at an odd hour or from a location the account has not used before.
• A policy or permission edit in a cloud account.

Example: an admin grant at 3 a.m.

This is an example, not output from a real project. A service named workspace-api writes an audit line for each membership change:

2026-11-08T03:02:17Z AUDIT workspace-api actor=u_8821 ip=203.0.113.77 action=role.update target=u_9402 from=member to=admin
2026-11-08T03:02:40Z AUDIT workspace-api actor=u_9402 ip=203.0.113.77 action=apikey.create scope=full_access expires=never
2026-11-08T03:03:05Z AUDIT workspace-api actor=u_9402 ip=203.0.113.77 action=export.start dataset=customers

One address performed an admin grant, and the new admin immediately created a key that never expires and started an export. The sensor asks whether any account has been granted admin at an unusual time, and Sazabi opens an issue. An example of what it could say:

• Name: Admin grant followed by a never-expiring key and a customer export
• Description: u_8821 promoted u_9402 to admin at 03
  UTC. Within a minute u_9402 created a full-access API key with no expiry and began exporting customer data. All three actions came from one address.
• Severity: critical

The evidence is the three audit lines in order. The analysis connects them as a chain, since each one alone could be routine and together they are not.

Expected changes

Most privilege changes are legitimate. Your IT lead adds an admin on a Tuesday afternoon. A deploy bot rotates keys on a schedule. The point is to surface the ones that are not routine. If an admin grant is routine in office hours, the same grant at 3 a.m. stands out. When your system changes, the agent updates the sensor.

You can also ask support for a specific sensor in plain words, for example "tell me when anyone is granted an admin role". sazabi signals list --type sensor lists the sensor signals.

How you get told

A new issue sends an Issue triggered notification to in-app, email, Slack DM or SMS, and to shared Slack or Microsoft Teams channels when a delivery rule matches severity, component or owning team. Audit-related issues often belong to a security owner, and a rule on severity can reach that person without alerting everyone.

Ask the agent follow-up questions, such as what else the new admin touched. sazabi issues agent-prompt hands the fix to a coding agent. Resolve, ignore or mute the issue from the dashboard, Slack, Teams or the CLI. A recurrence while the issue is open or ignored folds into it.

What it needs

Audit events in your logs. For your application, send them through OpenTelemetry or another source on the integrations list. For cloud accounts, AWS CloudTrail carries IAM and role changes. If your admin tool keeps its audit trail somewhere you do not forward, the sensor has nothing to question.

What it does not cover

• Reversing a change. Sazabi does not revoke a role or delete a key.
• Changes your systems do not log, or that happen in a vendor you cannot forward audit events from.
• Whether a grant was approved. It sees events, not your ticketing or approval history.
• Access that looks ordinary in your logs but is unusual for the person, which is outside this detection.

For the audit events to watch and how to filter expected actors, see the privilege escalation detection guide. The glossary has a short entry on privilege escalation. Issue volume is metered; see pricing.

Grants that follow a takeover are often preceded by authentication anomalies, and followed by unusual data egress.