This article shows you how to identify and secure open proxies in your AWS environment to prevent abuse, protect your IP address reputation, and control costs.

An open proxy is a server that forwards traffic on behalf of internet users without requiring authentication. While proxies can support legitimate use cases such as load balancing or caching, open proxies allow unrestricted access that threat actors can use to hide harmful activity. In Amazon Web Services (AWS) environments, open proxies often result from misconfigured Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, or compute resources such as AWS Lambda functions. These resources expose proxy functionality without access controls.

Open proxies come in several forms. Common open proxies can include:

• HTTP proxies: HTTP proxies forward HTTP requests to web servers, making them useful for web traffic management. These proxies can create potential issues when they’re unsecured.
• SOCKS proxies: SOCKS proxies support a wider range of traffic types and provide more flexibility. These proxies create a broader potential for misuse.
• Transparent proxies: Transparent proxies intercept traffic without the client’s knowledge and are often used to filter content. These proxies can become security liabilities when misconfigured.
• Reverse proxies: Reverse proxies help with internal routing. Unauthorized users can misuse these proxies if they’re exposed.

Knowing these risks can help you better protect your AWS environment.

Because of the unrestricted configuration of open proxy servers, threat actors target them to conduct denial of service (DoS) events, intrusion attempts, distribute spam, and other forms of unauthorized activity. These open proxy servers allow threat actors to hide their actual IP address and other forms of identification from the intended targets.

When your AWS infrastructure hosts an open proxy, several risks emerge that can affect both your operations and customers:

• Threat actors can misuse your resources, which can result in your IP address being added to security service and reputation system block lists. This can affect your legitimate business operations and customer access. When external parties use your infrastructure for harmful activities, the reputation damage extends beyond immediate technical concerns to affect your ability to reach customers and partners.
• Unexpected costs from resource consumption occur when threat actors use your bandwidth and compute capacity. The traffic patterns that proxy abuse generate can also alert AWS security monitoring systems and create additional operational overhead as you investigate and respond to these alerts.
• Service disruptions might affect your legitimate workloads because unauthorized traffic competes for resources with your business-critical applications. This competition for resources can potentially degrade performance or cause availability issues for your customers.

To prevent the risks associated with open proxies, it’s essential to implement proper security controls for proxy services in AWS environments. The following guidance is a comprehensive approach that you can follow to secure your proxy infrastructure.

An important security step is to use passwords and authentication mechanisms to restrict access to proxy services. Configure your proxies to accept connections only from known, trusted IP address ranges. For Elastic Load Balancing (ELB), limit access based on source IP addresses and add authentication to proxies behind the load balancers. When you create new instances in Amazon Elastic Kubernetes Service (Amazon EKS), limit access to your balancer in each instance. If instances don’t have public IP addresses, then you can limit access to the balancer instead. If instances have public IP addresses, then you must limit access to those IP addresses.

When possible, use AWS PrivateLink virtual private cloud (VPC) endpoints to provide private connectivity to AWS services without exposing them to the internet. Deploy proxy services in private subnets with controlled outbound access through NAT gateways or other controlled channels. For Amazon EC2 and Amazon Lightsail resources, update the attached security group to prevent public internet access. To secure the proxy, you must either limit access to specific IP addresses or implement authentication on the endpoint.

Turn on authentication for the proxy software and use strong credentials, certificates, or integration with AWS Identity and Access Management (IAM) and AWS Directory Service. Apply IAM policies with the principle of least privilege to limit access to only what users need to perform their tasks. This approach reduces the potential effects of credential compromise and helps maintain clear accountability for resource access.

To detect unusual proxy activity, configure Amazon Virtual Private Cloud (Amazon VPC) Flow Logs, AWS CloudTrail, and Amazon GuardDuty. Use Amazon CloudWatch alarms to notify you of abnormal traffic patterns that might indicate unauthorized use of your proxy services. These monitoring capabilities provide visibility into your network traffic patterns and help you identify both legitimate usage and potential security concerns.

Use HTTPS for ELB traffic to protect data in transit, and restrict security groups to necessary ports to minimize the surface area for potential misuse. Integrate AWS WAF with balancers to filter web traffic based on rules that you define. You can also use AWS Network Firewall for advanced traffic filtering capabilities. For APIs, deploy Amazon API Gateway with authentication and authorization controls to manage access to your backend services. This layered approach to security helps protect your infrastructure at multiple points in the traffic flow.

Run Amazon Inspector to scan for misconfigurations in your infrastructure, and use AWS Security Hub to centralize security findings across your AWS environment. Conduct penetration tests in accordance with AWS policy to identify potential security issues before they can result in unintended access.

Automate remediation with AWS Config rules and Automation, a capability of AWS Systems Manager, to respond rapidly to security events. Maintain incident response runbooks that outline clear steps for addressing proxy-related security incidents, and decommission unused resources that could become security liabilities.

Documented procedures and automated responses reduce the time between detection and remediation and minimizes the potential effects of security incidents on your operations.

When you implement these security measures, you gain the following advantages for your AWS environment:

• Protection of your IP address reputation helps maintain customer trust and prevents security services from blocking your legitimate traffic. When your infrastructure maintains a positive reputation, your business communications reach their intended recipients without interference.
• Cost control prevents unauthorized users from consuming your AWS resources and generating unexpected charges on your account. When you restrict access to legitimate users and use cases, you maintain predictable costs that align with your business needs.
• Operational stability reduces the risk of service disruptions that abuse of your proxy infrastructure can cause. When you dedicate your resources to serving your customers rather than supporting unauthorized activity, you can deliver consistent performance and availability.
• Enhanced visibility into your network traffic patterns helps you identify both legitimate usage and potential security concerns. This awareness allows you to make informed decisions about capacity planning, security improvements, and operational optimizations.

Open proxies present a serious risk in AWS environments, but you can effectively secure proxies with the right measures. By implementing strict access controls and additional security practices such as authentication, monitoring, and regular assessments, you can prevent misuse, protect your infrastructure, and maintain your IP address reputation.

Taking proactive steps strengthens your own environment and supports the broader security of the internet ecosystem. Under the AWS shared responsibility model, you’re responsible for the configuration and maintenance of these security controls, while AWS provides the underlying secure infrastructure. By following the guidance in this article, you can build a robust security posture that protects your proxy infrastructure while supporting your legitimate business needs.

If you have feedback about this post, submit comments in the Comments section below.

Generative AI brings promising innovation, transforming how individuals and organizations approach everything from customer service to content creation and more. As AI continues to expand its capabilities, organizations are increasingly focused on how they can integrate the responsible AI concepts into the development lifecycle of their AI applications.

Research from Accenture and Amazon Web Services (AWS) reveals compelling evidence for the business value of responsible AI practices, both internally within their organizations and externally to their users. Organizations that communicate a mature approach to responsible AI see an 82% improvement in employee trust in AI adoption, which directly leads to increased innovation. Additionally, companies that offer responsible AI-enabled products and services experience a 25% increase in customer loyalty and satisfaction.

AWS identifies these key dimensions that form the backbone of responsible AI implementation:

• Safety focuses on preventing harmful system output and misuse. This dimension focuses on steering AI systems to prioritize user and system safety.
• Controllability focuses on mechanisms that monitor and steer AI system behavior. This dimension refers to the ability to manage, guide, and constrain AI systems to operate within specific parameters.
• Fairness considers the impacts of AI on different groups of users.
• Explainability focuses on understanding and evaluating system outputs.
• Security and privacy focuses on making sure that data and models are appropriately obtained, used, and protected.
• Veracity and robustness focuses on achieving correct system outputs, even with unexpected or adversarial inputs.
• Governance makes sure that development, deployment, and management of AI systems align with ethical standards, legal requirements, and societal values.
• Transparency focuses on understanding how AI systems make decisions, why the systems produce specific results, and what data the systems use.

It’s a best practice to review and apply all these dimensions to your AI implementation. For more information, see Considerations for addressing the core dimensions of responsible AI for Amazon Bedrock applications.

When you implement AI systems, you should build safety into every phase of the AWS responsible AI lifecycle. The responsible AI lifecycle consists of the following three phases, each with distinct responsibility considerations for the safety dimension:

1. In the design and development phases, thoroughly evaluate potential safety risks. Understand what you want your AI application to do, what you don’t want it to do, and what you want to prevent it from doing. You should build safety guardrails into your systems from the beginning and make sure that your development teams understand the capabilities and limits of your AI application.
2. In the deployment phase, theory meets reality. During this phase, you should implement robust safety measures through multiple layers, from comprehensive user training to proactive monitoring and review processes. Every application, product, and feature must include clear safety protocols and user guidelines. You must think beyond the launch of an application and consider how to launch a holistic safety framework. This framework—which can contain steps such as red team testing—must protect your brand, users, and stakeholders.
3. In the operations phase, it’s important to maintain vigilance. Safety, like security, isn’t something you set up once and then ignore. Safety requires continuous monitoring and adaptation. To catch potential safety issues early, you can implement real-time feedback mechanisms to conduct regular performance evaluations. You can also continuously monitor for shifts in how your application is used, or functions that could compromise safety. Because safety considerations and risks evolve as technology evolves, it’s crucial to understand that adjustments are necessary over time.

For more information, see the Responsible use of AI guide.

Foundation models in Amazon Bedrock are inherently designed with safety mechanisms to prevent harmful outputs. However, you can implement additional input safety systems in production environments to provide critical early detection capabilities to identify problematic content, users, or patterns.

Note: Amazon Bedrock might implement automated abuse detection mechanisms to identify potential violations of the AWS Acceptable Use Policy (AUP) and Service Terms, including the Responsible AI Policy or a third-party model provider’s AUP.

See the Amazon Bedrock abuse detection document for more information.

To maintain trust in your AI services, preventative action is key, while also efficiently planning and managing development resources. Introduce observability and safety guardrails early in development to support long-term scalability and help identify potential issues before they affect your users. To begin this process, thoroughly scope your AI use case with the following actions:

• Understand your users
• Anticipate potential misuse scenarios
• Define your risk tolerance

This scope guides your development of a precise safety framework that addresses the specific risks of your AI implementation while you maintain expected performance. For this scope, you can use AWS specialized tools designed specifically to monitor and protect Amazon Bedrock applications.

Amazon CloudWatch provides essential visibility into AI system behavior and performance. When you configure comprehensive logging, you can capture important information across user segments and interaction types, such as the following:

• Request volumes
• Response latencies
• Rejection rates
• Content filtering triggers

You can use this information to identify potential abuse patterns or unexpected behaviors before they affect operations. CloudWatch dashboards visualize metrics according to monitoring priorities, and automated alerts provide prompt notification when you exceed thresholds. This infrastructure transforms interaction data into actionable insights and supports continuous safety improvement.

Note: By default, Amazon Bedrock logging is turned off. You must turn on logging for your application. To configure this, contact your account manager.

Amazon Bedrock Guardrails offers configurable protection mechanisms tailored to specific risk profiles and content policies. You can customize Bedrock Guardrails to match your application requirements, such as:

• Define domain-relevant undesirable topics
• Configure appropriate content filtering thresholds
• Configure sensitive information detection and redaction parameters aligned with data policies

Additionally, you can configure controls that prioritize accuracy and prevent hallucinations while maintaining creative flexibility based on your application needs. When you thoughtfully configure Guardrails, you can balance performance and safety according to your specific use case requirements and risk factors.

