Skip to content

MCP and OAuth: giving agents access without giving away secrets

3 min read Fullmakt Team

  • mcp
  • oauth
  • agents
  • integrations

Two standards are quietly converging to make AI agents safer to connect to real systems: the Model Context Protocol (MCP) for how agents discover and call tools, and OAuth 2.1 for how they prove they’re allowed to. Used together, they let you give an agent access to your APIs without ever handing it a secret — and let you take that access away at any time.

What MCP gives you

MCP standardizes the connection between an LLM client and a set of tools. A server advertises the tools it offers and their input schemas; the client (the agent’s host) discovers them and calls them on demand. Instead of bespoke glue for every model and every integration, you expose one MCP server and any MCP-capable client can use it.

That’s powerful, but it raises the obvious question: when an agent calls a tool that hits a real API, whose authority is it acting under, and how is that proven?

What OAuth 2.1 gives you

OAuth is the web’s answer to delegated access: let a client act on a resource without sharing the underlying password or key. OAuth 2.1 folds years of hard-won security guidance into the baseline — PKCE everywhere, no implicit flow, exact redirect matching, short-lived tokens.

The MCP authorization spec leans on exactly this. An MCP server can act as a protected resource: unauthenticated calls get a 401 with a WWW-Authenticate header pointing at the protected-resource metadata, which in turn points at the authorization server. The client discovers the endpoints, runs a standard authorization-code-with-PKCE flow, and comes back with a bearer token scoped to what it’s allowed to do.

The result is an agent that holds a short-lived, scoped token instead of a copy of your credentials.

Where the two meet

Put concretely, a well-behaved agent connecting to an MCP server over OAuth does roughly this:

  1. Calls the MCP endpoint with no token and gets a 401 plus discovery metadata.
  2. Fetches the authorization server’s metadata.
  3. Runs an authorization-code + PKCE flow (registering dynamically if needed).
  4. Receives an access token scoped to specific tools.
  5. Calls tools with Authorization: Bearer <token> until it expires.

No secret is ever pasted into the agent. Access is bounded by the token’s scope and lifetime, and revoking the token cuts the agent off immediately.

Why a broker still matters

OAuth proves the agent is allowed in. It doesn’t, on its own, decide whether a specific call right now is wise, inject the real upstream credential, enforce a rate limit, or record what happened. That’s the job of a broker sitting behind the MCP server:

  • Token in, policy check. The bearer token identifies the agent principal; the broker decides if this tool, with these arguments, is permitted now.
  • Credential out, at the edge. The broker resolves the real upstream secret at call time and injects it into the outbound request. The model never sees it.
  • Everything recorded. Each call lands in a tamper-evident audit log.
  • Revocation that sticks. Disable the principal or rotate the upstream secret and every future call stops — no agent redeploy required.

MCP gives agents a clean way to discover and call your tools. OAuth gives them a standard, secret-free way to authenticate. A broker is what turns “the agent is authenticated” into “the agent did exactly what it was allowed to, and we can prove it.” Together, they’re how you let agents in without giving anything away.