MCP Authentication
Every server's auth, handled for you.
Meandr authenticates in both directions. Your agents present one token to Meandr; Meandr presents whatever each tool server expects on the other side — a bearer token, an API key, OAuth, mutual TLS, AWS SigV4. You set it once. Your agents hold nothing.
Every server wants a different credential.
One server takes a bearer token, the next an API key in a header, another signs requests with AWS SigV4. The one thing they have in common is that your agents should not be the ones holding any of it.
A different key for every door
Each server has its own idea of what a valid request looks like. Wire them up one agent at a time and the same secret ends up copied into config after config.
Agents shouldn't hold secrets
A long-lived credential sitting in an agent's environment is a credential you can't rotate cleanly, can't scope, and can't take back the moment something looks wrong.
The hard cases need real work
OAuth means minting and refreshing tokens; AWS SigV4 means signing every request. Done by hand, each is a small service you now own and have to keep alive.
Upstream
Nine ways a server can ask to be trusted. Meandr speaks all of them.
Bearer tokens, API keys in a header or a query string, basic auth, OAuth (client-credentials and authorization-code), mutual TLS, AWS SigV4, or no auth at all. You pick the method once per server and Meandr presents the right credential on every call.
AWS SigV4 — no proxy, no sidecar
AWS-hosted MCP servers want SigV4-signed requests. Meandr signs each one server-side, over the exact bytes it sends — so an AWS server connects out of the box, with nothing extra for you to run. This is live today, proven against a real AWS managed server.
OAuth, minted for you
For servers behind OAuth, Meandr holds the client credentials, gets the access token, and keeps it fresh. Your agents just call — they never see the exchange.
Keys, headers, mTLS — same setup
API keys, custom headers, basic auth, and mutual-TLS client certs all go in the same place, once. Meandr stores what the server needs and attaches it on the way out.
Downstream
Your agents authenticate to Meandr — nothing else.
Point an agent at one Meandr endpoint and give it one identity. However your client signs in, the server credentials stay on Meandr's side.
A bearer token for code
Claude Code, the Messages API, or anything that can send a header gets one agent key: an Authorization: Bearer token that identifies the agent. Rotate it or revoke it in the dashboard without touching a single server.
One-click OAuth for Claude Desktop
Claude Desktop can't paste a token — so Meandr is an OAuth authorization server. You add the Meandr URL, click connect, sign in, and pick the agent. No token to copy, nothing to keep in sync.
The credential never reaches your agent.
A server's secret goes in once and stays put. Meandr uses it to sign requests; it never hands it back — to an agent, or to you.
Sealed at rest
Every server credential is sealed with AES-256-GCM under a KMS-wrapped data key — one key per environment. It's unsealed only to sign a request, then gone from memory.
Write-only by design
You can save a credential or rotate it, but the dashboard and the API never read it back. The config you can see — which header, which region — is kept separate from the secret you can't.
Access, not secrets
An agent presents its own token to Meandr; Meandr attaches the upstream credential on the way out. The two never meet, so nothing agent-side needs the server's keys.
Questions you'd ask anyway.
Which auth methods can Meandr use to reach a server?
Do my agents ever see a server's credentials?
How does Claude Desktop connect if it can't hold a token?
Do I need a proxy or sidecar for AWS SigV4?
Does routing through Meandr mean changing my agent's code?
Let Meandr hold the keys, so your agents don't.
Point your agent at one endpoint and you're governed in minutes — no code changes, no proxy to run.
Get startedQuestions? Email us