As AI safety evolves and new risks emerge, abuse might still occur even if you implement safety mechanisms. If you receive an abuse report from the AWS Trust & Safety team, then complete the following steps to help effectively address the issue:

1. Acknowledge receipt: Acknowledge the receipt of the abuse report within 24 hours. If your team is still conducting their investigation, then inform AWS that the investigation is ongoing. Provide the number of days expected to complete the investigation.
2. Investigate the issue: Thoroughly investigate the issue, including examining the logs (if enabled), reviewing Amazon Bedrock inputs, and checking for unauthorized access. While AWS abuse reports include a small sample of prompt IDs for you to investigate, investigate usage of your Amazon Bedrock application. Check for patterns to see if there’s a systemic issue that’s leading to abuse.
3. Take appropriate action: If appropriate, take action to implement fixes, update safeguards, address violating users, or redesign features. Consider if you need systemic or root-cause fixes, rather than addressing one abusive end user. An abuse incident by one user could indicate vulnerabilities in your safety mechanisms that can lead to continuous abuse.
4. Report back to AWS Trust & Safety: Following your investigation and implementation of fixes, provide an update to AWS Trust & Safety on your findings and remediation steps. Be transparent about what happened and how you addressed the issue. If you think that no violation occurred, then provide context on how you came to this conclusion. Include examples of the prompts and your business use case where possible.

To learn more about safety and responsible AI development, explore AWS resources, including the Responsible AI portal and machine learning best practices documentation. These resources provide additional tools and frameworks to build safe, effective AI systems that drive innovation and maintain safety standards.

The AWS Customer Incident Response Team (AWS CIRT) regularly encounters patterns that repeat across their engagements when helping customers respond to security incidents. We’re passionate about making sure that information is widely accessible so that everyone can improve their security posture and their organization’s resilience to disruption. The primary method we use to share this information is the Threat Technique Catalog for AWS (TTC). The latest update to the catalog for March 2026 addresses identity, persistence, infrastructure destruction, and privilege escalation. Each new entry reflects something we’ve encountered in practice, and each provides straightforward mitigations. This post breaks down what changed, why it matters, and what you can do about it today.

Based on recent observations, we’ve added three new entries to the TTC.

Amazon Cognito refresh tokens are designed for convenience. They let applications obtain new access and ID tokens without requiring users to re-authenticate. The default lifetime is 30 days and is configurable up to 10 years. Cognito provides the flexibility to address a wide range of use cases, however the AWS CIRT has seen this lifetime window used by threat actors in an unauthorized way to maintain persistence by refreshing credentials.

When a threat actor obtains a valid refresh token—through credential theft, compromised client-side storage, or elevated permissions—they can call cognito-idp:GetTokensFromRefreshToken to silently generate fresh tokens. The legitimate user’s session continues normally because their application independently refreshes tokens as needed—the threat actor’s refresh calls don’t invalidate the user’s token. This creates a parallel, persistent foothold that’s invisible to the user. In environments where refresh token rotation isn’t enabled, the same token can be reused indefinitely within its validity window.

This method of gaining persistent access is often overlooked by response teams who were confident that the initial compromise was contained, only to discover ongoing unauthorized access weeks later through a refresh token they didn’t know existed.

Enabling refresh token rotation and reducing the lifetime of tokens can help mitigate this risk. Dive deeper in the TTC (T1098.A006).

Amazon Machine Images (AMI) are a core part of many solutions and foundational to disaster recovery. They often contain the operating system, application configurations, and everything needed to rebuild your infrastructure. Threat actors know this, and we’re seeing ec2:DeregisterImage used to make it more difficult to recover from an incident.

By default, when an AMI is deregistered, it’s gone. Recycle Bin retention rules can allow the recovery of the AMI, but if you haven’t explicitly enabled that functionality, there’s no way to undo the deregister action. Working with customers, we’ve seen cases where the impact of this action goes beyond the immediate loss because the threat actors have also removed the golden images the teams planned to restore from.

The TTC has more information about how to detect and mitigate this technique, including how to enable Recycle Bin retention rules for key AMIs (T1485.A002).

We’ve updated T1098.003: Additional Cloud Roles to now include UpdateAssumeRolePolicy as a tracked API call. We’ve seen an increase in the use of this call to avoid detections set to flag new role creation (iam:CreateRole). By modifying the trust policy of an existing role, a threat actor with sufficient permissions can use UpdateAssumeRolePolicy to subtly add an external account or an identity they control. No new roles appear. No new policies are created. The existing role simply trusts a new principal which the threat actor can assume.

This persistence and privilege escalation technique blends into the volume of normal AWS Identity and Access Management (IAM) operations. It’s especially effective in environments with a large number of roles where trust policy changes aren’t actively monitored.

A common thread runs through all three of these updates: threat actors are using subtle, default, or unexpected behaviors to sidestep detection. Refresh tokens working as designed. AMI deregistration completing without guardrails. Trust policies being modified through legitimate API calls. These actions might not trigger alarms in most environments because they look like normal operations.

This is a shift worth paying attention to. Rather than relying on novel exploits or zero-days, the techniques we’re cataloging reflect threat actors who understand how cloud services work and use that knowledge to hide in plain sight. The implication for security teams is clear: prevention and detection strategies need to mature beyond monitoring for obviously malicious actions. Customers need to be watching for legitimate actions happening in illegitimate context—such as the right API call, made by the wrong principal, at the wrong time.

The Threat Technique Catalogue for AWS is designed to help with exactly this. Each technique entry includes detection guidance and mitigations specific to AWS environments. We encourage teams to review the relevant entries and assess whether their current monitoring would catch these patterns:

• T1098.A006: Cognito Refresh Token Abuse: Are you monitoring for cognito-idp:GetTokensFromRefreshToken from unexpected sources? Is refresh token rotation enabled?
• T1485.A002: AMI Image Deletion: Do you have Recycle Bin retention rules protecting your critical AMIs? Would you know if a production AMI was deregistered outside a maintenance window?
• T1098.003: Additional Cloud Roles: Are trust policy modifications tracked and alerted on? Could an external account be added to an existing role without anyone noticing?

Each of these techniques leaves traces in AWS CloudTrail, and the TTC provides specific guidance on what to watch for and how to respond.

The Threat Technique Catalog for AWS exists because we believe the patterns we observe during security engagements shouldn’t stay behind closed doors. When we see techniques repeating across customers, the most effective thing we can do is document them and make that knowledge available so you can act on it before you’re in the middle of an incident.

This March update adds three new entries, and the catalog will continue to evolve. Our team regularly updates it based on what we’re seeing in the real world when helping customers respond to security events. We encourage security teams to review the catalog regularly, incorporate its techniques into threat modeling exercises, and use it as a shared vocabulary for discussing cloud-specific threats.

Explore the full catalog: Threat Technique Catalog for AWS

• Reduce costs with customized delete protection for Amazon EBS Snapshots and EBS-backed AMIs
• Protect your resources from deletions through Rule Lock for Recycle Bin
• How to monitor, optimize, and secure Amazon Cognito machine-to-machine authorization
• AWS CIRT announces the launch of the Threat Technique Catalog for AWS
• Amazon Cognito refresh tokens documentation
• Amazon GuardDuty

If you have feedback about this post, submit comments in the Comments section below.

Understanding what AWS Identity and Access Management (IAM) policies can control helps you build better security controls and avoid spending time on approaches that won’t work. You’ve likely encountered questions like:

• Can I use AWS Organizations service control policies (SCPs) to prevent the creation of security groups that allow traffic from 0.0.0.0/0?
• Can I block uploads unless objects are encrypted?
• Can I prevent functions with more than 512 MB of memory allocated?

Some of these are possible with IAM policies. Others are not. The difference is determined by a fundamental principle of AWS authorization: Policies make decisions based on information available in the authorization context at the time of the API call.

In this blog post, you learn how to use the AWS Service Authorization Reference to determine what’s achievable with IAM policies, recognize scenarios that need alternative solutions, and build more effective security controls in your AWS environment.

When you make an AWS API request through the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS SDK, the specific AWS service (such as Amazon S3 or Amazon EC2) receiving the request assembles a request context containing information about that request. This context is used for policy evaluation decisions. Request context is structured using the Principal, Action, Resource, Condition (PARC) model, which has four key components.

• Principal: Identifies the requester and their attributes (tags, session context)
• Action: Specifies the AWS API operation being requested (for example, s3:PutObject, ec2:RunInstances)
• Resource: Defines the target AWS resource using Amazon Resource Names (ARNs)
• Condition: Provides additional context available at request time, such as IP address, time, encryption parameters, MFA status, and service-specific attributes

The following example shows the typical request context for an Amazon S3 object upload:

• Principal: AIDA123456789EXAMPLE
• Action: s3:PutObject
• Resource: arn:aws:s3:::my-bucket/documents/samplereport.pdf
• Condition:
  • aws:PrincipalTag/Department=Finance
  • aws:RequestedRegion=us-east-1
  • aws:SourceIp=x.x.x.x
  • aws:MultiFactorAuthPresent=true
  • s3:x-amz-server-side-encryption=AES256
  • s3:x-amz-storage-class=STANDARD_IA

IAM policies can evaluate request metadata like encryption method and storage class being specified. However, it cannot evaluate the actual file contents, object size, or specific data patterns. Policy evaluation occurs at the time of the request, using the information present in the authorization context.

The Service Authorization Reference is the authoritative documentation for understanding what policies can control. For every AWS service, it documents:

• Actions: Every controllable operation
• Resources: Resource types that can be targeted
• Condition keys: The exact context information available for policy decisions

Condition keys are broadly divided into two categories. Global condition keys, which can be used across AWS services, and service-specific condition keys, which are defined for use with an individual AWS service. Use the Service Authorization Reference to find the global-condition keys or service-specific condition keys for each AWS service.

Follow these steps to determine if your requirement can be controlled with IAM policies:

1. Navigate to your service: Go to the page for the specific AWS service you’re working with, such as Actions, resources, and condition keys for Amazon S3.
2. Find the action you want: Find the API operation you want to control. Be precise, different actions have different available condition keys.
3. Examine available condition keys: The Condition keys column shows what context information AWS makes available for that action.
4. Make your feasibility determination: If the information you need isn’t listed as a condition key, you will not be able to control it with IAM policies alone.

Let’s take an example from the Amazon Elastic Compute Cloud (Amazon EC2) ec2:RunInstances action to see what you can and can’t control. In the Service Authorization Reference under the Amazon EC2 section, examine the RunInstances action and check the Resource types column. The RunInstances action affects multiple resource types, each with its own set of condition keys.

For the instance* resource type:

• ec2:InstanceType: Can restrict instance types
• ec2:EbsOptimized: Can require EBS optimization
• aws:RequestTag/: Can enforce tagging requirements

For the network-interface* resource type:

• ec2:Subnet: Can control subnet placement
• ec2:Vpc: Can limit to specific virtual private clouds (VPCs)
• ec2:AssociatePublicIpAddress: Can control public IP assignment

Note: These are a few examples from the many condition keys available for each resource type under the RunInstances action. The Service Authorization Reference lists dozens of condition keys across resource types (instance, network interface, security group, subnet, volume, and so on) that RunInstances affects. Consult the complete reference to see the available options for your specific use case.

Beyond the human-readable documentation, AWS provides the Service Authorization Reference in machine-readable JSON format to streamline automation of policy management workflows. Use this programmatic access to incorporate authorization metadata into your development and security workflows.
For detailed information about the JSON structure and field definitions, see the Simplified AWS service information for programmatic access.
Developers can use tools like the IAM MCP Server for AWS IAM operations. This server provides AI assistants with the ability to manage IAM users, roles, policies, and permissions while following security best practices.

