AWS hosts MCP servers, and reaching one is not a matter of a bearer token. Every request to an AWS-hosted endpoint has to be signed with AWS SigV4 — AWS’s AWS4-HMAC-SHA256 scheme — using IAM credentials and the endpoint’s {region, service} pair. The signature is a digest computed over the request, including its body. Get one byte wrong and AWS rejects the call.
That single requirement is why teams usually end up standing up a Lambda shim or a local signing sidecar just to let an agent talk to an AWS MCP server. Meandr removes that step: aws_sigv4 is a first-class upstream auth type. You point Meandr at the AWS endpoint, give it IAM keys and the region and service, and it signs every upstream call for you. No proxy in front of the proxy, no sidecar, no code.
Concretely, that is one add-server call — the same shape any upstream uses. You name aws_sigv4 as the auth type, give the service and region to sign against, and hand over an IAM access key:
{
"endpoint": "https://<your-aws-mcp-endpoint>/",
"auth_type": "aws_sigv4",
"meta": { "service": "<service>", "region": "<region>" },
"secret": { "access_key_id": "AKIA…", "secret_access_key": "…", "session_token": null }
}Leave session_token null for a long-lived IAM user; set it when you sign with temporary STS credentials. Meandr stores the secret encrypted and uses it only to sign requests to this endpoint — the agent never holds it, and never sees the signature. That signing is the whole trick, and it is harder than it looks.
Why a naive relay cannot do this
Here is the part that makes it genuinely hard, and worth explaining. Meandr does not forward the agent’s bytes untouched. It rewrites the request body in flight, for reasons that are core to the product:
params.name— the agent’s alias for a tool is rewritten to the upstream’s real name;- resource URI prefixes — Meandr’s per-server namespacing slug is stripped;
_meta.progressToken— injected when the client sent none, so progress telemetry works.
Every one of those edits changes the bytes of the body. And AWS SigV4’s whole security property is that the signature covers those bytes. So any scheme where the client computes a signature and the upstream verifies it is fundamentally incompatible with a rewriting proxy: the moment the body is edited, the client’s signature no longer matches what arrives. A simple relay avoids that by not rewriting — but then it cannot do aliasing or namespacing, which is the point of a gateway. A rewriting relay breaks the signature. You appear to be stuck with one or the other.
Sign the bytes you actually send
Meandr escapes the bind because of how its request pipeline is built. It reads and holds the full request body before it forwards anything — it has to, in order to decide policy on complete data rather than guessing from a partial stream. A held body has a computable digest. So Meandr performs its rewrites first and then computes the AWS SigV4 signature over the exact bytes it is about to forward. The digest is taken after the rewrites, not before. The client never signs anything; Meandr is the signer, and it signs precisely what it sends.
That is the mechanism in one sentence: Meandr holds the body, rewrites it, and signs the result — which is exactly the sequence a client-side signer cannot perform, because it cannot anticipate the gateway’s edits.
It is verified, not theoretical
This path has been exercised against AWS’s own managed MCP server. Around 240 tools/call requests were routed through Meandr to that server over AWS SigV4 with a real IAM user, with zero gateway-attributable failures. Responses ran as large as 123,000 characters with no truncation or corruption, and ten identical requests came back byte-for-byte identical — the rewriting and signing path introduces no variance. Every error observed came from AWS itself, correctly attributed, never mislabeled as a gateway fault.
One of nine ways to authenticate
AWS SigV4 is the hardest upstream auth to do without a shim, which is why it leads — but it is one of nine methods Meandr offers in the same add-server dialog: none, bearer token, custom header, HTTP basic, two OAuth flows, mutual TLS, query-string, and AWS SigV4. Whatever a given server expects, the agent never holds the credential; Meandr signs in on its behalf.
Read the fuller story on the AWS MCP solution page, or start from what an MCP gateway is and how it terminates and forwards a session.