> ## Documentation Index
> Fetch the complete documentation index at: https://silmaril.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Amazon Bedrock AgentCore

> Connect model and MCP traffic through native AgentCore Gateway interceptors.

Connect Silmaril to AgentCore Gateway to check model requests, model responses, tool calls, and tool results. Your agents use their existing model and MCP interfaces through the Gateway, without a Silmaril SDK in the agent.

Get your Firewall endpoint, credentials and signed adapter release through [deployment access](https://silmaril.dev/docs/start/access.md).

## 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.

| Component | Responsibility |
| - | - |
| AgentCore Gateway | Route protected model and MCP traffic through both interception phases. |
| Silmaril Lambda adapter | Preserve native payloads, authenticate to Firewall, and apply the configured mode. |
| Firewall | Select policy, evaluate content, and record findings and capture. |

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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors.html).

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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-inference-invokemodel.html).

## 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

| Interface | Gateway route |
| - | - |
| Bedrock InvokeModel | Native inference target with a supported model-payload decoder. |
| Anthropic Messages | Inference target. |
| OpenAI Chat Completions and Responses | Inference targets. |
| Bedrock Converse | HTTP passthrough to the regional Bedrock endpoint with outbound SigV4 signing. |
| MCP tools | Request and response interceptors around tool execution. |

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

| Outcome | Shadow | Enforce |
| - | - | - |
| Completed allow | Continue with the native payload. | Continue with the native payload. |
| Completed deny | Record the decision and continue. | Block with a native denial response. |
| Incomplete inspection handled by the adapter | Report a coverage error and continue when the payload can be forwarded safely. | Block with an evaluation error. |
| Streaming or an unsafe Lambda envelope size | Reject explicitly. | Reject explicitly. |
| Lambda cannot run | Gateway error. | Gateway error. |

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 signed `adapter_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.

## Next steps

[Verify your integration](https://silmaril.dev/docs/start/verify.md), then review [findings](https://silmaril.dev/docs/operate/findings.md) and [modes and enforcement](https://silmaril.dev/docs/guides/enforcement.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.