The following examples show how you can use IAM policies to control specific scenarios.

In the Amazon S3 Service Authorization Reference, under s3:PutObject action, the s3:x-amz-server-side-encryption condition key is available in the authorization context, which can be used to control the server-side encryption of S3 objects with AES-256. Here is the required policy.

Policy 1: Deny Amazon S3 object upload if the encryption doesn’t use AES-256

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "DenyUnencryptedObjectUploads",
			"Effect": "Deny",
			"Action": "s3:PutObject",
			"Resource": "arn:aws:s3:::my-bucket/*",
			"Condition": {
				"StringNotEquals": {
					"s3:x-amz-server-side-encryption": "AES256"
				}
			}
		}
	]
}

Policy 1 is a resource-based policy that can be applied on an S3 bucket to restrict object uploads. It denies a PutObject request when the server-side encryption isn’t using the AES-256 encryption algorithm.

When checking the Amazon EC2 Service Authorization Reference for ec2:RunInstances, the ec2:InstanceType condition key, which is resource specific, is available. To restrict instance types based on who is launching them (rather than just what is being launched), you can either combine this with a global condition key or attach different policies to different principals. By using aws:PrincipalTag/tag-key alongside ec2:InstanceType, you can identify the user’s cost center from their IAM identity tags and then apply different instance type restrictions accordingly. This allows a single policy to dynamically enforce different permissions based on the requester’s identity.

Policy 2: Restricting EC2 instance types by cost center

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "AllowDevInstanceTypes",
			"Effect": "Allow",
			"Action": "ec2:RunInstances",
			"Resource": "arn:aws:ec2:*:*:instance/*",
			"Condition": {
				"StringEquals": {
					"aws:PrincipalTag/CostCenter": "Development"
				},
				"StringLike": {
					"ec2:InstanceType": "t3.*"
				}
			}
		},
		{
			"Sid": "AllowProdInstanceTypes",
			"Effect": "Allow",
			"Action": "ec2:RunInstances",
			"Resource": "arn:aws:ec2:*:*:instance/*",
			"Condition": {
				"StringEquals": {
					"aws:PrincipalTag/CostCenter": "Production"
				},
				"StringLike": {
					"ec2:InstanceType": [
						"m5.*",
						"c5.*",
						"r5.*"
					]
				}
			}
		}
	]
}

This is an identity-based policy that you can attach to IAM users, groups, or roles to control EC2 instance launches based on cost allocation. In the first statement, aws:PrincipalTag, which is a global condition key (tags attached to the IAM user or role), is used to determine which instance types are allowed. Users tagged with CostCenter=Development can only launch cost-effective T3 instance types (t3.micro, t3.small, t3.medium, and so on)with the service specific key ec2:InstanceType.

In the second statement, users tagged with CostCenter=Production can launch more powerful instance types from the M5 (general purpose), C5 (compute optimized), and R5 (memory optimized) families. This approach lets organizations enforce cost controls and allocate resources based on workload requirements. Each cost center maintains flexibility for its specific needs.

Note: Additional resources are required in the IAM policy to successfully launch EC2 instances. For the complete list, see Launch Instances.

You have identified that GetItem, PutItem,and UpdateItem actions are required. Corresponding to these actions, you can use the condition key to expose partition key values in the authorization context as described in the Amazon DynamoDB Service Authorization Reference

Policy 3: DynamoDB fine-grained access control

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
				"dynamodb:GetItem",
				"dynamodb:PutItem",
				"dynamodb:UpdateItem"
			],
			"Resource": "arn:aws:dynamodb:us-east-1:111122223333:table/UserProfiles",
			"Condition": {
				"ForAllValues:StringEquals": {
					"dynamodb:LeadingKeys": ["${aws:username}"]
				}
			}
		}
	]
}

The policy allows users to perform read and write actions (GetItem, PutItem, and UpdateItem) on the UserProfiles table, but only for items where the partition key value equals their own username (using the ${aws:username} policy variable). For example, if user alice attempts to access an item with partition key bob, the request will be denied.

Some requirements can’t be met using IAM policies. Here are three common scenarios that aren’t achievable with IAM policies alone.

Upon checking the Amazon EC2 Service Authorization Reference, you will find that the ec2:AuthorizeSecurityGroupIngress action is required in an IAM policy to add an inbound access rules to a security group.

To verify this in the Service Authorization Reference, navigate to the Amazon EC2 Service Authorization Reference and search for the AuthorizeSecurityGroupIngress action, which is the action that creates security group rules. After you locate this action, review the Condition keys column and look for condition keys related to CIDR blocks, IP ranges, ports, or protocols. Available condition keys for ec2:AuthorizeSecurityGroupIngress include:

• aws:ResourceTag/${TagKey}: Filters access by a tag key and value pair of a resource
• ec2:ResourceTag/${TagKey}: Filters access by a tag key and value pair of a resource
• ec2:SecurityGroupID: Filters access by the ID of a security group
• ec2:Vpc: Filters access by the ARN of the VPC

Notice there are no condition keys for CIDR blocks (such as 0.0.0.0/0), port numbers (such as 22), or protocols (such as TCP). The authorization context doesn’t include information about the specific CIDR blocks, ports, or protocols being added to the security group rule, so IAM policies can’t control these attributes.

Solution
Take a reactive approach using the AWS Config managed rule INCOMING_SSH_DISABLED to detect overly permissive rules. You can also use a combination of Amazon EventBridge and Lambda to either send a notification to your security team for the non-compliant configuration or to restrict the security group through an automation. For more information, see How to Automatically Revert and Receive Notifications About Changes to Your Amazon VPC Security Groups.

Following the same verification methodology described in Scenario 1, navigate to the AWS Lambda Service Authorization Reference and examine the CreateFunction action’s condition keys for the function* resource type.

Available condition keys for lambda:CreateFunction with the function* resource type include:

• lambda:CodeSigningConfigArn: Filters access by the ARN of the code signing
• configuration-lambda:Layer: Filters access by the ARN of a version of an AWS Lambda layer
• lambda:VpcIds: Filters access by the ID of the VPC configured for the Lambda function

There is no condition key for memory allocation (MemorySize parameter), timeout settings, storage configuration (EphemeralStorage), or runtime selection. Because memory allocation isn’t exposed in the authorization context, IAM policies can’t restrict this parameter.

Solution

• Use a policy-as-code (PaC) approach with AWS CloudFormation Hooks. For more information, see A practical guide to getting started with policy as code.
• Use AWS Service Catalog to provide pre-approved Lambda configurations.
• Use LAMBDA_FUNCTION_SETTINGS_CHECK to apply an AWS Config rule to detect non-compliant functions.

Keep these principles in mind when working with IAM policies:

• Policies control what’s in the authorization context, not all elements you see in API documentation
• The Service Authorization Reference is authoritative; if something isn’t listed as a condition key, you can’t control it with policies
• Different actions have different available contexts even within the same service
• Alternative approaches exist. AWS Config, EventBridge, and service-specific controls can be used to achieve your goals when policies alone can’t
• Layered security is essential; combine preventive, detective, and responsive controls to help ensure that your data is secure

In this post, you learned how to use the AWS Service Authorization Reference to determine what’s achievable with IAM policies and recognize scenarios that require alternative solutions. By understanding that policies can only make decisions based on information available in the authorization context, you can build more effective security controls and avoid spending time on approaches that won’t work.

The Service Authorization Reference is your authoritative source for understanding policy capabilities. When you need to implement a control, start there to see if the required condition keys exist. If they don’t, you will need to layer in detective or responsive controls using services like AWS Config, Amazon EventBridge, or AWS Lambda.

Remember that effective AWS security isn’t about finding one perfect control, it’s about combining preventive, detective, and responsive measures to create defense in depth. IAM policies are powerful tools for prevention and work as part of a comprehensive security strategy.

Next steps:

• Explore IAM policy simulator to test and troubleshoot your policies
• Read IAM policy types: How and when to use them to understand when to use different policy types
• Watch the video on Understanding AWS IAM Policy Language: Elements, Evaluation, and Best Practices

If you have feedback about this post, submit comments in the Comments section below.

As outlined in the AWS post-quantum cryptography (PQC) migration plan, addressing the risk of harvest now, decrypt later (HNDL) attack is an important part of your post-quantum plan. Upgrading the client-side of your workloads to support quantum-resistant confidentiality is an important aspect of your side of the PQC shared responsibility model. Timelines to plan and execute your PQC upgrades vary by region and by industry and will depend on your own business risk profile. To learn more, see the AWS PQC frequently asked questions.

AWS Secrets Manager uses SSL/TLS to communicate with AWS resources, currently supporting TLS 1.2 and 1.3 in all AWS Regions. The service supports using TLS 1.3 with hybrid post-quantum key exchange for clients that support this capability. The hybrid post-quantum approach establishes TLS connections by combining traditional cryptography (such as X25519) with post-quantum algorithms (ML-KEM), and helps to protect your secrets against both current classical attacks and future quantum computer threats. Regardless of how your workload accesses Secrets Manager, this client-side software upgrade is the only action you need to take to address risk to secrets from HNDL. Your secrets at rest are already encrypted using keys managed by AWS Key Management Service (AWS KMS). Properly implemented symmetric encryption is considered quantum-resistant; asymmetric cryptography faces quantum threats. To learn more, watch AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified.

To reduce builder effort for client-side upgrades, we’re pleased to announce the following Secrets Manager clients now enable and prefer post-quantum TLS when initiating connections to Secrets Manager: Secrets Manager Agent (v2.0.0 or later), the AWS Lambda extension (v19 or later) and the Secrets Manager CSI Driver (v2.0.0 or later). For SDK-based clients, hybrid post-quantum key exchange is available in supported AWS SDKs. Enablement requirements vary by language, version, and operating system. See the following table for your SDK client.

This launch is part of the ongoing commitment AWS has made to migrate systems to post-quantum cryptography and making it straightforward for our customers to do the same. See Post-Quantum Cryptography to learn more.

The following table summarizes the behavior for each client. When the client is upgraded to support hybrid post-quantum key exchange, the Secrets Manager service endpoint automatically selects it during the TLS handshake. Upgrading to the versions listed in the table is the only action you need to take for your workload to begin using hybrid post-quantum key exchange when calling Secrets Manager APIs.

If you’re using the Secrets Manager Agent, the Lambda extension, or the CSI Driver, upgrade to the listed version to use hybrid post-quantum key exchange in TLS as the default. Customers using the AWS SDK for Rust, Go, or Node.js at the versions listed in the table are already upgraded and no additional action is required. The SDK will select the hybrid post-quantum key exchange for API calls. For customers using the AWS SDK for Python, hybrid post-quantum key exchange in TLS requires OpenSSL 3.5 or later to be present on the host system. Guidance on verifying and enabling this is available in the AWS Secrets Manager documentation. For customers using the AWS SDK for Java v2, hybrid post-quantum key exchange in TLS requires using the AWS CRT HTTP client. The postQuantumTlsEnabled(true) must be set on the CRT client to enable hybrid post-quantum key exchange in TLS.

After your client versions meet the requirements listed in the table, you can verify that your connections are actively using hybrid post-quantum key exchange.

