# Kibana “Managed API keys” can be hidden/misclassified by editing metadata.managed (UI + Dev Tools)

**URL:** <https://discuss.elastic.co/t/kibana-managed-api-keys-can-be-hidden-misclassified-by-editing-metadata-managed-ui-dev-tools/384407>\
**Category:** Kibana\
**Tags:** elastic-stack-monitoring, elastic-stack-security\
**Created:** [January 7, 2026, 10:47am UTC](https://discuss.elastic.co/t/kibana-managed-api-keys-can-be-hidden-misclassified-by-editing-metadata-managed-ui-dev-tools/384407 "2026-01-07T10:47:20Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bolto](https://avatars.discourse-cdn.com/v4/letter/b/c0e974/32.png) [@Bolto](https://discuss.elastic.co/u/Bolto)\
**Post date:** [January 7, 2026, 10:47am UTC](https://discuss.elastic.co/t/kibana-managed-api-keys-can-be-hidden-misclassified-by-editing-metadata-managed-ui-dev-tools/384407/1 "2026-01-07T10:47:20Z")

</div>

Hi Elastic team/community,

While reviewing **API Keys** in Kibana, I noticed that the flag used to identify **Managed API keys** (created/used by Kibana background tasks) can be **overwritten by a user** by editing the API key **metadata**. This can cause keys to be **misclassified** or **hidden** when operators rely on “managed vs non-managed” filtering in the Kibana UI.

Elastic docs describe **Managed API keys** as “created and managed by Kibana to run background tasks.” (refer to [Elastic](https://www.elastic.co/docs/deploy-manage/api-keys/elasticsearch-api-keys))  
At the same time, the **Update API key** API explicitly allows updating metadata and states that new metadata **fully replaces** existing metadata. (refer to [Elastic](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-update-api-key?utm_source=chatgpt.com))  
Also, metadata is arbitrary and only keys starting with `_` are reserved for system usage. (refer to [Elastic](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-create-api-key?utm_source=chatgpt.com))

### Why this matters

In practice, admins often filter out “managed” keys because they assume those are system-generated and not something to review. If a user can set `metadata.managed: true` (or remove/flip it), then the “managed” label/filter becomes **user-controlled** , which can lead to **operational blind spots** during reviews.

### Steps to reproduce (what I did)

1. Go to **Stack Management → API Keys**.

2. Create an API key setting the metadata field `managed` to `true`

3. Observe that the key’s “managed-ness” and visibility changes when filtering/searching based on `metadata.managed`.

### Expected behavior

Either:

- Kibana should **not rely on user-editable metadata** to classify “Managed API keys”, or

- Kibana should **prevent editing** the field that controls “managed” classification (or warn loudly), or

- Managed-ness should be based on an **immutable/system-controlled attribute** (or a system-reserved metadata key) rather than a plain `metadata.managed` key.

### Environment

- Deployment: Elastic Cloud Hosted

- Stack version: [**v 9.2.1**]

- Role/privileges used: [e.g., manage\_api\_key / manage\_own\_api\_key]

### Questions

1. Is `metadata.managed` **intended** to be the source-of-truth for Kibana’s “Managed API keys” filter?

2. If yes, is it expected that a user can set/unset it and affect classification?

Thanks!