# Agent auth, twice

> I built MCP servers with OAuth 2.1 at two companies before mid-2026. Notes from doing the same thing twice.

FIELD NOTES · JUL 2026 · 4 min read · by Noah Mitchem

The first time, nobody asked for it. At Real Hire I was building a hiring
platform, and by 2025 agents were already making my own work faster. It
seemed obvious they'd soon be users of every product I cared about, so I
decided ours should be ready before anyone thought to ask. I built an MCP
server so an agent could do real work with your account: pull your profile,
query open jobs against your strengths and preferences, check on your
applications. Then, because "paste your API key into a config file" is not
a door you offer real users, I put a proper OAuth 2.1 flow in front of it:
PKCE, scoped tokens, a consent screen that says in plain words what the
agent may touch. The consent copy said "Claude wants to access your Profile
and Applications." Writing that sentence honestly is half the security
model.

The second time it was my day job. At Mesa, a San Francisco systems startup
rebuilding version control for AI agents, I owned a few surfaces: the
Python SDK, an AI code reviewer, my first real systems work inside a Rust
filesystem. The MCP server is the one that taught me the most. Twenty-two
tools, stateless, an OAuth 2.1 authorization server in front, cancellation
threaded end to end so an agent that gives up mid-request doesn't leave
work running behind it.

Here's what doing it twice taught me. The best test harness for an
agent-facing product is an agent. My loop was to point a coding agent at
the server cold. No docs, no system prompt, nothing but the tools. Then
watch. What does it reach for first? Where does it stall? Which tool does
it use in a way I never predicted, and which "obviously useful" tool does
it never touch? You can interview human users. Agents you can just run,
again and again, at almost no cost. It's the fastest product feedback I've
ever had.

That loop forces a discipline: the instructions have to live inside the
tools. If the agent needed context I hadn't shipped in a tool name, a
description, or an error message, I treated that as a bug in the surface,
not a gap in the prompt. A human gets onboarding, tooltips, a support
channel. An agent gets your tool list, once. Either the product explains
itself at the boundary or it doesn't work.

Auth stops looking like plumbing, too. A human forgives a clunky login once
a month. An agent hits your authorization surface every session. For
agent-facing products, the door is the product. "Connects instantly from
any client" versus "requires a support ticket" is the difference between
being infrastructure and being a demo.

If you're adding agent access to your product this year: the specs are
good. Read them before the blog posts. Then hand what you built to an agent
with no extra context, and watch. It will tell you what your product
actually is faster than any user ever has.

---

Source: https://noahmitchem.com/notes/agent-auth-twice — this is the Markdown representation of that page, served from the same URL to clients that send `Accept: text/markdown`.
Site index for agents: https://noahmitchem.com/llms.txt · Full site text: https://noahmitchem.com/llms-full.txt · Contact: noah@noahmitchem.com