With hybrid post-quantum key exchange using ML-KEM now enabled by default for Secrets Manager clients (see the preceding table), most customers will not need ongoing monitoring to verify correct behavior or detect regressions. However, security teams and compliance officers might want to confirm that their Secrets Manager API calls are negotiating the hybrid key exchange. On the server side, you can confirm hybrid post-quantum key exchange in TLS by using AWS CloudTrail. On the client side, you can inspect TLS handshake details using a utility like Wireshark or by using developer tools built into major web browsers.

Verification is a two-step process: first, fetch a secret using your Secrets Manager client to generate a GetSecretValue API call, then confirm in AWS CloudTrail that the call negotiated hybrid post-quantum key exchange.

The following examples show how to retrieve your secret using the Secrets Manager Agent, Lambda extension, and CSI Driver—each of which will automatically negotiate hybrid post-quantum key exchange when calling the GetSecretValue API.

To verify hybrid post-quantum TLS with Secrets Manager Agent on EC2 instance:
Install the agent on your Amazon Elastic Compute Cloud (Amazon EC2) instance and use it as a client to fetch your secret.

1. Follow the instructions for AWS Secrets Manager Agent.
2. Ensure that your EC2 instance profile has the permission for secretsmanager:GetSecretValue to fetch the secret.
3. Connect to your private EC2 instance.
4. Install the agent on your EC2 instance.
5. Use the agent to fetch your secret.
   curl -H “X-Aws-Parameters-Secrets-Token: $(</tmp/awssmatoken)” localhost:2773/secretsmanager/get?secretId=<YOUR-SECRET-ARN>
6. Wait for about 5 minutes for CloudTrail to deliver the logs.
7. Go to the CloudTrail event history and search for the event GetSecretValue.

To verify hybrid post-quantum TLS with Lambda extension:
Use the AWS parameters and Secrets Manager Lambda extension to create a Lambda function that will consume your secrets from Secrets Manager using direct API calls.

1. Follow Using the AWS parameters and secrets Lambda extension to create the Lambda layer and the Lambda function.
2. Select the latest extension version.
3. Wait for about 5 minutes for CloudTrail to deliver the logs.
4. Go to the CloudTrail event history and search for the event GetSecretValue.

To verify hybrid post-quantum TLS with CSI driver on Amazon EKS:
On your Amazon Elastic Kubernetes Service (Amazon EKS) cluster, use the AWS Secrets Store CSI Driver provider to fetch secrets from Secrets Manager in Kubernetes pods:

1. Confirm the installed add-on version is 2.0.0 or later.
   eksctl get addon --cluster <CLUSTER-NAME> --name aws-secrets-store-csi-driver-provider
2. Trigger a secret retrieval by restarting a pod that mounts a secret, or deploying a new one.
3. Wait for about 5 minutes for CloudTrail to deliver the logs.
4. Go to the CloudTrail event history and search for the event GetSecretValue.

CloudTrail logs include a tlsDetails field for Secrets Manager API calls. When hybrid post-quantum key exchange in TLS is active, the keyExchange field in tlsDetails will show X25519MLKEM768. Each CloudTrail record includes a tlsDetails field that contains the cipher suite and, where available, the key exchange group negotiated during the TLS handshake.

You can work with CloudTrail event history using the AWS Management Console for CloudTrail or the AWS Command Line Interface (AWS CLI).

To look up CloudTrail events using the console:

1. Verify you are in the correct AWS Region.
2. Open the CloudTrail console and select Event History.
3. Under Lookup attributes filter, select Event name and GetSecretValue.
   
   

   Figure 1: Search CloudTrail event history by event name

4. Select your event.
   
   

   Figure 2: Select the event

5. View the output in the Event Record section of the page.
   
   

   Figure 3: CloudTrail – GetSecretValue event

To look up CloudTrail events using AWS CLI :
Using AWS CLI, select the last events and look at the output.

aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
--max-results 5 \
--region <YOUR-REGION> \
--query 'Events[0].CloudTrailEvent' \
--output text

Example of CloudTrail Event for GetSecretValue API call:

In the following example, the userAgent field reflects what it used as a client to connect to Secrets Manager.

Note: The userAgent value depends on the client you use.

{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89",
        "arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89",
        "accountId": "111122223333",
        "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "AROA123456789EXAMPLE",
                "arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE",
                "accountId": "111122223333",
                "userName": "YOUR-EC2-INSTANCE-PROFILE"
            },
            "attributes": {
                "creationDate": "2026-03-27T17:08:37Z",
                "mfaAuthenticated": "false"
            },
            "ec2RoleDelivery": "2.0"
        },
        "inScopeOf": {
            "issuerType": "AWS::EC2::Instance",
            "credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89"
        }
    },
    "eventTime": "2026-03-27T17:12:54Z",
    "eventSource": "secretsmanager.amazonaws.com",
    "eventName": "GetSecretValue",
    "awsRegion": "eu-west-2",
    "sourceIPAddress": "1.2.3.4",
    "userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0",
    "requestParameters": {
        "secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
    },
    "responseElements": null,
    "requestID": "027507ea-f377-43d9-bf2f-646d4dc19223",
    "eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73",
    "readOnly": true,
    "resources": [
        {
            "accountId": "111122223333",
            "type": "AWS::SecretsManager::Secret",
            "ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
        }
    ],
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "111122223333",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.3",
        "cipherSuite": "TLS_AES_128_GCM_SHA256",
        "clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com",
        "keyExchange": "X25519MLKEM768"
    }
}

If the keyExchange field shows X25519MLKEM768, then hybrid post-quantum key exchange in TLS is active. If it shows a traditional algorithm such as X25519, the client is not advertising ML-KEM support, and you should check the client version and configuration.

If your Secrets Manager API calls aren’t negotiating X25519MLKEM768 after updating your clients, check your SDK version, OpenSSL version (Python), and firewall or proxy configuration as shown in the Client Hybrid Post-Quantum Key Exchange Requirements section near the beginning of this post.

This launch is one step in a broader migration. AWS is continuing to roll out ML-KEM support across AWS service HTTPS endpoints as part of Workstream 2 of the AWS PQC Migration Plan, with a target of full coverage across public AWS endpoints.

Support for CRYSTALS-Kyber, the pre-standardization predecessor to ML-KEM, is phasing out across AWS endpoints in 2026. Customers on older SDK versions that advertise only CRYSTALS-Kyber support will fall back gracefully to traditional TLS rather than negotiate the deprecated algorithm. To avoid this fallback, upgrade to the SDK versions listed in this post.

The journey of PQC migration extends beyond confidentiality of data in transit. To stay informed about the latest developments in the AWS PQC journey and your side of shared responsibility, follow the AWS Post-Quantum Cryptography page.

AWS Secrets Manager now enables hybrid post-quantum key exchange using ML-KEM by default to help protect your secrets and support your compliance efforts. This update requires no code changes or configuration updates for customers using the latest client versions.

This post covered how AWS Secrets Manager uses hybrid post-quantum cryptography to secure TLS connections, which clients support this capability, and how to verify that your connections are protected against harvest now, decrypt later attacks.

To benefit from this announcement today:

• Upgrade your Secrets Manager client (Agent, Lambda extension, or CSI Driver) to the latest available versions to enable hybrid post-quantum key exchange using ML-KEM
• If your workload uses the AWS SDK instead of a caching client, upgrade your AWS SDK and underlying dependencies to the minimum versions listed in this post
• Verify hybrid post-quantum key exchange in TLS is active by checking the keyExchange field in CloudTrail tlsDetails for your Secrets Manager API calls
• Test end-to-end hybrid post-quantum key exchange TLS connectivity in your environment, including network paths that traverse corporate firewalls or proxies

AWS will continue rolling out post-quantum cryptography support. For information about the broader migration effort, see the AWS PQC Migration Plan. Keep an updated cryptographic inventory of your broader environment to identify other uses of traditional public-key cryptography that will require migration. The CISA Quantum-Readiness guidance and the AWS PQC Migration Plan are good starting points.

Additional resources

• ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager
• Post-quantum TLS in Python

AI agents and coding assistants interact with AWS resources through the Model Context Protocol (MCP). Unlike traditional applications with deterministic code paths, agents reason dynamically, choosing different tools or accessing different data depending on context. You must assume an agent can do anything within its granted entitlements, whether OAuth scopes, API keys, or AWS Identity and Access Management (IAM) permissions, and design your controls accordingly. Agents operate at machine speed, so the impact of misconfigured permissions scales quickly.

This blog post focuses on IAM as the authorization layer for AWS resource access and presents three security principles for building deterministic IAM controls for these non-deterministic AI systems. The principles apply whether you’re using AI coding assistants like Kiro and Claude Code, or deploying agents on hosting environments like Amazon Bedrock AgentCore. We cover deployment patterns, then explore each principle with concrete IAM policy examples and implementation guidance.

This post specifically addresses securing the MCP access path, where agents interact with AWS resources through MCP servers. AI coding assistants and agents can also access AWS service APIs directly through general-purpose tools like bash or shell execution, bypassing MCP servers entirely. For this reason, we recommend architecting agents to use MCP servers rather than direct service access where possible. MCP servers provide a layer of abstraction that enables the differentiation controls in principle 3 and creates additional monitoring capabilities through AWS CloudTrail. When agents bypass MCP, the differentiation mechanisms in principle 3 don’t apply, and principles 1 and 2 become your primary controls. We discuss this scope boundary in principle 3.

Your deployment pattern determines which security principles and implementation approaches apply. Three dimensions define this pattern, including where the agent runs, what type of MCP server offers the tools, and your level of control over the agent code. No matter how you connect to it, the MCP server needs AWS credentials to interact with AWS resources.

Agents access AWS resources from three locations: developer machines (where you control the infrastructure), hosting environments (where you control the infrastructure or significant aspects of it), and third-party agent platforms (where you do not control the infrastructure). This post focuses on the first two patterns. Each has a different credential model and different organizational control options.

AI coding assistants and local agents

AI coding assistants (Kiro, Claude Code) or local agent applications represent the first deployment pattern. These assistants run locally on developer machines and connect to MCP servers or use AWS Command Line Interface (AWS CLI) commands to access AWS resources. In this pattern, credentials come from the developer’s local environment. When a developer configures an MCP server in their mcp.json file, they specify which AWS credentials to use. Options include a named profile, which can use credential helpers and the credential provider chain for short-lived credentials, environment variables, or explicit credential configuration. This means the developer controls which IAM principal the agent uses to access AWS. This creates a governance challenge. Without additional controls, developers often use their developer admin credentials, shared development roles, or even production roles for agent access. Developer credentials often carry broad permissions designed for interactive use, where human judgment serves as a safeguard. When an agent inherits these permissions, it operates without that judgment at machine speed. Principle 1 explores this risk in detail.

Agents on hosting environments

Agents deployed on hosting environments represent the second deployment pattern. These agents run on infrastructure you manage, not on developer machines. This changes the credential management model. Using Amazon Bedrock AgentCore as an example, when an agent runs on AgentCore Runtime, it uses an execution IAM role that you configure when creating the runtime. The execution role’s permissions apply to all operations the agent performs and cannot be scoped down per-invocation at the runtime configuration level. For more granular control, agents can call AWS Security Token Service (AWS STS) AssumeRole or AssumeRoleWithWebIdentity (collectively referred to as AssumeRole in this post). This obtains temporary credentials with session policies that further restrict permissions beyond the role’s base permissions. Agents built with frameworks like Strands can also initialize individual MCP clients with different credential sets by calling AssumeRole and passing the resulting credentials to each client connection. This enables per-tool credential isolation within a single agent process. The same pattern applies to agents deployed on Amazon Elastic Compute Cloud (Amazon EC2) or Amazon Elastic Kubernetes Service (Amazon EKS).

