Auth Failing while adding MCP server in DevOps Agent

The logs you have posted, confirm that the AWS DevOps Agent is failing to forward the Authorization header.

While the VS Code request includes authorization: Bearer devops123, the AWS Agent request is missing it entirely, resulting in the 401 Unauthorized error.

To resolve this, check the following in your AWS DevOps Agent configuration:

• Header Sanitization: AWS managed services often strip the standard Authorization header for security. Try using a custom header instead (e.g., X-API-Key: your_token) and update your MCP server to accept it.
• Secret Mapping: Ensure the token is not just defined as a variable, but explicitly mapped to the outgoing request headers. In many AWS environments, you must reference a Secret Manager ARN rather than hardcoding the string.
• Case Sensitivity: Ensure the header is defined as Authorization (capitalized). Some AWS proxies filter non-standard casing.

Try the following debugging

• Redirect to RequestBin: Point the AWS Agent URL to a tool like webhook.site to verify exactly which headers are leaving the AWS environment.
• IAM Policies: Confirm the Agent's IAM Role has the secretsmanager:GetSecretValue permission if the token is stored in AWS Secrets Manager.

The fact that even a custom X-API-Key header is being stripped confirms that the AWS DevOps Agent (which appears to be running a node environment based on your logs) is likely using a strict egress/allow-list policy or a sanitization middleware that drops any non-standard headers.

Since standard header injection is failing, I recommend trying these three specific approaches:

1. Authentication via Query Parameter (Verification Step)

As a diagnostic test, try appending the token directly to the URL in the Agent configuration: https://devopsmcp.xyz.ai/mcp?token=devops123

If the request succeeds, it confirms the Agent is stripping the header block but leaving the URI intact. You can then decide if you want to support a URL-based fallback on your MCP server (though keep in mind the security implications regarding log visibility).

2. Check Origin Request Policies (If using CloudFront/ALB)

If your MCP server is sitting behind an AWS Application Load Balancer (ALB) or CloudFront, the headers might be stripped there before reaching your server.

• Ensure you have an Origin Request Policy enabled that allows "All Viewer Headers" or explicitly includes your custom headers.
• AWS often defaults to a "Managed-CORS-CustomOrigin" policy which may drop headers it doesn't recognize.

3. Switch to IAM-based Authentication (SigV4)

Instead of relying on a Bearer token, which the Agent clearly struggles to forward, you could leverage the Agent's own IAM role.

• Configure your MCP server (or the entry point like API Gateway/ALB) to require AWS Signature Version 4 (SigV4).
• The Agent will then sign the request using its execution role, removing the need for a manually injected Authorization header.

Quick Question: What is the underlying infrastructure hosting your MCP server (e.g., Lambda, EC2, or an ECS container behind an ALB)? This would help narrow down exactly where the stripping is occurring.

Ok, Check the "Drop invalid header fields" setting on the ALB first. If that is already off, the AWS DevOps Agent (Node.js) is likely not correctly appending the headers to the request object before it hits the wire. Switching to Query Parameters for a quick fix or SigV4 for a long-term secure fix is advised.

However, fixing Auth Header Stripping on AWS ALB/ECS

Given that your MCP server is hosted on ECS behind an ALB, the fact that even custom headers like X-API-Key are being dropped suggests a configuration mismatch at the load balancer level or the way the Agent interacts with the target group.

1. Disable "Drop Invalid Header Fields" on the ALB

By default, AWS Application Load Balancers can be aggressive about what they consider "invalid" headers. If the AWS DevOps Agent is sending the header in a format the ALB dislikes (e.g., underscores instead of hyphens, or specific casing), the ALB will silently drop them.

• Action: Go to the EC2 Console > Load Balancers > Select your ALB.
• Settings: Ensure "Drop invalid header fields" is turned OFF. Even if your header looks valid, turning this off is a critical troubleshooting step for proxy-passed requests.

2. Verify ALB "Origin Request" behavior

Unlike CloudFront, ALBs don't have "Origin Request Policies," but they do have specific behavior regarding the Authorization header. If the ALB is configured with OIDC/Cognito Authentication at the listener level, it will often strip or overwrite the incoming Authorization header before it reaches the ECS container.

• Action: Check if there are any "Authenticate" rules on your ALB Listener. If so, move the authentication logic entirely to your MCP server or use a custom header name that does not conflict with AWS reserved words.

3. Use the "X-Forwarded-*" Verification

In your logs, we see x-forwarded-for and x-amzn-trace-id. This proves the ALB is receiving the request. If the Authorization header is present in a curl request but missing from the node (DevOps Agent) request reaching the same ALB, the Agent's environment is likely failing to inject the header into the outbound HTTP object.

• Workaround: As a final resort for the DevOps Agent, try passing the token via the User-Agent or a Query Parameter (e.g., /mcp?api_key=...). If your ECS logs show the query parameter arriving but the header missing, the problem is 100% the Agent's header-injection middleware.

4. Recommended Infrastructure Change: SigV4

Since both the Agent and the MCP server (ECS) are within the AWS ecosystem, the most robust "AWS-native" way to fix this is to:

1. Enable AWS Signature Version 4 (SigV4) on the ALB/Target Group.

2. Grant the DevOps Agent's IAM Role permission to invoke the ALB.

3. This eliminates the need for manual Bearer tokens, which are clearly being stripped by the Agent's Node.js runtime environment.

Hello Florian,

Thanks for the reply, I am from the same team as Cedric,

We have MCP server on ECS container behind an ALB

Hi , I have tried all the mentioned methods, still getting the same logs with no x-api-key (or any other auth key) being attached by the AWS Devops Agent