AI connectors in Kibana: 90+ data sources your agent can call

Agent Builder is available now GA. Get started with an Elastic Cloud Trial, and check out the documentation for Agent Builder here.

Kibana ships with more than 90 AI connectors. Slack, GitHub, Confluence and PagerDuty are in there, along with Gmail, Drive, Jira, Salesforce and Snowflake. Add one to your agent and it calls that service as a tool while it reasons. There is no integration code to write, and the data stays where it already lives. Your Elasticsearch index tells the agent what happened. The connectors tell it why, whether that turns out to be the pull request that changed a permission scope, the Confluence page on a known regression, or the Slack thread where someone first raised it. During an incident, that can save the first 30 minutes usually spent hunting for context.

A library of 90+ AI connectors 

Kibana ships with more than 90 connector specs, including Gmail, Google Drive, Google Calendar, Slack, GitHub, Confluence, PagerDuty, Jira, Salesforce, Datadog, and Snowflake: 

Each spec declares what data the connector can reach, how it authenticates, what actions it supports, and which of those actions agents can call as tools:

That last part makes this practical. The agent calls a connector action while it reasons, the same way it calls any other tool. There's no integration code to write or separate pipeline to maintain.

How AI connectors authenticate

Kibana Connectors handle OAuth and API keys, as well as bearer tokens. With Elastic's Auth Relay Service, users can authorize against Google or Slack without giving Kibana their credentials. The agent sees typed actions, and the spec handles everything underneath.

How an AI agent pulls context from outside your index

For example, take a product analyst asking an agent about customer engagement. The Elasticsearch index has events, sessions, cohorts, and conversion metrics, and the agent is good at querying it and writing Elasticsearch Query Language (ES|QL).

The question is What happened?, not What do the numbers show? The analyst wants to know why engagement dropped for the enterprise cohort in Q2 and what to do about it. The index data can't say. The answer is spread across four places:

• An email thread where a large customer flagged an onboarding problemA Google doc that describes a feature change that shipped in early Q2 

• A Slack discussion where the growth team debated a hypothesis and never settled it

• A calendar invite for the product review where someone chose to delay the fix

With Kibana Connectors, the agent can reach all of it. It searches the email, pulls the spec from Drive, reads the Slack thread, and checks the meeting records for what was decided and when. The analyst asks once, and the agent does the rest.

AI incident response: getting to root cause faster

Now let’s consider a security alert. The security information and event management (SIEM) flags unusual credential use and lateral movement, along with a spike in failed authentication from an internal service account. The raw telemetry is in Elasticsearch, so the agent can query it and correlate events. It can also find the affected hosts.

Finding the data is the easy part. The hard part is working out what happened. Which code change caused this? Was there a deployment just before the anomaly? What did the original design intend for the authentication flow? When did the on-call engineer get involved, and what have they already ruled out?

Elasticsearch holds the telemetry. The rest of the record sits in four other places:

• The pull request (PR) that added the permission scope is in GitHub 

• The design doc that says whether this is a bug or intended behavior is in Confluence

• The incident timeline is in PagerDuty 

• The team's current theory is in a Slack thread

With Kibana Connectors, the agent can collect that material while the engineer is still reading the alert. That saves the first 30 minutes of the incident, which are usually spent hunting for context.

Which identity should an AI connector use?

Identity gets messy once you leave Elastic. A Kibana user and a Google Drive login are different identities, even when they share an email address. When a connector calls an outside service, it has to establish who it's acting as. The right answer depends on whose data the agent is touching.

Personal data: connect as the user

Personal data (a Gmail inbox, Slack DM, or Drive folder, for example) calls for the individual's own identity. That's what makes the agent useful; it sees that person's private conversations and nobody else's. Connectors that support personal OAuth let each user authorize separately, so the agent acts with their permissions.

Organizational data: connect as a system account

Organizational data (such as a PagerDuty timeline, Confluence design doc, or shared GitHub repo) usually works better with a system account or API key. An admin configures authentication once, and nobody has to authenticate individually.

Most agents will end up with a mix.

Set up AI connectors in Kibana

Each AI connector you add becomes something your agent can call, so the setup is a one-time configuration rather than an integration project.

Open your agent in Kibana, and go to the tools configuration. Browse the connector library, and set up the data sources you need. Any connector you add is available to that agent while it reasons.

If you're starting from scratch, an Elastic Cloud trial gives you the full connector library in a hosted environment. The docs are in the Kibana Connectors reference.