With this centralized execution model, you can implement organizational controls. You define the available IAM roles through infrastructure configuration instead of relying on developer choice. However, you must design these roles carefully to prevent overly permissive access and implement session policies for tool-specific restrictions.

MCP servers come in two types, provider-managed and self-managed. AWS-managed servers are operated by AWS on your behalf. Self-managed servers are servers that you install and run yourself. The server type affects your operational overhead, available features, and how you implement security controls.

AWS offers fully managed MCP servers, including the AWS MCP Server, Amazon EKS MCP Server, and Amazon ECS MCP Server. These AWS-managed servers run on AWS infrastructure and require no installation or maintenance on your part. AWS-managed MCP servers automatically add IAM context keys (aws:ViaAWSMCPService and aws:CalledViaAWSMCP) to every downstream AWS service call. You can write IAM policies that check these keys to distinguish between AI-driven actions and human-initiated actions without any additional configuration.

Self-managed MCP servers include AWS-provided servers from the AWS MCP GitHub repository that you install and run yourself. They also include custom MCP servers that you build from scratch. With self-managed servers, you control the deployment location (local machine, Amazon EC2, Amazon EKS), the configuration, and the maintenance. These servers can be used with either AI coding assistants running locally or agents deployed on hosting environments. The key difference for security controls is that self-managed servers don’t automatically add IAM context keys for differentiation. You must configure the MCP server to add session tags when assuming IAM roles if you require differentiation between AI-driven and human-initiated actions. This requires modifying your MCP server code to call AWS STS AssumeRole with tags attached. You then write IAM policies that check for these tags using the aws:PrincipalTag condition key. Self-managed servers can also be extended to implement dynamic authorization flows, such as mapping inbound OAuth tokens to outbound IAM role assumptions, giving you control over the full authorization chain. Additionally, with AWS-managed MCP servers, AWS injects context keys at the service layer, so callers cannot spoof them. With self-managed servers, the entity calling AssumeRole sets the session tags, so you must trust that your MCP server code hasn’t been modified.

The responsibility model differs between server types. With AWS-managed MCP servers, AWS is responsible for server infrastructure, patching, and context key injection. You’re responsible for IAM policy design and credential configuration. With self-managed MCP servers, you’re additionally responsible for server patching, dependency and library supply chain security, session tag implementation, and verifying server integrity. This connects to the supply chain risk described in principle 1. While self-managed servers require more operational overhead to implement and maintain, they give you flexibility and control.

A third dimension shapes your security implementation, whether you control the agent and MCP client code (code-controlled) or are limited to configuring pre-built tools without modifying their runtime behavior (configuration-bound). This determines which security mechanisms are available to you at runtime.

In configuration-bound scenarios, you use an AI coding assistant such as Kiro or Claude Code and configure credentials in your mcp.json file. You select which IAM role or profile the agent uses, but you cannot modify the agent’s runtime behavior. The agent calls AWS APIs using whatever credentials you configured ahead of time, and you cannot inject session policies or tags into those calls programmatically. Your security controls must be in place before the agent runs. You select narrowly scoped roles at configuration time, and your organization enforces guardrails through permission boundaries and service control policies (SCPs). These mechanisms restrict what the agent can do regardless of which role the developer selects.

In code-controlled scenarios, you build or deploy a custom agent on Amazon Bedrock AgentCore, Amazon EC2, Amazon EKS, or your local machine, or you build and run a custom MCP server. Because you control the runtime code, you can implement credential management programmatically. For custom agents, this means calling AssumeRole with session policies scoped to each tool invocation, attaching session tags for differentiation, and obtaining temporary credentials with the minimum permissions each operation requires. For custom MCP servers, you can inject session policies into every AWS API call the server makes, applying a consistent set of restrictions across all operations. Both approaches give you runtime IAM controls that are not available in config-bound scenarios.

The following table summarizes how these dimensions combine.

Your deployment pattern and level of client control determine which of the following security principles apply and how you implement them.

With this understanding of deployment patterns, let’s explore the three security principles that apply across all patterns.

• Principle 1 – Assume all granted permissions could be used: Design permissions based on the acceptable scope of impact, not intended functionality alone.
• Principle 2 – Provide organizational guidance on role usage: Enforce permission design through role governance, session policies, permission boundaries, and organizational policies.
• Principle 3 – Differentiate AI-driven from human-initiated actions: Apply different IAM rules based on whether the action comes from an agent or a human.

The first security principle is fundamental. Any permission you grant to an agent can be exercised, regardless of your intended use case. If you give an agent s3:DeleteObject permission with a tool that can call the API, you must assume it can delete any Amazon Simple Storage Service (Amazon S3) object it has access to. This can happen in ways you cannot predict or fully prevent through code review alone. This non-deterministic behavior requires a shift in your approach to IAM permissions.

Traditional applications follow deterministic code paths. You can review the source code, identify every API call, and grant the permissions needed. AI agents operate differently. They make decisions at runtime based on reasoning, context, and learned patterns. You cannot predict which AWS APIs or tools an agent will call or which resources it will access. Static analysis of agent code tells you what tools are available, but not which tools will be invoked or how they’ll be used.

This creates a challenge when developers configure agents to use AWS credentials. Developers commonly use existing IAM roles, such as the role their traditional application uses or their local admin role for the AWS CLI. These roles were designed assuming predictable behavior and human judgment. Your local admin role has s3:* permissions because you exercise judgment on what to delete and when. You understand the context, recognize production resources, and can assess the impact of your actions.

An agent with that same role operates at machine speed without human judgment. It can delete production data through hallucination or be directed through prompt injection to perform unintended actions. It can also make a logical error in its reasoning that leads to unintended operations. The speed and scale at which agents operate increases the potential scope of these issues. An agent can make thousands of API calls in seconds, so the impact of misconfigured permissions scales quickly.

Consider the following scenarios with overly permissive access.

• Hallucination: The agent misinterprets a user request and performs the wrong action. An agent designed to clean up temporary files might hallucinate that production data is temporary and delete it.
• Prompt injection: An outside party crafts unexpected input that influences the agent’s reasoning. An agent designed to query Amazon DynamoDB tables could be directed to call dynamodb:PutItem or dynamodb:DeleteItem on resources outside its intended scope.
• Logic errors: The agent’s reasoning leads to an incorrect conclusion. An agent analyzing S3 storage costs might conclude that frequently accessed production data is unused and delete it to save costs.
• Tool poisoning: A compromised MCP server or dependency performs unintended operations using the agent’s credentials. An agent with broad S3 and DynamoDB permissions connects to an MCP server whose dependency has been modified to exfiltrate data. The compromised tool reads sensitive objects and writes them to an attacker-controlled location, all within the agent’s granted permissions.

This security principle reframes how you approach IAM permissions for agents. Instead of asking what does the agent need to do?, ask what is the scope of impact if the agent acts outside its intended use case? Design permissions based on the acceptable scope of access, not only on intended functionality. If an agent needs to read S3 objects, grant s3:GetObject, not s3:*. If it needs to write to specific paths, use resource-level conditions to restrict access to those paths. Consider what tools the agent has access to and what API calls those tools can make. Design permissions that limit what the agent is allowed to perform based on organizational policy. This doesn’t mean agents can’t have write or delete permissions. It means you and your organization must consider what resources those permissions apply to and what safeguards are in place.

Beyond IAM policies, consider implementing data perimeters as an additional layer of defense. Data perimeters use VPC endpoint policies, resource control policies (RCPs), resource policies, and service control policies (SCPs) to restrict access based on identity, resource, and network boundaries. For agents, data perimeters help verify that even if IAM permissions are broader than intended, access is limited to trusted resources from expected networks. For more information, see Building a data perimeter on AWS.

Practical implementation guidance:

• Apply least privilege rigorously: If an agent needs read access, grant read permissions. If it needs write access, grant write to specific resources, not all resources of that type.
• Use resource-level restrictions: Employ IAM policy conditions to limit permissions to specific buckets, paths, tables, or other resources. Don’t grant blanket permissions across all resources.
• Consider read-only alternatives: Evaluate whether the agent’s task can be accomplished with read-only access. Many analysis and reporting tasks don’t require write or delete permissions.
• Implement comprehensive monitoring: Set up Amazon CloudWatch alarms for unexpected agent actions, unusual access patterns, or operations on sensitive resources. Monitor for sensitive operations like deletions or modifications to production resources.
• Conduct regular permission audits: As agents gain new tools and capabilities, developers often add permissions incrementally without removing unused ones. An agent that started with read-only access can gradually accumulate write and delete permissions across multiple services. Review agent IAM roles and policies regularly to identify and remove permissions that are no longer needed.
• Verify MCP server integrity: Verify the provenance and integrity of MCP servers before granting them access to AWS credentials. Maintain an organizational registry of approved MCP servers and their expected behavior, and monitor for unauthorized server deployments that might have assumed execution roles. For more on agentic application risks, see the OWASP Top 10 for Agentic Applications.

Security principle 1 establishes the foundation. Understand the scope of every permission you grant. The next two security principles build on this foundation.

The second security principle addresses organizational governance. Principle 1 requires that you design permissions based on acceptable scope of impact. Principle 2 addresses how your organization enforces that design through role governance, session policies, permission boundaries, and organizational policies.

When developers adopt AI coding assistants and configure MCP servers, they choose which credentials to use. Without organizational controls, developers often use existing roles (such as personal admin roles, shared development roles, or production roles) that were designed for human use with far more permissions than agents need. For agents deployed on hosting environments, you configure execution roles, but the same question applies. What permissions should those roles have, and how do you enforce consistency across deployments? The answer depends on your level of client control.

When you control the agent code

When you build or deploy custom agents on Amazon Bedrock AgentCore, Amazon EC2, Amazon EKS, or locally, you control the runtime code and can implement dynamic credential management. This is the strongest enforcement model because you can scope permissions per tool invocation at runtime. The same applies if you build or modify a custom MCP server. Because you control the server code, you can inject session policies into every AWS API call the server makes.

The IAM role defines the permission ceiling for the agent across all its tools. Instead of creating a separate role for every tool or MCP server, you use session policies to scope down the role’s permissions per operation. When the agent invokes a specific tool, it calls AssumeRole with a session policy that restricts permissions to just what that tool requires. The effective permissions are the intersection of the role’s policies and the session policy. Session policies restrict permissions but never expand them. If a role grants broad permissions but you attach the ReadOnlyAccess managed policy as a session policy, the agent can only perform read operations. You can also use inline session policies for resource-specific restrictions, such as limiting access to specific S3 buckets or DynamoDB tables.

The following example shows how to implement session policies in agent code.

import boto3

# Uses the execution IAM role as part of AgentCore Runtime
sts = boto3.client('sts')

# Assume role with ReadOnlyAccess managed policy as session policy
response = sts.assume_role(
    RoleArn='arn:aws:iam::111122223333:role/AgentDataRole',
    RoleSessionName='agent-data-reader',
    PolicyArns=[
        {'arn': 'arn:aws:iam::aws:policy/ReadOnlyAccess'}
    ],
    DurationSeconds=3600
)

# Use the temporary credentials
credentials = response['Credentials']
s3 = boto3.client(
    's3',
    aws_access_key_id=credentials['AccessKeyId'],
    aws_secret_access_key=credentials['SecretAccessKey'],
    aws_session_token=credentials['SessionToken']
)

