Update content/vault/global/partials/policies/list-allowed-parameters.mdx

Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>

Author: bosouza

content/vault/global/partials/policies/list-allowed-parameters.mdx

@@ -14,11 +14,16 @@ For example, if you set `allowed_parameters` to `"X": ["A", "B"]`:
    even `"X": ["A"]`, because the parameter value does not
    **exactly** match one of the allowed values ("A" or "B").
 
-The same logic applies to `denied_parameters`: if it is set to `"Y": ["C", "D"]`,
-Vault **allows** a request with parameter `"Y": ["C", "D"]`, which can lead to
-unauthorized access if the intent was to deny any request that includes "C", "D"
-or both. As a result, we **strongly recommend** using `allowed_parameters` instead of
-`denied_parameters` for list parameters.
+The same logic applies to `denied_parameters`. If you create a policy with
+`denied_parameters` set to `"Y": ["C", "D"]`:
+
+- Vault only denies requests with parameter `"X": "C"` or `"X": "D"`.
+- Vault allows all other requests. For example, Vault allows requests with
+   parameter `"Y": ["C", "D"]`, which can lead to unauthorized access if you
+   intended to deny any request that included "C", "D", or both.
+
+As a result, we **strongly recommend** using `allowed_parameters`
+instead of `denied_parameters` for list parameters.
 
 Additionally, Vault v1.20 and earlier does not treat comma-separated strings in request
 parameters as lists when evaluating `allowed_parameters` and `denied_parameters`.