Your AI agent doesn't need your API key: OAuth 2.1 for Elasticsearch MCP server authentication

Claude Desktop, Cursor or any MCP host can now connect to your Elasticsearch data with a one-time browser sign-in. OAuth 2.1 is now GA for the Agent Builder MCP server in Elastic Cloud Serverless. Instead of pasting an API key into a config file, your agent gets a short-lived token tied to your permissions. Every connection can be audited individually and revoked without affecting anything else on your account. Refresh tokens roll for 30 days, so you rarely need to sign in again. Org owners can see exactly who authorized which agents, and Agent Builder is the first Elastic surface using this model, with the rest of the Elastic API to follow.

Why OAuth is better than API keys for MCP server authentication

With OAuth, tokens are short-lived credentials that expire on their own, so a leaked token is a narrowing window rather than a standing grant. Every token traces back to an explicit consent: which user, which client, which time.

In contrast, an API key is a long-lived credential. It lives in a configuration file on the machine that runs the agent, working for whoever uses it until someone rotates or deletes it. That model is manageable for a CI pipeline you wrote and deployed for your team. It gets uncomfortable when the key is held by an AI agent that assembles its own requests, retrieves untrusted content that may contain injected instructions, and sometimes passes context to sub-agents.

The failure mode is familiar from every credential-leak postmortem: the key ends up somewhere it shouldn't (a log file, a prompt), and from that moment anyone who has the key can access everything its creator could. The audit trail doesn't help much: API key logs tell you that a key with a given name did something, but not who authorized the client that used it or when.

How to set up OAuth 2.1 for the Elasticsearch MCP server

Setup is a one-time step per project:

1. In your Elastic Cloud Serverless project, open Agent Builder → Tools library → MCP clients → Create MCP client (OAuth). This gives you a client ID and the MCP server URL.

2. Add the server to your MCP host. In Cursor or Claude Desktop, the configuration file entry looks like this:

{
  "mcpServers": {
        "kibana-mcp": {
          "command": "npx",
          "args": [
            "mcp-remote",    "https://<your-project>.kb.<region>.aws.elastic.cloud/api/agent_builder/mcp",
            "--static-oauth-client-info",
            "{\"client_id\":\"MYCLIENTID111\"}"
          ]
     }
   }
}

3. The first time the agent calls a tool, the host opens your browser on an Elastic Cloud consent screen. You sign in with your normal Elastic Cloud credentials and see what the agent is requesting access to.

4. Click Authorize. This creates an application connection between you, your machine, and your project, and Elastic Cloud issues the agent a short-lived access token.

From there, your agent has access to your project’s data. The mechanics are invisible. When the access token expires, the host refreshes it using a refresh token with a 30-day rolling expiry, so you are not re-authenticating every hour. If you stop trusting a connection, open the application connections page in Elastic Cloud and revoke the connection. Both tokens die immediately, and nothing else about your account changes.

The agent acts with the permissions of the user who consented. Calls to Agent Builder tools, such as ES|QL queries, Workflows, and Streams, are evaluated based on your role. If you want an agent with less access than your own, authorize the connection as a user with a tighter role, or keep using a scoped API key for that workload. 

How to manage and revoke MCP server connections in Elastic Cloud

Org owners can list every active application connection across an organization or a specific project: which MCP hosts were authorized, by whom, and when. Revocation is per connection, so cutting off one misbehaving agent does not disturb the authorizing user's account or any other integration. There is no shared credential to rotate and no blast radius beyond the one client.

This is the practical difference for teams. An OAuth app connection records who consented, to which client, and when. An API key log shows that agent-key-3 queried an index, but not who authorized that agent. 

What's next for OAuth authentication across the Elastic API

Agent Builder is the first Elastic surface behind OAuth, and the same authorization model will carry to the rest of the Elastic API surface, including Elasticsearch and Elastic Cloud management, as we work toward a single Elastic MCP endpoint.

To try it now, open Agent Builder in an Elastic Cloud Serverless project and create an OAuth client, or start with the documentation. If you don't have a project yet, you can start a free trial.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.