For agents on hosting environments like Amazon Bedrock AgentCore, the execution role serves two purposes. It’s the trust anchor that lets the agent call AssumeRole for tool-specific credentials, and it can supply baseline permissions that all operations need, such as writing logs to CloudWatch. For tool-specific operations that access customer resources, use AssumeRole with session policies to obtain scoped temporary credentials rather than using the execution role’s permissions directly. This centralized execution model simplifies enforcing consistent session policies across all agent deployments. Agents can also attach tags when assuming roles for differentiation purposes (covered in Security principle 3).

When you’re configuration bound

When you use an AI coding assistant like Kiro or Claude Code with off-the-shelf MCP servers, you configure credentials in your mcp.json file but cannot modify the agent’s runtime behavior. Your security controls must be established before the agent runs.

Your first control is role selection. As described in the preceding deployment patterns section, AI coding assistants use credentials from the developer’s local environment. Create agent-specific IAM roles with narrower permissions than equivalent human roles, and direct developers to use them. For self-managed MCP servers running locally, the developer specifies the role through environment variables in the mcp.json configuration.

{
  "mcpServers": {
    "awslabs.aws-pricing-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-pricing-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "agent-dev-role",
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

For AWS-managed MCP servers, the developer connects through the mcp-proxy-for-aws proxy and specifies the role through the profile parameter.

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--profile", "agent-dev-role",
        "--metadata", "AWS_REGION=us-east-1"
      ]
    }
  }
}

Only role selection depends on developer compliance. IAM permission boundaries provide organizational enforcement without requiring code changes or developer cooperation. A permission boundary is a managed policy that your security team attaches to an IAM role to set the maximum permissions that role can grant. The effective permissions are the intersection of the role’s identity-based policies and the permission boundary. Permission boundaries are most effective on agent-specific roles that your organization creates for agent use. They ensure those roles cannot exceed their intended permissions even if misconfigured. If a developer configures their existing role in mcp.json instead, a permission boundary on that role restricts all use of the role, not just agent use. For AWS-managed MCP servers, principle 3’s context keys address this gap. They let you write IAM policies that restrict actions only when they come through an MCP server, leaving the developer’s direct use of the same role unaffected. For self-managed MCP servers, modifying the server code to AssumeRole into an organization-defined role provides a similar override, and session tags can be attached during that AssumeRole for differentiation (see principle 3). For multi-account environments, SCPs in AWS Organizations provide guardrails at the account or organizational unit level. SCPs set the maximum permissions for all principals in an account, giving your central governance team control over agent permissions across your organization.

Organizational governance at scale

Whether your agents are config-bound or code-controlled, you need organizational mechanisms to enforce consistent governance across teams and accounts.

Tag IAM roles intended for agent use with a consistent identifier, such as a tag key of Usage with a value of Agent. This lets your governance team inventory all agent roles across accounts, identify roles that don’t have permission boundaries, and distinguish agent roles from human roles in audit reports. You can also use tag-based conditions in SCPs to enforce that only properly tagged roles are used for agent operations. For AWS-managed MCP servers, the automatic context keys (principle 3) provide this identification without requiring role tags, but tagging remains useful for role inventory and audit purposes.

Use CloudTrail to monitor all API calls made by agent sessions and set up CloudWatch alarms for sensitive operations like resource deletion or permission changes. Principle 3 covers how to filter and analyze agent activity using context keys (AWS-managed MCP) and session tags (self-managed MCP).

For multi-account environments, combine SCPs with permission boundaries and resource control policies (RCPs) for layered enforcement. SCPs set the maximum permissions for principals within your organization at the account or organizational unit level, while permission boundaries constrain individual roles. RCPs enforce controls at the resource level regardless of the caller’s organizational membership, protecting resources even from cross-account access. Verify that the AWS services you use support MCP context keys in RCP evaluation. This layered approach gives your central governance team control over agent permissions across your organization, even when individual teams manage their own accounts and roles. Conduct quarterly reviews of agent roles and session policies to identify permissions that are no longer needed as agent capabilities evolve.

Practical implementation guidance:

• For code controlled agents: Implement session policies for every tool invocation. Use AssumeRole with the minimum permissions each operation requires rather than relying on the execution role’s base permissions.
• For config-bound agents: Create agent-specific IAM roles with narrower permissions than human roles or configure self-managed MCP servers to AssumeRole into an organization-defined role. Have your security team attach permission boundaries to agent-specific roles to enforce maximum permissions regardless of developer role selection.
• At the organization level: Tag agent roles consistently, enforce guardrails through SCPs, and monitor agent activity through CloudTrail. Conduct quarterly reviews to remove unused permissions.

Security principle 2 gives you organizational control over agent permissions through mechanisms matched to your level of client control. Session policies and dynamic credential scoping enforce permissions at runtime for code-controlled agents. Permission boundaries and SCPs enforce permissions at the organizational level for config-bound agents. The next principle adds a complementary layer of governance at the resource level based on whether a human or agent is performing the action.

The third security principle adds an additional level of control on top of principle 2. Where principle 2 governs what permissions an agent has, this principle governs what the agent can do with those permissions based on whether the action is AI-driven or human-initiated.

This principle is essential for two reasons. For AWS-managed MCP servers, you cannot modify the server code to inject session policies or call AssumeRole with scoped credentials. The developer’s credentials flow through as-is. Context keys are your primary mechanism to restrict agent actions differently from human-initiated actions on the same role. For self-managed MCP servers where principle 2’s session policies are already in place, differentiation adds a second layer of defense at the resource level. Even if the session policy is broader than intended, differentiation policies can deny specific dangerous operations when performed through an agent.

For example, you can allow both humans and agents to read Amazon S3 objects, but deny delete operations when accessed through agents. Without a differentiation mechanism, IAM policies can’t distinguish between AI-driven actions and human-initiated actions. If a developer has s3:DeleteObject permission and uses an agent with their credentials, the agent also has s3:DeleteObject permission with no way to restrict it.

Differentiation gives you granular governance. Allow human-initiated actions with broad permissions while restricting agent actions to narrower permissions. Apply different rules based on context and implement progressive restrictions. Allow read operations for everyone, require approval for AI-driven write operations, and deny delete operations for agent actions entirely. Maintain audit trails showing which actions were AI-driven versus human-initiated, essential for compliance and security investigations.

When agents bypass MCP servers

Differentiation through condition keys and session tags applies when the agent accesses AWS through an MCP server. AI coding assistants like Kiro and Claude Code have access to general-purpose tools, including bash, shell, and code execution. When an agent uses a bash tool to run an AWS CLI command like aws s3 rm s3://my-bucket/my-object or executes a Python script that calls boto3 directly, the request goes straight to AWS using the developer’s existing credentials. The request bypasses MCP servers entirely. The aws:ViaAWSMCPService condition key isn’t set, session tags from MCP server AssumeRole calls aren’t applied, and IAM policies conditioned on these values don’t evaluate.

This means a deny policy like “Condition": {"Bool": {"aws:ViaAWSMCPService": “true"}} blocks the agent when it calls Amazon S3 through a managed MCP server, but doesn’t block the same agent when it runs the equivalent AWS CLI command through a bash tool. The agent has two paths to the same AWS API, and differentiation controls govern one path.

The condition keys work as designed, differentiating MCP-mediated access from direct access. This is a scope boundary. Differentiation controls secure the MCP access path. For the direct access path, principles 1 and 2 are your controls. Least privilege on the underlying IAM role (principle 1) and organizational guardrails like permission boundaries and SCPs (principle 2) apply regardless of how the agent reaches AWS. If the role doesn’t have s3:DeleteObject permission, the agent can’t delete objects through a bash tool or through an MCP server.

Restricting which tools an agent can access is a complementary control outside the scope of IAM. You can use agent frameworks and hosting environments such as Amazon Bedrock AgentCore to limit the set of available tools, removing general-purpose execution capabilities for agents that interact with AWS exclusively through MCP servers. When you combine tool restriction with the IAM controls in this post, you close the gap between the MCP access path and the direct access path.

AWS-managed MCP servers: Automatic context keys

AWS-managed MCP servers, including the AWS MCP Server, Amazon EKS MCP Server, and Amazon ECS MCP Server, offer differentiation by default. They automatically add IAM context keys to every downstream AWS service call. These context keys are aws:ViaAWSMCPService, a boolean set to true when the request comes through any AWS-managed MCP server. The second key is aws:CalledViaAWSMCP, a string containing the MCP server name like aws-mcp.amazonaws.com, eks-mcp.amazonaws.com, or ecs-mcp.amazonaws.com. No configuration is required on your part. You only need to write IAM policies that check for these keys to apply different rules for agent actions.

The following IAM policy denies delete operations when accessed through any AWS-managed MCP server.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowS3ReadOperations",
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:ListBucket"
    ],
    "Resource": "*"
  }, {
    "Sid": "DenyDeleteWhenAccessedViaMCP",
    "Effect": "Deny",
    "Action": [
      "s3:DeleteObject",
      "s3:DeleteBucket"
    ],
    "Resource": "*",
    "Condition": {
      "Bool": {
        "aws:ViaAWSMCPService": "true"
      }
    }
  }]
}

When a request doesn’t come through an AWS-managed MCP server, the aws:ViaAWSMCPService condition key isn’t present in the request context. The Deny statement only applies when the key is explicitly set to true, so human-initiated actions are unaffected by this policy.

You can also restrict operations to specific MCP servers. With this policy, you can run EKS operations only when accessed through the EKS MCP server, not through the AWS API MCP server.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowEKSOperationsViaEKSMCP",
    "Effect": "Allow",
    "Action": "eks:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:CalledViaAWSMCP": "eks-mcp.amazonaws.com"
      }
    }
  }, {
    "Sid": "DenyEKSOperationsViaOtherMCP",
    "Effect": "Deny",
    "Action": "eks:*",
    "Resource": "*",
    "Condition": {
      "Bool": {
        "aws:ViaAWSMCPService": "true"
      },
      "StringNotEquals": {
        "aws:CalledViaAWSMCP": "eks-mcp.amazonaws.com"
      }
    }
  }]
}

Self-managed MCP servers: Manual session tags

Self-managed MCP servers, whether AWS-provided servers from the AWS MCP GitHub repository or custom servers you build yourself, don’t automatically add IAM context keys. To implement differentiation with self-managed servers, you must configure the MCP server to add session tags when assuming IAM roles. This requires modifying your MCP server to call AWS STS AssumeRole with tags attached. The tags remain active for the duration of the assumed role session and can be referenced in IAM policies using the aws:PrincipalTag condition key. This approach gives you flexibility and control over the session tag configuration. To maintain consistency, verify that all MCP server instances add the appropriate tags.

The following example shows how to configure your MCP server to add session tags.

import boto3

sts = boto3.client('sts')

response = sts.assume_role(
    RoleArn='arn:aws:iam::111122223333:role/MCPServerRole',
    RoleSessionName='mcp-server-session',
    Tags=[
        {'Key': 'AccessType', 'Value': 'AI'},
        {'Key': 'Source', 'Value': 'AgentRuntime'},
        {'Key': 'MCPServer', 'Value': 'org-data-server'}
    ]
)

# Use the temporary credentials from response['Credentials']
credentials = response['Credentials']

