An AI agent may need to call an internal tool that accepts only Basic authentication. At that legacy boundary, adopting tool integration first means translating the authentication method somewhere in the request path.

An AWS Security Blog post published on August 18, 2026 places that translation point in an Amazon Bedrock AgentCore Gateway request Lambda interceptor. The key design choice is to keep the username and password away from the agent and let only deterministic Lambda code handle them.

That does not remove the weaknesses of Basic authentication. To decide whether the pattern fits, we need to separate what becomes safer from the operational debt that remains.

Translating Bearer to Basic keeps the service credential outside the model

A REQUEST interceptor runs Lambda before AgentCore Gateway calls its target, allowing validation, authorization, and request transformation. The official interceptor documentation describes it as custom code that runs during each gateway invocation.

The pattern splits the authentication path as follows.

Agent -- Bearer JWT --> AgentCore Gateway
                         |
                         +--> REQUEST interceptor
                              1. Revalidate the JWT
                              2. Read a service account from Secrets Manager
                              3. Replace Authorization with Basic
                         |
                         +-- Basic credential --> Legacy tool

After the gateway validates the inbound JWT, the interceptor validates its signature, expiration, and issuer again. It then retrieves a system service account from Secrets Manager, Base64-encodes username:password, and builds Authorization: Basic .... The AWS sample repository shows the complete flow using Amazon Cognito, PyJWT, Secrets Manager, and KMS.

An Authorization header returned by the interceptor is automatically forwarded to the target and takes precedence over a header supplied by the client or a credential provider. This behavior is documented in AgentCore Gateway's header propagation rules. The agent and tool schema therefore do not need to become aware of Basic authentication; the translation exists only at the gateway boundary.

The more important separation is permission. The agent execution role does not receive Secrets Manager access; only the interceptor Lambda can retrieve the credential. This removes a direct design path for a prompt to make the model read the secret. It is not a guarantee against prompt injection as a whole, but it does isolate direct access to the authentication credential.

Enabling passRequestHeaders turns Lambda into a sensitive trust boundary

The interceptor must use passRequestHeaders: true to read the inbound JWT in this pattern. The default is false; enabling it sends request headers, including authentication tokens, to Lambda. The interceptor security guidance explicitly warns against logging these sensitive headers.

The Lambda is therefore more than a string transformer. The implementation and its permissions need clear boundaries:

• Allow the gateway execution role to invoke only the interceptor Lambda in use
• Limit the interceptor role to secretsmanager:GetSecretValue for the intended secret ARN and kms:Decrypt for the relevant KMS key
• Keep Authorization out of event, exception, and debug logs
• Stop with a 401-equivalent response before reading the secret when JWT validation fails
• Make the transformation idempotent

The last item is easy to miss. Gateway can retry an interceptor Lambda after failures or timeouts, and the official documentation recommends idempotent functions. A stateless sequence of validation, secret retrieval, and header construction fits that requirement well.

Base64 leaves TLS and credential rotation as hard requirements

Basic authentication is not encryption. RFC 7617 defines it as a Base64 encoding of a user ID and password pair and says it is not considered secure without external protection such as TLS. Generating the header in an interceptor does not change that requirement; the path from Gateway to the downstream tool must remain protected by TLS.

A second obligation is the lifecycle of a long-lived credential. In the Active Directory example, an administrator creates the service account and seeds its initial password into Secrets Manager once. The design then rotates that human-known value immediately and keeps the password synchronized between Secrets Manager and AD.

The Secrets Manager rotation documentation reinforces that rotation updates both the secret and the database or service that uses it. Updating only one side causes authentication failures, so rotation status, synchronization drift, and downstream 401 responses belong in the same operational view. If the interceptor caches the secret, the team must also decide how quickly a rotated value is picked up.

The downstream Basic header contains a system service account, not an individual user's credential. The legacy tool will therefore see that service identity unless the design adds another mechanism. Where per-user authorization or auditability matters, use the inbound JWT claims to make the authorization decision before the call and retain a non-secret audit trail that correlates the caller with the tool invocation.

Prefer built-in OAuth or IAM whenever the target can support it

The current AgentCore Gateway outbound authorization documentation lists IAM, caller IAM credentials, OAuth, token passthrough, and API keys among the available options. Support varies by target type, including MCP servers, OpenAPI schemas, and Lambda functions.

If the downstream system can use one of those mechanisms, built-in authorization is the more natural starting point. Moving to OAuth or IAM can remove the work of generating, storing, and synchronizing a Basic-auth password. A request Lambda interceptor is most relevant when the downstream tool cannot change yet and AgentCore adoption must proceed on a different timeline from authentication modernization.

A practical decision sequence is:

1. Check the built-in authorization options for the target type
2. Establish when the downstream tool can move to OAuth, IAM, or another supported method
3. If Basic authentication is still required, design the interceptor as a time-bounded bridge
4. Make TLS, least privilege, log redaction, rotation, authorization, and auditing acceptance criteria
5. Remove the Basic translation and service account after downstream modernization

The least-privilege guidance in AWS Secrets Manager best practices is what makes steps three and four inseparable. Moving a password into a managed vault is not sufficient; isolation depends on narrowing who can read it.

Use the request interceptor as a bridge with a defined exit

The opening question has a concrete answer. Even when a legacy tool accepts only Basic authentication, a request Lambda interceptor can connect the tool without giving its credential to the agent.

Basic authentication nevertheless remains Basic authentication. TLS, header-safe logging, least-privilege Lambda and secret access, synchronized rotation, and service-account-level auditing still require deliberate operations.

The practical role of this design is therefore an integration bridge, not the target architecture. Defining its removal condition at adoption time lets a team move AgentCore work forward without allowing the downstream OAuth or IAM migration to disappear from the roadmap.

Source

• Title: Implement custom authentication for tools integration using request Lambda interceptor in AgentCore Gateway
• URL: https://aws.amazon.com/blogs/security/implement-custom-authentication-for-tools-integration-using-request-lambda-interceptor-in-agentcore-gateway/