AWS SigV4 without a proxy

AWS hosts MCP servers, and reaching one is usually 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 deploying 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 sign-in method for the servers you add. 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.

How AWS SigV4 signing works

The secret key itself is never sent. Instead, the client proves it holds the key by using it to sign each request. For every request, the client:

  1. Builds a canonical request. The method, path, query string, the headers it chooses to sign and a SHA-256 hash of the body, written out in a fixed format.
  2. Builds a string to sign. The timestamp, the credential scope (date, region and service) and a hash of the canonical request.
  3. Derives a signing key. A chain of HMACs over the secret key, the date, the region and the service, so the key only works for that day, region and service.
  4. Signs and attaches. The signature goes into the Authorization header, together with the access key ID and the list of signed headers.

A signed MCP call to AWS’s managed MCP server looks like this:

POST /mcp HTTP/1.1
Host: aws-mcp.us-east-1.api.aws
Content-Type: application/json
X-Amz-Date: 20261022T091500Z
Authorization: AWS4-HMAC-SHA256
    Credential=AKIAIOSFODNN7EXAMPLE/20261022/us-east-1/aws-mcp/aws4_request,
    SignedHeaders=content-type;host;x-amz-date,
    Signature=4f2c8e1a…b91d

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "aws___search_documentation",
    "arguments": {
      "search_phrase": "S3 bucket names"
    }
  }
}

The body isn’t in the header, but its hash is part of the canonical request, so the signature covers every byte of it, including the tool name and its arguments.

Two details matter for MCP. AWS rejects a request whose timestamp is more than about five minutes off, so a signature can’t be made once and reused. And every MCP message is its own HTTP request, so every tool call needs a fresh signature made with the secret key.

Why MCP clients can’t sign it themselves

Claude, Cursor and most other MCP clients sign in with OAuth or send a fixed header. Neither fits SigV4, which needs the secret key at hand to sign each request again. AWS’s answer is MCP Proxy for AWS, a small program that runs next to the client on your machine, reads your local AWS credentials and signs each request before it leaves. AWS’s managed MCP server also offers a browser sign-in, but that session belongs to one person and ends after 12 hours at most.

That works for one developer at a desk. It gets harder for a team:

  • Every person installs and updates the proxy, and every laptop holds AWS credentials.
  • Agents that run in the cloud or overnight have no laptop to run the proxy on.
  • Each client is set up on its own, so nobody sees in one place which agent called which AWS tool.

AWS’s managed MCP server isn’t the only place this comes up. MCP servers you host on Amazon Bedrock AgentCore Runtime use SigV4 by default, and so does any server behind API Gateway with IAM authorization.

Why a naive relay cannot do this

The obvious fix is a relay in the middle: the client signs, and the relay passes the request on. That breaks as soon as the relay is a real gateway, because a gateway changes requests on the way. It lets you give a tool a different name for your agents and maps it back to the name the server knows. It keeps resources from different servers apart by giving each server its own prefix. Every change like that alters the body.

SigV4 exists so that an altered body is rejected. A signature made before the gateway touched the request no longer matches what reaches AWS. A relay that changes nothing keeps the signature intact, but then it can’t do any of the work a gateway is for. A relay that changes the request breaks the signature. Either way, you’re stuck.

Sign the bytes you actually send

Meandr gets out of this by doing the signing itself, as the very last step. It reads the whole request before passing anything on, because it checks your policies against the complete call rather than a partial stream. Then it makes its changes, and only then calculates the SigV4 signature over the exact bytes it’s about to send. The client never signs anything, and the AWS key never leaves Meandr.

Meandr reads the request, changes what it needs to, and signs the result. A client can’t do that, because it can’t know in advance what the gateway will change.

Connect an AWS MCP server in Meandr

In the dashboard, an AWS server is added with the same form as any other:

  1. Open Servers and click Add MCP server.
  2. Paste the endpoint, for example https://aws-mcp.us-east-1.api.aws/mcp for AWS’s managed MCP server.
  3. Choose AWS · SigV4 and set the service and region. For AWS’s managed MCP server, the service is aws-mcp. Other SigV4 endpoints use their own service name, such as execute-api for API Gateway.
  4. Paste the access key ID and secret access key of an IAM user.

Meandr reads the server’s tools and you choose which ones your agents can use. Agents call them through the workspace connection URL with their own Meandr key. They never see the AWS key or the signature. Meandr keeps the key encrypted and uses it only to sign requests to that server.

On the AWS side, create a separate IAM user for Meandr and give it only what your agents need. Requests that come through AWS’s managed MCP server carry the aws:ViaAWSMCPService condition key, so you can write a policy that treats agent traffic differently, for example by denying deletes that arrive through MCP.

Tested against AWS’s managed MCP server

We tested this against AWS’s own managed MCP server with a real IAM user. About 240 tool calls went through Meandr over SigV4, and none of them failed because of Meandr. Responses as large as 123,000 characters arrived whole, and the same request sent ten times came back identical every time. The only errors we saw came from AWS itself, and Meandr reported them as AWS’s errors.

One of nine ways to authenticate

SigV4 is the hardest sign-in to handle without a shim, which is why it gets its own page. It’s one of nine options in the same Add MCP server form: none, bearer token, custom header, HTTP basic, OAuth client credentials, OAuth sign-in, mutual TLS, query string and AWS SigV4. Whatever a server expects, your agents never hold its credential. Meandr signs in for them.

The AWS MCP SigV4 page shows each step of connecting an AWS MCP server in the dashboard.

To see where signing fits in the bigger picture, read what an MCP gateway is and how it handles a session between your agents and your servers.