Skip to main content
Version: 1.9.0

Sign requests to MCP servers and A2A agents behind AWS IAM

Some MCP servers and A2A agents do not take a token. They check an AWS Signature Version 4 (SigV4) signature on each request instead. Amazon Bedrock AgentCore Gateway and AgentCore Runtime work this way when they use IAM authorization, and so do API Gateway APIs with IAM auth and Lambda function URLs.

From 1.9.0, DVARA signs every request to such a server or agent. You tell it the AWS region and service, and which AWS key to sign with.

What you set​

On the MCP server's page, or on an A2A agent's page with the AWS_SIGV4 auth scheme, fill in the AWS Signature Version 4 section:

FieldWhat it is
RegionThe AWS region the server or agent is in, such as us-east-1.
ServiceThe name the service signs for: bedrock-agentcore for AgentCore, execute-api for API Gateway, lambda for a function URL.
AWS CredentialsStored access key: the credential named in Credential Reference above. The gateway's own AWS identity: see below.

For a stored key, add a credential on the Credentials page and set Credential Reference to its name. Its value is the access key id and secret key separated by a colon:

AKIAIOSFODNN7EXAMPLE:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

For temporary keys, add the session token after another colon. You can also paste the JSON that aws sts get-session-token or aws sts assume-role prints. The credential is encrypted like any other. You never type the key into the server or agent itself.

Leave Region and Service empty to turn signing off.

Register an AgentCore Gateway as an MCP server​

  1. In the AgentCore console, note your gateway's MCP URL, such as https://my-gateway-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp. Its inbound authorization must be IAM.
  2. Create an IAM user or role that is allowed bedrock-agentcore:InvokeGateway on that gateway, and an access key for it.
  3. In Flightdeck, on the Credentials page of your workspace, add a credential named aws.agentcore-key with the value ACCESS_KEY_ID:SECRET_KEY.
  4. Add an MCP server: transport Streamable HTTP, the gateway's address as the URL with /mcp as the endpoint path, and Credential Reference aws.agentcore-key.
  5. In AWS Signature Version 4, set Region to us-east-1, Service to bedrock-agentcore and AWS Credentials to Stored access key. Save.
  6. Sync the server's tools. The gateway's tools appear, and you can call them through DVARA with the same policies, approvals and records as any other MCP server.

An A2A agent on AgentCore Runtime works the same way: choose the AWS_SIGV4 auth scheme on the agent, set Credential Reference to a key allowed bedrock-agentcore:InvokeAgentRuntime, and fill in the region and bedrock-agentcore.

Use the runtime's invocation URL as the endpoint, for example https://bedrock-agentcore.<region>.amazonaws.com/runtimes/<encoded ARN>/invocations/. AgentCore serves the agent's Agent Card under that path, not at the host's /.well-known/agent-card.json. From 1.9.0 DVARA looks there when the host has no card, so the card is read, checked and refreshed like any other. Before, you had to save the agent without a card.

What DVARA signs​

  • Every request: each tool call, the tool sync, the session's own requests, streamed answers, and for A2A every message, stream, task call and Agent Card request.
  • The body exactly as it is sent, the host, the content type and the x-amz-* headers. DVARA never sends a request with an unsigned body.
  • It does not send the key as a header. A server or agent that signs cannot also have OAuth, and a static header starting with x-amz- is refused.

When you rotate the credential on the Credentials page, the next call is signed with the new key. No restart is needed.

If the clock of the machine DVARA runs on is more than a few minutes off, AWS refuses the signature. DVARA then reads AWS's time from that answer and uses it for the next requests to that address. The refused call is not sent again, because it may already have had an effect.

When a request cannot be signed​

DVARA refuses the call, and nothing is sent. The caller gets MCP_UPSTREAM_SIGV4_FAILED or A2A_UPSTREAM_SIGV4_FAILED (502), with the reason: the credential could not be found, its value is not an AWS access key, the settings are not valid, or the gateway's own identity is switched off or unavailable.

Sign with the gateway's own AWS identity​

DVARA can also sign with the AWS identity it runs as, so no key is stored: the environment's AWS keys, an IAM role for service accounts (IRSA) on EKS, container credentials on ECS or EKS Pod Identity, or the EC2 instance profile.

This is off by default. To use it:

  • Set dvara.upstream-sigv4.gateway-credentials.enabled=true (environment variable DVARA_UPSTREAM_SIGV4_GATEWAY_CREDENTIALS_ENABLED) on the gateways, and on Flightdeck, which syncs tools and reads Agent Cards.
  • Only a platform administrator can choose The gateway's own AWS identity, and leave Credential Reference empty. Workspace administrators are not offered it and cannot edit a server or agent that uses it, so a workspace cannot borrow the platform's AWS role.

What the records show​

  • A refused call is recorded with its reason, the region and the service, never a key.
  • The key in use is recorded by its fingerprint, so you can see when a rotated or renewed key took effect.
  • Saving a server or agent records the region, the service and where the key comes from.
  • An export writes the setting as it is and the credential reference as ***. Importing the file back keeps the reference you had.

Who can set it​

Platform administrators and workspace administrators can both sign with a stored key that belongs to the server's or agent's workspace. Only platform administrators can use the gateway's own identity.