After your MCP server has added session tags, you can write IAM policies that check for these tags to differentiate agent actions.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowS3ReadOperations",
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:ListBucket"
    ],
    "Resource": "*"
  }, {
    "Sid": "DenyDeleteWhenAccessedViaAI",
    "Effect": "Deny",
    "Action": [
      "s3:DeleteObject",
      "s3:DeleteBucket"
    ],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalTag/AccessType": "AI"
      }
    }
  }]
}

Session tags and session policies are both passed to AssumeRole, but serve different purposes. Session policies (covered in security principle 2) constrain what permissions the agent has. Session tags (covered here in security principle 3) mark the session as AI-driven, enabling IAM policies to differentiate between agent and human actions. You can use both in the same AssumeRole call for defense-in-depth. The session policy constrains what the agent can do. The session tags let IAM policies apply different rules based on the actor type.

The following example uses both session policies and session tags together.

import boto3

sts = boto3.client('sts')

# Assume role with both managed session policy and tags
response = sts.assume_role(
    RoleArn='arn:aws:iam::111122223333:role/AgentDataRole',
    RoleSessionName='agent-data-reader',
    PolicyArns=[                              # Principle 2: Constrains permissions
        {'arn': 'arn:aws:iam::aws:policy/ReadOnlyAccess'}
    ],
    Tags=[                                    # Principle 3: Enables differentiation
        {'Key': 'AccessType', 'Value': 'AI'},
        {'Key': 'Source', 'Value': 'AgentRuntime'},
        {'Key': 'MCPServer', 'Value': 'org-data-server'}
    ],
    DurationSeconds=3600
)

CloudTrail logging and audit trails

Both differentiation mechanisms generate CloudTrail logs for audit trails. For AWS-managed MCP servers, downstream AWS API calls include the MCP service identifier in the invokedBy, sourceIPAddress, and userAgent fields. You can filter on these fields to isolate agent activity. MCP-originated downstream calls are classified as data events, so you must enable data event logging on your CloudTrail trail to capture them.

{
  "eventVersion": "1.11",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAEXAMPLE:developer-session",
    "arn": "arn:aws:sts::111122223333:assumed-role/DeveloperRole/developer-session",
    "accountId": "111122223333",
    "sessionContext": {
      "sessionIssuer": {
        "type": "Role",
        "principalId": "AROAEXAMPLE",
        "arn": "arn:aws:iam::111122223333:role/DeveloperRole",
        "accountId": "111122223333",
        "userName": "DeveloperRole"
      }
    },
    "invokedBy": "aws-mcp.amazonaws.com"
  },
  "eventSource": "s3.amazonaws.com",
  "eventName": "GetObject",
  "sourceIPAddress": "aws-mcp.amazonaws.com",
  "userAgent": "aws-mcp.amazonaws.com",
  "eventType": "AwsApiCall",
  "managementEvent": false,
  "eventCategory": "Data"
}

For self-managed MCP servers with session tags, the tags appear in the requestParameters.principalTags field of the AssumeRole CloudTrail event. You can correlate the session name from the AssumeRole event to downstream API calls to trace agent activity.

{
  "eventSource": "sts.amazonaws.com",
  "eventName": "AssumeRole",
  "requestParameters": {
    "roleArn": "arn:aws:iam::111122223333:role/MCPServerRole",
    "roleSessionName": "mcp-server-session",
    "principalTags": {
      "AccessType": "AI",
      "Source": "AgentRuntime",
      "MCPServer": "org-data-server"
    }
  }
}

With these logs, you can query CloudTrail to find all AI-driven actions and analyze patterns of agent behavior. You can also identify unexpected or unauthorized operations and maintain compliance audit trails. Set up CloudWatch alarms to detect agent actions on sensitive resources or unusual patterns that indicate unintended access or misconfiguration.

When deciding between AWS-managed and self-managed MCP servers, consider the trade-offs. AWS-managed MCP servers offer the most straightforward path. Context keys are added automatically with no configuration on your part. Self-managed MCP servers require modifying code to add session tags. However, they give you complete control over the tags and let you implement custom functionality not available in AWS-managed servers. Organizations can use both approaches, AWS-managed servers for standard AWS operations and self-managed servers for specialized use cases.

Practical implementation guidance:

• Assess direct access paths: Evaluate whether your agents have access to general-purpose tools (bash, shell, code execution) that can bypass MCP servers. If they do, rely on principles 1 and 2 for those paths and consider restricting tool availability where possible.
• Choose a differentiation mechanism: Select based on your MCP server type (for managed, use context keys, for self-managed, use session tags).
• For AWS-managed MCP: Write IAM policies that check aws:ViaAWSMCPService and aws:CalledViaAWSMCP condition keys. No MCP server configuration needed.
• For self managed MCP: Modify MCP server code to add session tags when assuming roles. Verify consistent tag application across all instances.
• Update IAM policies: Add differentiation conditions to existing policies. Test in non-production first to verify behavior.
• Monitor CloudTrail logs: Verify differentiation is working by checking for context keys or session tags in CloudTrail events.
• Set up alerts: Configure CloudWatch alarms for AI-driven sensitive operations or policy violations.
• Perform regular audits: Review IAM policies quarterly to verify differentiation conditions remain correct as agent capabilities evolve.

Securing AI agent access to AWS resources requires building deterministic IAM controls for non-deterministic AI systems. The three security principles give you a defense-in-depth framework that adapts to your deployment pattern and level of client control.

Your implementation path depends on your situation. Start with principle 1. Audit current agent permissions and default to read-only access where possible. Next, implement principle 2. For config-bound scenarios, establish permission boundaries and select agent-specific roles. For code-controlled scenarios, implement dynamic session policies scoped to each tool invocation. Finally, add principle 3 differentiation based on your MCP server type. Use automatic context keys with AWS-managed MCP servers, or configure session tags with self-managed servers.

By applying these three security principles, you can use AI agents while maintaining the governance and compliance controls your organization requires.

If your organization relies on AWS IAM Identity Center for workforce access, you can now extend that access across multiple AWS Regions with multi-Region replication. Previously, AWS access portal was only available in one Region, when you add an additional Region, users get an active access portal endpoint there. If the primary Region experiences a disruption, they can continue working through the additional Region. This enhancement also enables you to deploy AWS managed applications in additional Regions closer to your users, which reduces latency and helps meet regional compliance requirements. Meanwhile, you maintain centralized control by managing Identity Center configurations from the primary Region.

In this post, you’ll learn how to configure multi-Regions support, including multi-Region replication, encryption setup, adding Regions, updating your identity provider (IdP), and testing the setup end to end.

Before enabling multi-Region support, confirm your environment meets these requirements and understand how this change will affect your existing setup.

• Confirm that your currently deployed AWS managed applications support Identity Center configured with a customer managed KMS key, and that applications you plan to deploy in the future also support this configuration. See the AWS managed applications that integrate with IAM Identity Center table in the Identity Center User Guide to identify which applications support customer managed KMS key with Identity Center.
• Additionally, for AWS managed applications you plan to deploy in additional Regions, verify that they support Identity Center configured with both customer-managed KMS keys and multi-Region deployment. Consult the AWS managed applications that integrate with IAM Identity Center table in the Identity Center User Guide.
• You must be using an organization instance of Identity Center connected to an external identity provider (IdP), such as Okta or Microsoft Entra ID. Review documented IdPs in External identity providers.
• Both the primary and additional Regions must be commercial Regions enabled by default.

Keep the following limitations in mind before you begin:

• IAM Identity Center account instances don’t support multiRegion replication.
• Microsoft Active Directory and IAM Identity Center directory as identity source aren’t supported for multi-Region replication.
• AWS opt-in Regions aren’t supported.
• The AWS access portal in additional Regions doesn’t support the custom alias (in other words, customer-chosen subdomains).
• AWS account access through additional Region relies on already provisioned permissions; new permission set assignments and group memberships can be managed only in the primary Region and are then automatically replicated to additional Regions.

To set up multi-Region support, you’ll follow three steps: creating and configuring a customer-managed KMS key with Identity Center, enabling the additional Region in the Identity Center console, and updating your identity provider with the new regional URLs and bookmark applications.

Important: Your Identity Center instance operates on a primary-replica model where instance-level configuration changes must be made in the primary Region, while additional Regions receive read-only replications of your settings and provide Region-local access for your workforce. In this example, you will use Okta as your external IdP, with N. Virginia (us-east-1) as the primary Region and Frankfurt (eu-central-1) as the additional Region.

Before you start, ensure that you’re signed in to the console as an administrator in the same account and Region where your Identity Center instance resides.

First, you must set up a multi-Region customer-managed KMS key with Identity Center in your primary Region and replicate it to additional Regions where you plan to replicate Identity Center. Identity Center uses customer-managed KMS keys for encryption of your identity data such as user attributes. Because the same key material must be available in each Region, you’ll create a multi-Region key — complete this step in the AWS Organizations management account. Before proceeding, confirm that your currently deployed AWS managed applications support customer-managed KMS keys with Identity Center. Each AWS KMS key has usage and storage cost, see AWS KMS pricing page for details.

1. Create the multi-Region customer-managed KMS keys in your primary Region and add it to your Identity Center instance
Follow the blog AWS IAM Identity Center now supports customer-managed KMS keys for encryption at rest, ensuring that you choose Multi-Region Key in Part 1: Create the key and define permissions.

For guidance on configuring your key policy, see the KMS key policy examples for common use cases in the Identity Center User Guide, which provides example policies you can adapt for your specific requirements.

2. Create replica keys in additional Regions
After completing the primary Region setup, create new replica keys in each AWS Region where you plan to replicate Identity Center. To complete this step, follow the documentation in Create multi-Region replica keys.

Note: The replica key automatically inherits the same key policy as the primary customer-managed KMS key. However, future modifications to the key policy must be manually applied to the replica key in each Region. AWS KMS replica keys are independent resources; policy changes on the primary key do not propagate automatically.

Now that key replication is complete, you can add an additional Region to your Identity Center instance. For this post, use Frankfurt (eu-central-1). If you have a delegated admin account configured, we recommend completing remaining configurations in that account. We will perform this configuration using the console, but you can also use the IAM Identity Center API. For detailed instructions, see Add the Region in IAM Identity Center.

1. Open the AWS Management Console.
2. In the search bar, enter IAM Identity Center and choose the service.
3. In the navigation pane, choose Settings.
4. Choose Add Region.


Figure 1: Management tab with encryption and Region information

5. From the Region list on the following page, select Frankfurt (eu-central-1). Then, choose Add Region.

The Region list shows Regions enabled by default where the customer-managed KMS key was replicated, making them available for you to choose.



Figure 2: Choose an AWS Region to add

6. You’ll return to the Settings for Identity Center page, where you’ll see the new Region with a Replicating status. A blue banner indicates that Identity Center is replicating your workforce identities, configuration, and metadata to the new Region. After the initial setup (15–30 minutes, depending on the size of your Identity Center instance), future changes replicate within seconds.


Figure 3: Initial replication to the newly added Region in progress

7. After replication completes, the Replication Status column changes to Replicated. Your Identity Center endpoints in the additional Region are now active.


Figure 4: A console view after the initial replication is done

8. Users can now access AWS accounts through both AWS access portal URLs. You can view and copy the enabled portal URLs either from the Region list or by choosing View AWS access portal URLs.

You can view Security Assertions Markup Language (SAML) information, such as ACS URLs, about the primary and additional Regions by choosing View ACS URLs. In the next section you will use both, your AWS access portal URLs and ACS URLs to update your external IdP configuration.

