Update README to clarify policy tightening process

Clarified the process of tightening the policy after deployment and the implications for defenders.

Author: AI-redteam

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