[dashboard-data-scope] High-severity dashboard data-scope regressions in Azure OpenAI, AWS ELB OTEL, and Proofpoint

## Findings

### 1. Over-broad dashboard data sources leak cross-integration data

#### 1.1 Azure OpenAI dashboards use global `logs-*`/`metrics-*` as active data sources

**Locations**
- `packages/azure_openai/kibana/dashboard/azure_openai-8b09a72a-8317-4ec5-aafe-4b7d3833dcc0.json:15,33,51,199,208,240,288,297,331`
- `packages/azure_openai/kibana/dashboard/azure_openai-21d9a0d0-e6a0-4b34-bc6d-ce6560a1dab3.json:15,34,52,207,337,346,375`
- Scoped datasets available in package:
- `packages/azure_openai/data_stream/logs/manifest.yml:1-3`
- `packages/azure_openai/data_stream/metrics/manifest.yml:1-4`

**Evidence**
- Control panels use global data views: `"dataViewId": "logs-*"` and `"dataViewId": "metrics-*"`.
- Lens state and refs use global data views: `"currentIndexPatternId": "logs-*"`, `"indexPatternId": "logs-*"`, `"indexPatternId": "metrics-*"`, and refs with `"id": "logs-*"`/`"id": "metrics-*"`.

**What is wrong**
Dashboard controls and visualizations query global index patterns rather than integration-scoped Azure OpenAI streams.

**Why it matters**
Users with multiple integrations installed will see mixed data from unrelated packages in Azure OpenAI dashboards, making filtering and interpretation unreliable.

**Suggested fix**
Replace global sources with package-scoped patterns derived from package datasets (e.g., `logs-azure_openai.logs-*` and `metrics-azure.open_ai-*`, or equivalent package-installed scoped data views).

#### 1.2 AWS ELB OTEL dashboard uses global `logs-*` in controls and ESQL queries

**Locations**
- `packages/aws_elb_otel/kibana/dashboard/aws_elb_otel-918bae2f-9268-46da-acac-7f4029ca0bfa.json:14,32,43,47,120,130,201,212,216`
- Dataset declared by package: `packages/aws_elb_otel/manifest.yml:23`

**Evidence**
- Control panel `dataViewId` is `logs-*`.
- Multiple queries are `FROM logs-*`.
- Ad hoc data view title is `logs-*`.

**What is wrong**
The dashboard source is not scoped to the package dataset (`aws.elbaccess.otel`).

**Why it matters**
Panels will include unrelated logs from other integrations, causing immediate user-visible data contamination.

**Suggested fix**
Use scoped data source patterns for this package dataset (for example `logs-aws.elbaccess.otel-*`), and keep dataset filters aligned with that scope.

### 2. Stale static `indexPatternId` reference can break Proofpoint dashboard panels

**Locations**
- `packages/proofpoint_365totalprotection/kibana/dashboard/proofpoint_365totalprotection-848432d2-2f3b-4fd9-83fc-be07ab74407c.json:61,67,70,90,95,101,103,166,175`
- No package index pattern assets found under `packages/proofpoint_365totalprotection/kibana/index_pattern/*.json`

**Evidence**
- Panels hard-reference `"id": "689cbaca-105d-4237-88b4-661a103791fc"`.
- Lens state uses `"currentIndexPatternId": "689cbaca-105d-4237-88b4-661a103791fc"` and `"indexPatternId": "689cbaca-105d-4237-88b4-661a103791fc"`.
- `adHocDataViews` is `{}` (no inline fallback data view definition).

**What is wrong**
The dashboard depends on a static saved object ID that is not installed by this package.

**Why it matters**
In installations where that saved object does not exist, panels can show missing data source / broken visualization errors.

**Suggested fix**
Either ship a matching `kibana/index_pattern` asset with this ID, or migrate panels to package-scoped ad hoc data views / package-installed data view IDs.

### 3. `SVR00002` suppressions without rationale hide scope-validation failures

**Locations**
- `packages/azure_openai/validation.yml:2-4`
- `packages/elastic_agent/validation.yml:1-3`

**Evidence**
- Both files suppress `SVR00002` under `exclude_checks` without explanatory comment or linked tracking context.

**What is wrong**
Validation suppression removes guardrails for dashboard scope issues without documenting necessity or remediation intent.

**Why it matters**
Over-broad dashboard regressions can be knowingly carried forward with no audit trail, increasing recurrence risk in high-traffic packages.

**Suggested fix**
Add explicit suppression rationale with issue linkage and expiration/removal plan, or remove suppression after scoping fixes are applied.

## Suggested Actions

- [ ] Scope Azure OpenAI control and Lens data sources to package datasets (replace global `logs-*`/`metrics-*`).
- [ ] Scope AWS ELB OTEL dashboard queries and controls to package dataset(s), not `logs-*`.
- [ ] Replace or install valid data view references for Proofpoint dashboard (remove hard dependency on uninstalled static ID).
- [ ] Remove or document `SVR00002` suppressions with actionable remediation tracking.

## Audit Coverage

- Total dashboards scanned: **1189**
- Dashboards with confirmed high-severity findings: **4** (Azure OpenAI x2, AWS ELB OTEL x1, Proofpoint x1)

> [!NOTE]
>
> 🔒 Integrity filtering filtered 1 item
>
> Integrity filtering activated and filtered the following item during workflow execution.
> This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.
>
> - issue:elastic/integrations#unknown (`search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
>
>

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Sweeper: Dashboard Data Scope and Filter Integrity](https://github.com/elastic/integrations/actions/runs/23586765925)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
> - [x] expires on Apr 2, 2026, 9:41 AM UTC