You’ve successfully replicated your Identity Center instance to the Frankfurt (eu-central-1) Region. This means your workforce identities are now available in that additional Region and can use the new AWS access portal endpoint. Identity Center supports two authentication flows: one where users start from the AWS access portal or AWS managed application (service provider-initiated), and one where users start from their IdP portal (IdP-initiated). With service provider-initiated authentication, when users attempt to authenticate, Identity Center redirects them to your IdP authentication page, and after successful authentication, their authentication response is sent to the Regional SAML assertion consumer service (ACS) endpoint in Identity Center. The ACS endpoint in the additional Region uses a different URL than the primary Region, as shown in the following image.

Figure 5: Identity Center URLs

Currently, your IdP only has information about your Identity Center in the primary Region. To successfully redirect users’ authentication responses to the additional Region, you must add the new Regional endpoint to the IdP configuration.

Update the Identity Center application in your IdP:

This update enables service provider-initiated authentication to succeed. In the Identity Center app within your external IdP, add the ACS URL for the additional Region so that the app contains both Regional ACS URLs. Keep the existing URL as the first one in the list, the IdP uses the first URL as the default redirect target for IdP-initated authentication. The additional ACS URL will be used by the IdP to send the authentication response when users sign in using service provider-initiated authentication flows.

As an example, follow the instructions to configure your Identity Center application in Okta:

1. Log in to the Okta portal as an Admin.
2. Expand the Applications drop-down in the left pane, then choose Applications
3. Choose your Identity Center Application
4. Select the Sign-on tab and choose Edit in the Settings windows.
5. In the AWS SSO ACS URL1 box add the additional ACS URL

Figure 6: Identity Center enterprise application configuration in Okta

Users can now access accounts starting from the Region-specific AWS access portal, in this case they need to remember two Region specific URLs, one for Frankfurt (eu-central-1) and one for N. Virginia (us-east-1). To accommodate these Region-specific portal URLs, we recommend creating a bookmark application in your IdP. While users can also bookmark the URLs directly in their browsers, providing a bookmark app makes the additional Region discoverable in the IdP portal without requiring each user to manually save a URL.

This bookmark app functions like a browser bookmark and contains only the URL to the AWS access portal in the additional Region. Users can access this bookmark app from their IdP portal to reach the Region-specific AWS access portal. You also must grant your users access to the bookmark app in the external IdP. In Okta, follow the instructions below:

1. Log in to the Okta portal as an Admin.
2. Expand the Applications drop-down in the left pane, then choose Applications.
3. Choose Browse App Catalog
4. Search for “Bookmark App”, select it from the list of results, and choose Add in the left pane.
5. Choose an app name. For this blog post, the name can be “Identity Center – Frankfurt (eu-central-1)”
6. In the URL box, paste the Frankfurt (eu-central-1) specific URL
7. Choose Done. You will be redirected to the Bookmark application in the Assignments tab.
8. Choose Assign and select the Groups/People that will have access to this application.

After completing this configuration, users will see two Identity Center applications in their IdP portal—one for the primary Region and another for the additional Region.
Figure 7 shows how this configuration appears in the Okta end user dashboard.

Figure 7: Okta end-user portal with two Region-specific tiles for Identity Center

If you choose the newly created bookmark app, it will direct you to the AWS access portal in the additional Region.

Note: Identity Center supports IPv4-only endpoints, and dual-stack endpoints that support both IPv6 and IPv4. Depending on where your organization is in the process of IPv6 adoption, you will need to configure corresponding Assertion Consumer Service (ACS) URLs in your external IdP and used the corresponding AWS access portal URLs in your IdP bookmark application. For more information, see IPv6 support in Identity Center blog.

In the previous sections, you finished configuring the requirements for Identity Center multi-Region replication between the primary N. Virginia (us-east-1) and additional Frankfurt (eu-central-1) Regions. With this configuration complete, users with sufficient permissions can now enable supported AWS managed applications in either Region. Additionally, users can access their AWS accounts through the AWS access portal from either Region. To validate both capabilities, you will first test AWS account access from the additional Region and then configure a supported AWS managed application in that Region.

Permission set assignment that exists in the primary Region of your Identity Center instance will be replicated to your additional Region. This means that, if there is a service disruption in Identity Center in the primary Region, you can switch to the additional Region to access your AWS accounts through the access portal or AWS CLI. To complete this section, your user in Identity Center needs existing access to an AWS account with permission sets. For more information see Manage AWS accounts with permission sets.

1. Open the IAM Identity Center console.
2. In the navigation pane, choose Settings.
3. Choose the Management tab.
4. Choose View AWS access portal URLs.
5. Choose additional Region URL, a new browser tab will open with the AWS access portal in Frankfurt (eu-central-1).
6. Confirm you can see permission sets assigned to you.
7. Choose a permission set, confirm that you can access your AWS account.

AWS Command Line Interface (AWS CLI) connects to a specific Identity Center Region to authenticate users and obtain credentials. For customers using multi-Region replication, we recommend creating multiple Regional CLI profiles—one for your primary Region and another for each additional Region. Separate profiles allow you to quickly switch between Regions during a disruption without reconfiguring your CLI. Before completing this section, confirm that AWS CLI version 2.x or later is installed and that you have an existing AWS CLI configuration file.
To facilitate Region-specific access through the AWS CLI, create two CLI profiles using the following configuration:

1. Open your AWS CLI configuration file at ~/.aws/config.
2. Add the following two profiles configurations, one per additional Region. The example below shows a user in Virginia using N. Virginia (us-east-1) as their primary Identity Center Region with Frankfurt (eu-central-1) as a backup. Replace with your actual Identity Center instance ID and with your account number. To find your Identity Center instance ID, navigate to IAM Identity Center console, Settings, Instance ARN (the instance ID is the value that starts with ‘ssoins-‘)
3. Save the file.

   [profile ReadOnly]
   sso_role_name=ReadOnly
   sso_account=<account-Id>
   sso_session=us-east-1
   
   [sso-session us-east-1]
   sso_region=us-east-1
   sso_start_url=https://identitycenter.amazonaws.com/ssoins-<instance-Id>
   
   [profile ReadOnly-additional]
   sso_role_name=ReadOnly
   sso_account=<account-Id>
   sso_session=eu-central-1
   
   [sso-session eu-central-1]
   sso_region=eu-central-1
   sso_start_url=https://identitycenter.amazonaws.com/ssoins-<instance-Id>
   

Once the profiles have been configured, you can authenticate to each regional Identity Center endpoint independently using the following commands.
1. Run aws sso login –profile ReadOnly to log in through your primary Region N. Virginia (us-east-1),
2. Run aws sso login –profile ReadOnly-additional to log in through your additional Region Frankfurt (eu-central-1)

Each command opens a browser window to the corresponding regional AWS access portal, where you complete the authentication flow. After a successful login, the AWS CLI uses the credentials obtained from that Region for subsequent API calls made with that profile.

To test application deployment in the additional Region, for this blog post you will configure AWS Deadline Cloud, a managed service for rendering and visual effects workloads. You can choose other AWS managed applications that support deployment in additional Identity Center Regions — see the AWS managed applications that you can use with IAM Identity Center table in the documentation. This table is regularly updated as additional applications become available.
To configure AWS Deadline Cloud, follow the steps:

1. Navigate to the AWS Deadline Cloud console and switch to your additional Region—for this example, Frankfurt (eu-central-1).
2. Choose Set up Deadline Cloud on the Get Started section and follow the configuration wizard until Step 2: Set up monitor.
3. In the Set up monitor screen, enter a name (for example, Frankfurtmonitorapp), then expand the Additional monitor settings menu. Notice how the Identity Center instance in Frankfurt (eu-central-1) is automatically selected by the AWS DeadLine Cloud wizard. Choose Next.
4. On Define farm details, under Groups and users, select the group that will have access to the application, verify you are a member of that group. Notice how you can automatically choose groups that were synced from your IdP into your Identity Center instance.
5. For this demonstration, leave remaining configurations with their default values and complete the application setup by following the wizard. After the application deployment is complete, choose Go to dashboard.

The application is now configured to use Region-local Identity Center service APIs for user sign-in and access to workforce identities. The dashboard displays the option to manage users, and user assignment management for this application is performed through the Frankfurt (eu-central-1) Region.

You can test user access to AWS Deadline Cloud by choosing Monitor in the upper right-hand corner of the dashboard. This initiates the service provider authentication workflow, which redirects you to your IdP for authentication. Because your IdP now recognizes the Frankfurt (eu-central-1) ACS URL, it knows where to send the successful authentication response, and you are authorized to access the newly created application.

You can also access the application using the application provided endpoint or through your AWS access portal. The AWS access portal in each Region displays the applications assigned to the user independent of the Region they are configured.

If Frankfurt (eu-central-1) hasn’t been added to your Identity Center instance, the application console will detect your organization instance in N. Virginia (us-east-1), and prompt you to enable Frankfurt (eu-central-1) first.

Figure 8: AWS Deadline cloud console wizard when Identity Center isn’t configured in the current Region

Note: Existing deployments of AWS managed applications that use cross-Region calls with Identity Center (for example, Amazon Q Business) continue to function normally. When deploying an AWS managed application that supports cross-Region calls, we recommend configuring it to use Identity Center in the same Region, provided the prerequisites are met. Otherwise, you can configure the application to use Identity Center from one of its enabled Regions. See the respective AWS application’s User Guide to learn if it supports cross-Region calls to Identity Center.

Identity Center provides Regional endpoints for the AWS access portal when you enable multi-Region replication. You can access these Regional instances directly, or you can build a redirection system that intelligently routes users to the nearest available AWS access portal endpoint with failover capabilities.

For a serverless implementation of automatic failover, you can combine several AWS services:

• Amazon Route 53: Manages DNS routing with health checks and geoproximity-based routing policies to redirect users to their nearest Regional endpoint.
• Amazon Application Recovery Controller (ARC): Orchestrates failover logic and provides readiness checks to ensure smooth transitions between Regions during service disruptions.
• Application Load Balancer (ALB): Performs simple HTTP redirects to the appropriate Regional AWS access portal endpoints based on routing decisions.

This setup redirects users to a healthy endpoint in another Region if the primary Region goes down. Geoproximity routing sends users to their nearest endpoint under normal conditions.

The primary Region is the central management hub for instance-level configurations, while additional Regions provide Region-local application management and access capabilities. Application management is always performed in the Region where the application was configured.

This table shows the availability of use cases between Regions. The primary Region maintains centralized control over identity and access management, while additional Regions focus onRegion-specific application management and providing resilient access to AWS accounts.

In this post, you learned how to extend your access to AWS through IAM Identity Center across multiple AWS Regions using multi-Region replication. To replicate your Identity Center instance to additional Regions, you need a multi-Region KMS key, updated IdP configuration, and network access to the new regional endpoints.

With multi-Region replication in place, your users gain resilient, low-latency access to AWS accounts and AWS managed applications through Region-specific AWS access portals. If a disruption occurs in the primary Region, users can continue working using already provisioned permissions through any additional Region. For organizations looking to deploy AWS managed applications beyond Deadline Cloud in additional Regions, consult the AWS managed applications that integrate with IAM Identity Center table in the Identity Center User Guide to verify that the application supports both customer-managed KMS keys and deployment in additional Regions before proceeding.

To explore the full range of IAM Identity Center multi-Region capabilities, including quota management, visit the Using IAM Identity Center across multiple AWS Regions user guide.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.