Describe a specific use case for the feature:
Interaction with ML during alert execution, using the alert's permissions (role/licensing authorization).

Describe the feature:
The ML Plugin's contract exposes a number of useful services for consumers to use.

However, all of these service providers require an ApiCaller argument (i.e. a cluster client) to function, and this client must define ml-specific paths in order to function.

As a temporary workaround for 7.7, I exposed the ML client as part of ML's contract. This provides consumers with a ml-path-enriched client to pass to those services. Additionally, it can be used in a request handler to make calls on behalf of the current user by using the asScoped method.

However, there is one major limitation with this approach, and that's alerting. Alerts execute independent of a request (so we cannot use asScoped) but execute on behalf of the user that created them. To support that, alerts are provided a cluster client scoped to their creator (via an API key mimicking their permission). However, due to the paths requirement mentioned above, we cannot use said client with ML services, and are left with the following options:

1. Write custom queries agains ML indices using the scoped client
   • data access is respected, but ML logic is leaked
   • SIEM currently does this to query anomalies during ML Rule execution
2. Use ML services with mlClient.callAsInternalUser)
   • ML logic is not leaked, but neither is data access respected
   • SIEM currently does this to check jobs' status during ML Rule execution