Minor update to data encryption bang box

website/content/docs/concepts/security/data-encryption.mdx

@@ -35,17 +35,17 @@ The current scoped DEKs and their purposes are detailed below:
 ~> Management of these keys is handled entirely internally; the information
 provided in this section is purely for informational purposes.
 
-* `database`: This is the general-purpose DEK used to encrypt sensitive or
-secret values within the database.
+- `database`: This is the general-purpose DEK used to encrypt sensitive or
+  secret values within the database.
 
-* `oplog`: This is used for encrypting oplog (operation log) values for the
-given scope.
+- `oplog`: This is used for encrypting oplog (operation log) values for the
+  given scope.
 
-* `tokens`: This is used for encrypting tokens generated by auth methods within
-the given scope.
+- `tokens`: This is used for encrypting tokens generated by auth methods within
+  the given scope.
 
-* `sessions`: This is used as a base key against which to derive
-session-specific encryption keys.
+- `sessions`: This is used as a base key against which to derive
+  session-specific encryption keys.
 
 ## The `worker-auth` KMS Key
 
@@ -75,9 +75,9 @@ On the client side, a user can use the `-recovery-config` flag with any
 operation on the CLI to specify a configuration file containing a suitable `kms`
 block. This functionality is also accessible via the Go SDK.
 
-~> This mechanism cannot be used to authorize a session, as there is no user
-information attached to these requests. Requests authorized via this mechanism
-will show a user of `u_recovery`.
+~> Requests authorized via this mechanism will show a user of `u_recovery`. This
+mechanism _cannot_ be used to authorize a session, as there is no uniquely
+identifying user information available.
 
 There are some other situations where this mechanism can be useful. For example,
 it is possible to use this mechanism, along with some defaults in the Terraform