Grant access to AlertZero
Give each person on your team only the AlertZero access their work needs, whether they view AlertZero, approve or decline proposed actions, or set up Workers.
Most AlertZero access comes from the AlertZero, Proposed Actions, and Agentic Investigations Kibana privileges. A predefined role already includes these privileges, so it's the quickest way to give someone access. To grant narrower access, build a custom role with the privileges for each job.
To approve an action, a role also needs the privileges to run that action.
In Serverless, assign one of these predefined roles:
| Predefined roles | What they can do in AlertZero |
|---|---|
| - Admin | - Everything, including turning Workers on or off and changing their settings |
| - Editor - SOC manager - Tier 3 analyst - Rule author - Detections admin - Platform engineer |
- Approve or decline proposed actions - Manage investigations - Manage escalations - Start onboarding, but not turn on Workers |
| - Tier 1 analyst - Tier 2 analyst - Threat intelligence analyst - Endpoint operations analyst - Endpoint policy manager |
- Approve or decline proposed actions - Manage investigations - Manage escalations |
| - Viewer | - View AlertZero without making changes |
On Elastic Stack, assign one of these built-in roles:
| Built-in role | What they can do in AlertZero |
|---|---|
| superuser | - Everything, including turning Workers on or off and changing their settings |
| editor | - Approve or decline proposed actions. To approve host isolation and process actions, they also need the Elastic Defend privileges. - Manage investigations - View escalations, but not open, assign, or link them - Turn on AlertZero in a space and start onboarding, but not turn on Workers |
| viewer | - View AlertZero without making changes |
To create the role, refer to Kibana role management.
Every analyst needs the privileges in the first row. Add the privileges in the other rows for each task the analyst does.
| To let someone | Add |
|---|---|
| View AlertZero, its Watch settings, and the Proposed actions page | AlertZero: Read and Proposed Actions: Read |
| Approve or decline proposed actions | Proposed Actions: All, plus the privileges for each action they approve |
| See impacted entities, and filter proposed actions by entity | Agentic Investigations: Read |
| Open investigation details or chats | Agent Builder: Read |
| Assign, close, or reopen investigations | Agentic Investigations: All, or its Manage investigations sub-feature privilege |
Add the privileges for each task the analyst does with escalations.
| To let someone | Add |
|---|---|
| View escalations | Agentic Investigations: Read, or its View escalations sub-feature privilege |
| Open escalation details or chats | Agent Builder: Read |
| Create an escalation, add an investigation to one, or change who is assigned to one | Agentic Investigations: Manage escalations sub-feature privilege, which All doesn't include |
| Close an escalation | Agentic Investigations: Manage escalations and Manage investigations sub-feature privileges. To close an escalation that has pending proposed actions, also add Proposed Actions: All. |
An approved action runs as the person who approved it, so each analyst needs the privileges for the actions they approve. Without them, the action fails.
| Action | Privileges |
|---|---|
| Close alerts | Alerts: All |
| Create, edit, install, or turn on a detection rule, or add a rule exception | Rules and Exceptions: All |
| Isolate a host | Security: All, with the Elastic Defend sub-feature privileges Host Isolation and Response Actions History |
| Kill or suspend a process | Security: All, with the Elastic Defend sub-feature privileges Process Operations and Response Actions History |
A detection rule that an analyst creates, changes, installs, or turns on by approving an action runs with that analyst's privileges. The same rule authorization applies after any rule edit.
At Supervised autonomy, a Worker approves its own proposed actions, and they run as the Worker's service account. Analysts don't need the action privileges for those actions.
To set up AlertZero in a space, an administrator needs the privileges in the first three rows. Add the privileges in the other rows for each task the administrator does after setup.
| To let someone | The role needs |
|---|---|
| Turn on AlertZero in a space | Advanced Settings: All |
| Start AlertZero onboarding | AlertZero: All |
| Turn Workers on or off | AlertZero: All, the manage_security cluster privilege, and Workflows: Update and Update managed workflows, which All doesn't include. Each Worker runs as a managed workflow. |
| Change the models the Workers use | The privileges for Feature Settings |
| Edit Worker settings, such as autonomy | AlertZero: All and the manage_security cluster privilege |
| Run Workers on demand from Workflows | Workflows: Execute |
| View Worker execution history | Workflows: Read, or its Read Workflow Execution and Read managed workflow execution sub-feature privileges |
AlertZero uses the manage_security cluster privilege to create a service account for each Worker. The privilege also lets anyone who has it manage users and roles for the whole cluster, so don't grant it only for AlertZero. Instead, have an administrator who already has it set up the Workers.
Each Worker runs as its own service account with a built-in role of the same name, such as alertzero_alert_triage for Alert Triage. In Serverless, the role name starts with an underscore, such as _alertzero_alert_triage. You can't edit or delete these roles.
AlertZero creates the service accounts with the privileges of the person who turns on the Workers.