How does an AI agent authenticate to an MCP server?

An agent authenticates to a remote MCP server with an OAuth access token, sent as a bearer credential on every request. It gets that token through a flow the server itself starts: the first request without a token is answered with 401, and the answer says where to look next. Everything the agent may do afterwards is decided by what that token was issued for.

That is the mechanism. The useful question for anyone who owns the product behind the server is a different one: which credential do you revoke, and what does it stop? In a setup like DeployIt's there are three, and they do not behave alike.

We read the MCP authorization specification (revision 2026-07-28) on 30 September 2026 before writing this. Where we state what a server "must" do, it comes from there. Where we describe our own server, we stick to what our public pages already say.

The flow, in the order things happen

Authorization is optional in the specification. When a server over HTTP supports it, it should follow the specification. A server that answers questions about a private product has every reason to.

1. The client calls the server with no token. The server replies 401 Unauthorized with a WWW-Authenticate header carrying the address of its protected resource metadata.
2. The client reads that metadata, which names the authorization server, then reads the authorization server's own metadata to find its endpoints.
3. The client gets an identity. The specification prefers a client ID that is an HTTPS URL pointing at a metadata document. Dynamic registration is still accepted, but the specification now labels it deprecated. A pre-registered client works too.
4. A person authorizes, in a browser. The client uses PKCE and sends a resource parameter naming the exact server the token is meant for.
5. The client receives the token and sends Authorization: Bearer … on every later request. Never in the URL.

Two rules from that page deserve to be quoted, because they carry most of the security. The server must check that a token was issued for it as audience. And it must not accept or pass along any other token.

In plain terms: a token stolen from one server is worth nothing at another. And a server that forwards your token to a third party is out of specification, not merely rude.

Three credentials, three different revocations

Here is the part the specification cannot settle for you, because it lives in the deployment. The specification even says the authorization server's implementation is out of its scope.

Look at the first row before anything else. It is the one that never leaves the server. The agent asking about your product never holds a GitHub credential, which is why the safe access model can call the connection read-only and revocable at any time without a caveat about copies in circulation.

The second row is the one you use daily. A support platform is retired, a contractor's engagement ends: you cut that one requester, and nobody else notices.

The third row is the least visible and the most often forgotten. A token has a life; the authorization it came from has another. Cutting one and leaving the other is a half-measure you find out about later.

An example, labelled illustrative

A consultancy connects a client's support agent to the product expert of a project. Three months later the engagement ends. What should happen, in order:

• the agent's credential is withdrawn, so on a well-behaved server its next call meets a 401 and the flow leads nowhere;
• the repository connection stays, because two other requesters still depend on it;
• nothing was ever copied to the agent's side, so there is no repository token to hunt for.

Reverse the order of the last two and you have an outage or a leak. The table exists to keep you from mixing them.

What we do not claim

Precision has a cost, and here it is. We do not describe DeployIt's token lifetimes, its refresh rules, or its exact revocation timing, because our public pages do not state them and the server is in early access. What they state is narrower: one MCP server per project, a read-only GitHub connection, and an endpoint with credentials that we hand over during onboarding.

Ask for the rest before you rely on it. It is the same grid you would use on any vendor.

The questions to put to any server

Five, short enough to fit a call:

• Does an unauthenticated request get a 401 with a pointer to metadata, or a silent 200?
• Is the token bound to this server as audience?
• Can one requester be cut without touching the others?
• Does any credential to the underlying source ever reach the requester?
• What survives a revocation: the token, the grant, or both?

A server that answers the first two on paper and the last three in practice is worth connecting to a support agent. One that answers none of them is a shared password with extra steps.

Where this sits

This article covers the mechanism. The access model explains why a read-only, per-project server is the right shape, and calling the server as an API shows what the caller receives once it is authenticated. For the official server's own setup, see the GitHub MCP server guide.

If you would rather wire this into your support agents with us, the design partner program for our MCP server is open. The server is in early access, and DeployIt is free during early access; paid plans arrive in January 2027.