[Entity Analytics][Leads generation] Improve error states for ES index-level permission denials

[abhishekbhatia1710]

Summary

This PR improves the error handling in the Lead Generation feature when Elasticsearch index-level permissions are missing. Previously, security_exception errors from ES were silently swallowed, resulting in either empty data responses (misleading 200s) or unhelpful 500 errors. After this change, those errors propagate as proper HTTP 403 responses with an actionable message.

---

Background

The Lead Generation feature stores leads in .entity-analytics.entity-leads-* indices. Two separate permission layers protect these APIs:

1. Kibana feature privileges (securitySolution + ${APP_ID}-entity-analytics) — enforced by the Kibana framework before the handler runs. Missing this results in a Kibana-level 403.
2. Elasticsearch index-level privileges — enforced by ES when esClient.asCurrentUser executes a query. Missing read/write access on the leads indices causes ES to return a security_exception with status 403.

Layer 1 was already correctly configured on all routes. Layer 2 was silently absorbed.

---

What was broken

In lead_data_client.ts, the findLeads, getStatus, and createLeads methods all had catch blocks that swallowed every error:

// findLeads (before)
} catch (e) {
  // checked only for index_not_found_exception; security_exception was also silently absorbed
  logger.error(`Unable to find leads due to error: ${e}`);
  return { leads: [], total: 0, page, perPage }; //  misleading 200 OK
}

A user without .entity-analytics.entity-leads-* read access would get back an empty list with a 200 OK instead of a 403 "access denied" response. For createLeads, the write would silently fail with only a log warning.

API flow before fix

GET /internal/entity_analytics/leads

returns { leads: [], total: 0 }   200 OK with empty data

---

API flow after fix

GET /internal/entity_analytics/leads
transformError -> HTTP 403
- > frontend useQuery onError → toast: "security_exception: indices:data/read/search (...)  
    is unauthorized for user [...]"

index_not_found_exception continues to be swallowed and returns an empty result, which is the intended behaviour before the indices are first created.

---

Testing steps (before fix)

1. Create a Kibana role with securitySolution feature access but no access to .entity-analytics.entity-leads-* ES indices.
2. Log in as a user with that role.
3. GET /internal/entity_analytics/leads — returns 200 { leads: [], total: 0 } instead of 403.
4. GET /internal/entity_analytics/leads/status — returns 200 { isEnabled: false, indexExists: false, ... } instead of 403.

Testing steps (after fix)

Same setup:
3. GET /internal/entity_analytics/leads -> 403 security_exception: indices:data/read/search is unauthorized
4. GET /internal/entity_analytics/leads/status -> 403 security_exception: ...
5. UI: toast notification displays the permission error rather than showing empty leads.

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-entity-analytics (Team:Entity Analytics)

[ymao1]

Testing steps (after fix)
Same setup:
3. GET /internal/entity_analytics/leads -> 403 security_exception: indices:data/read/search is unauthorized
4. GET /internal/entity_analytics/leads/status -> 403 security_exception: ...
5. UI: toast notification displays the permission error rather than showing empty leads.

Just wanted to check, I'm seeing the error toast but these routes still return a 200 because generate just returns an execution UUID and status returns the error within the status, which is then thrown in the UI. This ends up with the same result.

[ymao1]

LGTM. Works as described. Can we create a followup issue to maybe hide or disable the leads section if the user doesn't have access to the .entity_analytics-entity-leads index? Maybe disable the Generate button if they don't have write access (but still show the leads generated since they can read?

[abhishekbhatia1710]

Thanks for testing this @ymao1! You're right to flag the discrepancy let me clarify the two scenarios this PR addresses:

Scenario A — Direct read/write calls (what the HTTP 403 fix covers)

When a user directly calls:

• GET /internal/entity_analytics/leads → was 200 with empty data, now 403 HTTP
• GET /internal/entity_analytics/leads/status → was 200 with default values, now 403 HTTP
• POST /internal/entity_analytics/leads/dismiss/{id} → was silently swallowed, now 403 HTTP
• POST /internal/entity_analytics/leads/bulk_update → same as above

These are the routes where the HTTP 403 improvement applies.

Scenario B — Generate flow (fire-and-forget)

POST /generate always returns 200 immediately with an executionUuid, the actual pipeline runs in the background. This is by design and unchanged.

The improvement here is different:

• Before: createLeads silently swallowed the security_exception, the pipeline reported success, lastError stayed null, the UI showed nothing (silent failure)
• After: createLeads re-throws the security_exception, the pipeline's catch block captures it, lastError is set to the error message, the UI toast surfaces it

So what you observed , a 200 from status with lastError populated + a toast is exactly the correct post-fix behaviour for the generate flow.

I'll update the reproduction steps in the PR description to make this distinction clearer. Apologies for the confusion!

[kibanamachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: e863533

Failed CI Steps

• FTR Configs #125
• Serverless Detection Engine - Exceptions - Security Solution Cypress Tests #1

Metrics [docs]

✅ unchanged

History

• 💛 Build #435454 was flaky d8afcf2
• 💔 Build #434657 failed a936793

cc @abhishekbhatia1710

[kibanamachine]

Starting backport for target branches: 9.4

https://github.com/elastic/kibana/actions/runs/25117707078

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	9.4

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation