Authorization in experimental alerting system

Authorization in the experimental alerting system determines which user's privileges a rule uses when it runs and how those credentials stay current as your team changes. Use this page to understand how the API key model works, keep credentials current, and resolve authorization errors.

The experimental alerting system involves two execution contexts, each with its own authorization model.

A rule runs using an API key that was captured the last time the rule was saved. That key's privileges determine what data the rule can query.

When an action policy matches an alert episode and invokes a workflow, the workflow runs under its own stored API key, which belongs to the user who last saved the workflow. Action policy evaluation runs in a background dispatcher process and does not use a user's stored credentials.

When a rule runs, Kibana records the identity of the user whose API key authorized the execution. This identity appears in rule execution history, so you can audit which credentials each run used.

Workflows that are invoked by action policies record execution identity the same way as directly invoked workflows. For details, refer to Workflow authorization.

When you save a rule, Kibana creates an API key that captures your privileges and authorizes the rule's ES|QL query and writes to .rule-events. Workflow invocations use the workflow's own key, not the rule's.

To refresh the stored API key for future runs, save the rule again with the desired user, or toggle the rule off and back on. A rule retains its key when disabled. If the key is missing when you re-enable it, Kibana generates a new one using your current privileges.

The following table covers authorization errors that can cause a rule to fail. If an action policy or workflow produces authorization errors, refer to Workflow authorization.