How it connects
The Gateway invokes a Lambda interceptor in your AWS account. The interceptor sends the native event to your authenticated Firewall endpoint and translates the decision back into the Gateway’s response format.
Traffic that bypasses the Gateway, including direct provider calls and local tools, is outside this integration’s coverage.
Before you start
Use a Firewall endpoint reachable from the Lambda and an API key registered for the intended Gateway identities. Store the key in an existing AWS Secrets Manager secret. The Terraform module receives its ARN, so the key value does not enter Terraform state. Use buffered model responses and disable MCP response streaming. Keep your existing Gateway configuration available for rollback. AWS permits one request and one response interceptor per Gateway. Check both slots before installation and preserve any existing owner. See AWS Gateway interceptors. For native Bedrock inference targets, grant the Gateway execution role the required model-discovery and model-invocation permissions. Verify that each target is ready before testing the adapter. See AWS’s Bedrock target setup.Connect your Gateway
1
Install the adapter
Apply the independently callable
modules/agentcore-integration module from SilmarilTF using the module revision and immutable signed artifact supplied for your deployment. Configure the Firewall URL, API-key secret ARN, allowed Gateway identities, and shadow mode.The module installs the Lambda, scoped permissions, logs, and alarms. Your Terraform root continues to own its provider and state backend.2
Attach both interception phases
Run the release’s Gateway preflight check. Resolve occupied interceptor slots before continuing. Attach the module’s request and response interceptor configuration to your caller-owned Gateway resources, and grant the Gateway execution role permission to invoke the adapter alias.Include response bodies so Firewall can check generated content and tool results.
3
Route and verify traffic
Point the agent’s model and MCP connections at the configured Gateway routes. Send benign requests and confirm that native bodies, IDs, status codes, and SDK behavior are preserved.Verify model input, model output, tool calls, and tool results separately. Confirm findings and capture in your Firewall deployment and check adapter latency and coverage errors.
4
Enable enforcement
Test denials, incomplete inspection, retries, parallel tool calls, and rollback in an isolated environment. Confirm that a denied request prevents execution and that a denied response releases no protected content. Then set the adapter mode to
enforce.Model and tool coverage
Unsupported schemas, missing request context and payload limits appear as coverage errors. Use those errors to identify routes or formats that need configuration changes.
The adapter checks text content and evaluates each actionable tool call in a response.
Modes and failures
Shadow is the default observation mode. Check coverage errors separately from security decisions. Lambda invocation failures return a Gateway error in either mode.
Update or roll back
Pin the immutable module revision and signedadapter_release together. Before changing them, retain the previous signed release inputs and compatible module revision, and save the current Gateway configuration. Keep the retained release’s signing profile authorized while it remains a rollback option. Review and apply a saved Terraform plan, then verify both interception phases.
For rollback, select the retained signed adapter_release and its compatible immutable module revision, then review and apply a new saved Terraform plan. The module verifies and publishes the selected adapter and moves the Lambda alias to that published version. Restore the saved Gateway configuration as needed, then verify both interception phases. Firewall releases and rollback run through its release pipeline. Customer operators apply their module and Gateway changes separately.