[dashboard-data-scope] High-severity unscoped Elastic Agent dashboard controls and suppressed SVR00002

## Findings

### 1. Elastic Agent dashboard uses global `logs-*` / `metrics-*` data views for live controls and Lens sources

**Dashboard**: `packages/elastic_agent/kibana/dashboard/elastic_agent-02117980-6082-11f0-89d2-bb7ceae5af7f.json`

**Locations**
- Control definition with no dashboard-level scoping filter: `:56-63` (`"filter": []`, empty query)
- Control fields: `:16-31` (`agent.name`, `filebeat_input.id`) and `:40-46` (`filebeat_input.input`)
- Control data-view references:
- `:1812-1815` → `"name": "controlGroup_1b4d...:optionsListDataView"`, `"id": "logs-*"`
- `:1817-1824` → `"name": "controlGroup_59c3...:optionsListDataView"`, `"id": "metrics-*"`
- Lens datasource references:
- `:1762-1809` multiple `"id": "metrics-*"`
- `:342` / `:567` / `:792` / `:1017` / `:1237` / `:1502` (`"currentIndexPatternId": "metrics-*"`)

**What is wrong**
This dashboard belongs to `elastic_agent`, but its controls and Lens panels use global wildcards (`logs-*`, `metrics-*`) as active data sources instead of package-scoped data views.

**Why it matters (high severity)**
Any cluster with multiple integrations installed will populate control dropdown values from unrelated integrations. That makes filtering misleading on first open (not just after user edits), and can mix unrelated data into the dashboard experience.

**Correct scoped pattern(s)**
From package data stream manifests:
- `packages/elastic_agent/data_stream/filebeat_input_metrics/manifest.yml` → `dataset: elastic_agent.filebeat_input` (`type: metrics`)
- `packages/elastic_agent/data_stream/filebeat_input_logs/manifest.yml` → `dataset: elastic_agent.filebeat_input` (`type: logs`)

Expected scoped patterns:
- `metrics-elastic_agent.filebeat_input-*` (for this dashboard’s metric controls/panels)
- `logs-elastic_agent.filebeat_input-*` only if a logs-backed control is intentionally required

### 2. `SVR00002` is suppressed for `elastic_agent` without rationale

**Location**: `packages/elastic_agent/validation.yml:1-4`

```yaml
errors:
exclude_checks:
- SVR00002
```

**What is wrong**
The dashboard scope validator (`SVR00002`) is excluded with no explanatory comment, while the package contains an active unscoped dashboard issue.

**Why it matters (high severity)**
This suppression hides exactly the class of regression that leaks cross-integration data scope to users.

**Regression context (high-traffic package history)**
- `dcffec3453` — `[elastic_agent] Add 10 remaining input dashboards (#14690)` (introduced this dashboard file)
- `e322c1ce17` — `Correct dashboard links (#18410)`

## Stale `indexPatternId` references
No new high-severity stale-ID finding is included here; currently tracked open issues already cover those packages:
- #18065
- #18200

## Coverage
- Total dashboards scanned: **1282**
- Dashboards containing `"logs-*"` or `"metrics-*"`: **1191**
- Confirmed new high-severity findings in this report: **1 dashboard / 1 package**

## Suggested actions
- [ ] Replace global wildcard control and Lens data-view references in `elastic_agent-02117980-6082-11f0-89d2-bb7ceae5af7f.json` with scoped `elastic_agent` data views.
- [ ] Re-enable `SVR00002` in `packages/elastic_agent/validation.yml` (or add an explicit, justified temporary exception with owner and removal criteria).
- [ ] Add/extend dashboard validation checks to prevent wildcard control data views (`controlGroup_*:optionsListDataView`) in package dashboards.

---
[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/25158589235)

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