AWS Security ChangesHomeSearch

AWS bedrock-agentcore documentation change

Service: bedrock-agentcore · 2026-04-19 · Documentation low

File: bedrock-agentcore/latest/devguide/security.md

Summary

Removed detailed content about resource-based policies and replaced with a link to a separate HTML page. The entire 'Resource-based policies for Amazon Bedrock AgentCore' section was deleted, including policy examples, best practices, and troubleshooting information.

Security assessment

This change appears to be a documentation restructuring where detailed content about resource-based policies was moved to a separate HTML file. There is no evidence in the diff of addressing a specific security vulnerability, weakness, or incident. The change maintains security documentation but reorganizes it, which could impact clarity but doesn't directly address a security issue.

Diff

diff --git a/bedrock-agentcore/latest/devguide/security.md b/bedrock-agentcore/latest/devguide/security.md
index 039fb656b..22b1a4b37 100644
--- a//bedrock-agentcore/latest/devguide/security.md
+++ b//bedrock-agentcore/latest/devguide/security.md
@@ -7,2 +6,0 @@
-Resource-based policies
-
@@ -30 +28 @@ This documentation helps you understand how to apply the shared responsibility m
-  * Resource-based policies for Amazon Bedrock AgentCore
+  * [Resource-based policies for Amazon Bedrock AgentCore](./resource-based-policies.html)
@@ -41,569 +38,0 @@ This documentation helps you understand how to apply the shared responsibility m
-## Resource-based policies for Amazon Bedrock AgentCore
-
-Resource-based policies in Amazon Bedrock AgentCore allow you to control which principals (AWS accounts, IAM users, or IAM roles) can invoke and manage your Amazon Bedrock AgentCore resources (currently supported for Runtime, Gateway and Memory). You can attach IAM-style policies directly to your resources to define rules around who can start runtime sessions, invoke a gateway, access memory or perform other management and invocation actions.
-
-Resource-based policies work in conjunction with identity-based IAM policies to provide access control for your Amazon Bedrock AgentCore resources. While identity-based policies are attached to IAM identities and specify what actions they can perform, resource-based policies are attached directly to resources and specify who can access them.
-
-###### Topics
-
-  * Supported resources
-
-  * How resource-based policies work
-
-  * Policy structure
-
-  * Supported actions
-
-  * Condition keys
-
-  * Common use cases and examples
-
-  * Managing resource policies
-
-  * Security best practices
-
-  * Troubleshooting
-
-
-
-
-### Supported resources
-
-Amazon Bedrock AgentCore supports resource-based policies for the following resources:
-
-  * **Agent Runtime and Agent Endpoints** \- Control access to agent invocation and management operations
-
-  * **Gateway** \- Control access to gateway invocation operations
-
-  * **Memory** \- Control access to memory operations
-
-
-
-
-### How resource-based policies work
-
-#### Identity-based vs resource-based policies
-
-Aspect | Identity-Based Policy | Resource-Based Policy  
----|---|---  
-Attachment |  Attached to IAM users, roles, or groups |  Attached directly to Amazon Bedrock AgentCore resources  
-Management |  Managed through AWS IAM |  Managed through Amazon Bedrock AgentCore APIs  
-Specifies |  Actions and Resources (Principal is implicit) |  Principals, Actions, and Conditions (Resource is implicit)  
-Use Case |  Define what an identity can do |  Define who can access a resource  
-  
-#### Policy evaluation
-
-When a request is made to a Amazon Bedrock AgentCore resource, AWS evaluates both identity-based and resource-based policies. The following table shows how different policy combinations affect access:
-
-IAM Policy | Resource Policy | Result  
----|---|---  
-Grants access |  Silent |  Allowed  
-Grants access |  Grants access |  Allowed  
-Grants access |  Denies access |  Denied  
-Silent |  Silent |  Denied  
-Silent |  Grants access |  Allowed  
-Silent |  Denies access |  Denied  
-Denies access |  Silent |  Denied  
-Denies access |  Allows access |  Denied  
-Denies access |  Denies access |  Denied  
-  
-Key principles:
-
-  * **Explicit Deny Always Wins** : If any policy explicitly denies the action, access is denied regardless of other policies
-
-  * **Either Policy Can Allow** : If either identity-based or resource-based policy allows the action (and no policy denies it), access is granted
-
-  * **Default Deny** : If no policy explicitly permits an action, access is denied
-
-
-
-
-#### Hierarchical authorization for agent runtime and endpoint
-
-Agent endpoints are addressable access points to specific versions of an agent runtime. Each endpoint points to a particular version of the runtime configuration, with a DEFAULT endpoint automatically routing to the latest version. When authorizing runtime API operations such as `InvokeAgentRuntime` and `InvokeAgentRuntimeCommand` , AWS evaluates both identity-based and resource-based policies for both the agent runtime and the agent endpoint being invoked.
-
-For a request to be authorized, the following conditions must be met:
-
-  * The identity-based policies attached to the calling principal must allow the action on both the agent runtime and agent endpoint resources
-
-  * The resource-based policy on the agent runtime must allow the action (if a policy exists)
-
-  * The resource-based policy on the agent endpoint must allow the action (if a policy exists)
-
-
-
-
-###### Important
-
-To provide cross-account access to a principal, you must create resource-based policies granting access for **both** the agent runtime and the agent endpoint. If either resource denies access or lacks an explicit allow statement, the request will be denied.
-
-Example: Granting cross-account access requires policies on both resources:
-    
-    
-    // Policy for Agent Runtime (attached to
-    // arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/AGENTID)
-    {
-    "Version": "2012-10-17",
-        "Statement": [
-            {
-                "Effect": "Allow",
-                "Principal": {
-                    "AWS": "arn:aws:iam::123456789012:role/CrossAccountRole"
-                },
-                "Action": "bedrock-agentcore:InvokeAgentRuntime",
-                "Resource": "arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/AGENTID"
-            }
-        ]
-    }
-    
-    // Policy for Agent Endpoint (attached to
-    // arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/AGENTID/endpoint/ENDPOINTID)
-    {
-    "Version": "2012-10-17",
-        "Statement": [
-            {
-                "Effect": "Allow",
-                "Principal": {
-                    "AWS": "arn:aws:iam::123456789012:role/CrossAccountRole"
-                },
-                "Action": "bedrock-agentcore:InvokeAgentRuntime",
-                "Resource": "arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/AGENTID/endpoint/ENDPOINTID"
-            }
-        ]
-    }
-
-#### Authentication type considerations
-
-The way you write resource-based policies depends on the authentication type configured for your Agent Runtime or Gateway:
-
-SigV4 Authentication
-    
-
-Use specific AWS principals (IAM users, roles, or accounts) in the `Principal` element. For example: `"Principal": {"AWS": "arn:aws:iam::123456789012:role/MyRole"}` . The policy is evaluated in conjunction with the caller’s IAM permissions.
-
-OAuth Authentication
-    
-
-Must use wildcard principal ( "Principal": "*" ) in policy statements. OAuth tokens are validated by AWS Identity Service before policy evaluation. Only authenticated OAuth users with valid JWT tokens from the registered Identity Provider (IdP) can invoke the resource. Anonymous or unauthenticated requests are rejected before policy evaluation. Use condition keys to restrict access (e.g., `aws:SourceVpc` , `aws:SourceVpce` ).
-
-###### Important
-
-An Agent Runtime or Gateway can only be configured with either SigV4 OR OAuth authentication at creation time, not both simultaneously. This means a single resource-based policy applies to only one authentication type.
-
-### Policy structure
-
-A resource-based policy is a JSON document with the following structure:
-    
-    
-    {
-    "Version": "2012-10-17",
-        "Statement": [
-            {
-                "Sid": "StatementId",
-                "Effect": "Allow",
-                "Principal": {
-                    "AWS": "arn:aws:iam::account-id:role/role-name"
-                },
-                "Action": "bedrock-agentcore:ActionName",
-                "Resource": "arn:aws:bedrock-agentcore:region:account-id:resource-type/resource-id",
-                "Condition": {
-                    "ConditionOperator": {
-                        "ConditionKey": "ConditionValue"
-                    }
-                }
-            }
-        ]
-    }
-
-###### Important
-
-The `Resource` field in the policy document must contain the exact ARN of the resource to which the policy is attached. Using "Resource": "*" is not supported and will result in a validation error.
-
-### Supported actions
-
-#### Agent Runtime actions
-
-  * `bedrock-agentcore:InvokeAgentRuntime` \- Invoke an agent runtime
-
-  * `bedrock-agentcore:InvokeAgentRuntimeForUser` \- Invoke an agent runtime endpoint with X-Amzn-Bedrock-AgentCore-Runtime-User-Id header
-