AWS bedrock-agentcore high security documentation change
Summary
Added a new section 'Front your runtime with an AgentCore Gateway' explaining how to use a gateway as a security layer to enforce policies, guardrails, and interceptors
Security assessment
The change explicitly documents a security pattern to prevent direct access to the runtime, enforce policy-based authorization, and implement guardrails. It provides specific security controls (IAM/OAuth restrictions) to prevent bypass of security layers.
Diff
diff --git a/bedrock-agentcore/latest/devguide/runtime-security-best-practices.md b/bedrock-agentcore/latest/devguide/runtime-security-best-practices.md index caf6d535a..0bf915c3c 100644 --- a//bedrock-agentcore/latest/devguide/runtime-security-best-practices.md +++ b//bedrock-agentcore/latest/devguide/runtime-security-best-practices.md @@ -7 +7 @@ -Session isolation and data protectionIAM and least privilegeResource-based policies and cross-account accessConfused deputy preventionAuthentication best practicesCredential and secret managementNetwork securityEncryptionAuditing and monitoringShared responsibility modelCommand execution securityVM platform server +Session isolation and data protectionIAM and least privilegeResource-based policies and cross-account accessConfused deputy preventionFront your runtime with an AgentCore GatewayAuthentication best practicesCredential and secret managementNetwork securityEncryptionAuditing and monitoringShared responsibility modelCommand execution securityVM platform server @@ -22,0 +23,2 @@ This topic consolidates security best practices for Amazon Bedrock AgentCore Run + * Front your runtime with an AgentCore Gateway + @@ -136,0 +139,24 @@ For more information, see [Cross-service confused deputy prevention](./cross-ser +## Front your runtime with an AgentCore Gateway + +A common pattern is to front your AgentCore Runtime with an AgentCore Gateway so that the gateway becomes the single, governed entry point to the runtime. Placing a gateway in front lets you apply controls **outside** of the agent’s own environment: + + * **Policy-based authorization** — Use the gateway’s policy engine to control which callers can invoke which targets and under what conditions. For more information, see [Use policies to control access to gateway targets](./policy.html). + + * **Guardrails** — Apply Amazon Bedrock Guardrails through the policy engine to screen requests and responses. For more information, see [Use guardrails in policies](./policy-guardrails-in-policies.html). + + * **Request and response interceptors** — Inspect or transform traffic with interceptor Lambda functions configured on the gateway. + + + + +These controls only protect you if all traffic actually flows through the gateway. If a caller can reach the runtime directly, it bypasses the gateway’s policies, guardrails, and interceptors entirely. To prevent this, restrict the runtime to accept invocations only when they originate from your gateway. How you do this depends on the runtime’s inbound authorization type: + + * **IAM (SigV4) runtimes** — Attach a resource-based policy that restricts invocation to the gateway’s execution role. See [Restrict IAM (SigV4) inbound invocation to your gateway](./runtime-oauth.html#runtime-restrict-iam-gateway). + + * **OAuth (JWT) runtimes** — Configure `allowedWorkloadConfiguration` on the runtime’s authorizer. See [Restrict invocation to your gateway](./runtime-oauth.html#deploy-agent-allowed-workload). + + + + +To set this up, you [create the gateway](./gateway-create.html), [deploy your runtime](./runtime-oauth.html#deploy-agent), and then [add the runtime as a gateway target](./gateway-target-http-runtime.html) on that gateway. For the target configuration, outbound authorization, and the invocation URL format, see [AgentCore Runtime targets](./gateway-target-http-runtime.html). +