From 65a1490ad053782ea18d4bd6a715fe006547e723 Mon Sep 17 00:00:00 2001
From: Ben <93559326+AI-redteam@users.noreply.github.com>
Date: Thu, 23 Oct 2025 13:24:27 -0500
Subject: [PATCH] Update README to clarify policy tightening process

Clarified the process of tightening the policy after deployment and the implications for defenders.
---
 .../aws-post-exploitation/aws-mwaa-post-exploitation/README.md  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-mwaa-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-mwaa-post-exploitation/README.md
index 1c86f673e..86d86f7fc 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-mwaa-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-mwaa-post-exploitation/README.md
@@ -30,7 +30,7 @@ Because the underlying SQS queues are provisioned by AWS in a separate, AWS-cont
 
 This policy is present in both the "Sample policy for a customer-managed key" and "Sample policy for an AWS-owned key" in the official AWS MWAA documentation.
 
-Crucially, this configuration is **mandatory for the service to operate**. Any attempt to tighten this policy, for example by removing the wildcard \* from the account ID or restricting the SQS actions, will cause the MWAA environment to fail. The scheduler will be unable to queue tasks for the workers, effectively breaking the entire workflow orchestration service. This leaves defenders with no direct IAM-based method to fix the vulnerability without disabling the service.
+Crucially, this configuration is **mandatory for the service to operate**. Any attempt to tighten this policy before deployment, for example by removing the wildcard \* from the account ID or restricting the SQS actions, will cause the MWAA environment to fail. The scheduler will be unable to queue tasks for the workers, effectively breaking the entire workflow orchestration service. But, it can be tightened after creation by hardcoding the Account ID. This leaves defenders with no direct IAM-based method to fix the vulnerability without the need to engage in a risky manual step that bypasses CI/CD pipelines and requires extra effort.
 
 ### **Why This is a Security Risk**