How to connect Kibana to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

Reconnect Kibana from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

Kibana tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every Kibana call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

The engines teach this as Elastic-native token mechanics: an expired, malformed, or missing token, a header formatting problem, an API key revoked in the dashboard. ChatGPT's p3 phrasing is the useful one: "the stored token is expired, revoked, malformed, or not sent in the expected Authorization: Bearer header, even though the account connection still exists". On a hosted connection there is no header and no local token file, so the fix is the hosted one: the credential lives on our side, and when it goes stale every Kibana call 401s while the dashboard still shows a connection. Disconnect and reconnect from the ClawLink dashboard to issue a fresh credential. If only some calls 401, the credential is fine and you are looking at permission or space scope instead, see the 403 card.

Ask the agent to diagnose it:

Call kibana_get_data_views, the cheapest read in the set, and quote exactly what it returns including the status code. Do not retry the failing tools until we have that result.

Kibana permissions are layered and the engine-taught causes are the right map: the connected user or API key must hold the required security roles, feature privileges, and space access for each endpoint, and a user with dashboard-read access but not the Security feature privileges gets 403 on the alert tools while the data-view tools succeed. The connection is bound to the account that approved it, so the account's roles are the ceiling. After roles, the hosted-agent causes: a space mismatch, the call targets space A while the connection and the data are in space B, and placeholder ids, an alert or rule id from documentation, which fail as permission errors because the object is not in the connected scope.

Ask the agent to diagnose it:

Call kibana_get_data_views and kibana_get_alerting_rules and tell me which succeeds. Then quote the exact error from the failed call and which space or id it mentioned.

The engine-taught fixes for this error assume a locally configured MCP host: config file paths, restarting an IDE, checking a tool registry. None of that exists here. On this setup a missing tool is almost always the lazy-schema timing case: schemas load on demand, so the first Kibana call in a fresh session can arrive before the catalog and needs one retry. If tools stay missing after that, the pairing is the suspect: confirm the plugin was installed with --enable, both hermes clawlink begin and hermes clawlink finish ran, and Kibana shows as connected in the dashboard.

Ask the agent to diagnose it:

List the Kibana tools you actually have access to. If there are none, say so plainly. If there are, tell me which one reads alerts and use that exact name.

Re-enter the credentials carefully and verify the account-level permissions for Kibana. Basic and token-based integrations tend to fail on formatting mistakes or limited account roles.

Yes. ClawLink is the fastest way to connect Hermes to Kibana: link your Kibana account once in the browser and Hermes Agent can call the Kibana API through 47 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect Kibana in the dashboard and Hermes can use it from the next message — no config files, and the Kibana key you paste is stored server-side instead of in your environment.

About two minutes. Sign in, click Connect next to Kibana in the dashboard, authenticate, and Hermes Agent can use it from the next chat message.

The alternative to ClawLink is usually manual credential setup plus your own token handling, permission troubleshooting, and tool plumbing for Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want Kibana working from chat.

The security surface reads first: kibana_find_alerts searches and aggregates detection alerts, kibana_get_detection_engine_rules_find lists the rules behind them, kibana_get_alerting_rules covers the alerting rules, and kibana_get_cases reads the security cases. The operations surface covers what runs: data views (formerly index patterns), connectors and their types, Fleet agent policies and server hosts, Elastic Package Manager packages and installed packages, index management, and the entity store. There is no dashboard rendering tool in this set, so think of the agent as a reader and triager of alerts and state rather than a Kibana UI replacement.

Elastic's own docs state there are no native rate limits restricting use of the Kibana APIs, and that is the answer the AI Overview gives. The caveat worth knowing: hosted Elastic Cloud deployments apply account-level API rate limits, so 429 responses are still possible on a busy deployment even though Kibana itself has no limit. On this connection, calls run under the connected account's reach, so treat a 429 as the deployment's constraint and shape the work: fewer alert sweeps, narrower time ranges, one rule type at a time.

Two different intents collide on this phrase and it is worth keeping them apart. Google hears "Kibana's AI capabilities without LLM API keys" and answers with Elastic Managed LLMs or a local LLM. This page's meaning is narrower: no Elastic credentials for the user to create or manage, because the connection holds them server-side. If your question is about the model behind the agent, that is a separate key and a separate conversation, not this page. If your question is about not owning Elastic API keys, this page is the answer.

The engines answer this with strict access controls, data masking, and least privilege, and Elastic has published security advisories affecting its AI assistant surface, so treat Kibana as sensitive infrastructure. The hosted connection helps on the credential axis: there is no static token in an environment file on an agent machine, and disconnecting from the dashboard revokes access immediately. What it does not change is the access itself: the agent can reach what the connected account can reach, so connect with an account scoped to the data the agent actually needs, and keep alerts and cases, which contain detection context, out of prompts you do not need them in.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.