diff --git a/content/aws/exploitation/Misconfigured_Resource-Based_Policies/misconfigured_iam_role_trust_policy_wildcard_principal.md b/content/aws/exploitation/Misconfigured_Resource-Based_Policies/misconfigured_iam_role_trust_policy_wildcard_principal.md
index 06975093e..767095c8e 100644
--- a/content/aws/exploitation/Misconfigured_Resource-Based_Policies/misconfigured_iam_role_trust_policy_wildcard_principal.md
+++ b/content/aws/exploitation/Misconfigured_Resource-Based_Policies/misconfigured_iam_role_trust_policy_wildcard_principal.md
@@ -27,7 +27,7 @@ This policy typically looks like the following:
 }
 ```
 
-This policy would `Allow` anyone in the `111111111111` account the ability to perform the action `sts:AssumeRole` (assume the role).
+This policy would `Allow` anyone in the `111111111111` account the ability to perform the action `sts:AssumeRole` (assume the role), provided that they have the action in their IAM identity-based policy.
 
 As mentioned in our documentation on [Misconfigured Resource Based Policies](https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/#the-principal-and-risks), there are a variety of options that can be used for the `Principal` element, including, AWS accounts, specific IAM roles, role sessions, IAM users, and AWS services. Arguably the most risky is the "wildcard" `Principal`. This `Principal` encompasses __ALL__ AWS principals.