diff --git a/site/content/en/contributions/design/wasm-extension.md b/site/content/en/contributions/design/wasm-extension.md
index 26f9a10ca27a..a4021b733080 100644
--- a/site/content/en/contributions/design/wasm-extension.md
+++ b/site/content/en/contributions/design/wasm-extension.md
@@ -19,31 +19,43 @@ Google Container Registry, and Amazon Elastic Container Registry, to Envoy proxi
 Envoy lacks native OCI image support, therefore, EG needs to download Wasm modules from OIC registries, 
 cache them locally in the file system, and serve them to Envoy over HTTP.
 
-**HTTP Code Source:** For HTTP code source, we have two options: serve Wasm modules directly from their 
+#### HTTP Code Source
+
+For HTTP code source, we have two options: serve Wasm modules directly from their 
 original HTTP URLs, or cache them in EG (as with OCI images). Caching both the HTTP Wasm modules and OCI 
 images inside EG can make UI consistent, for example, sha256sum can be calculated on the EG side and made 
 optional in the API. This will also make the Envoy proxy side more efficient as it won’t have to download the
 Wasm module from the original URL every time, which can be slow.
 
-**Memory Optimization:** Since we cache Wasm modules in the file system, we can optimize the memory usage 
+#### Memory Optimization
+
+Since we cache Wasm modules in the file system, we can optimize the memory usage 
 of the cache and the HTTP server to avoid introducing too much memory consumption by this feature. 
 For example, when receiving a Wasm pulling request form the Envoy, we can open the Wasm file and write 
 the file content directly to response, and then close the file. There won’t be significant caching involved. 
 However, we need to balance the memory usage and the efficiency, which could be addressed in implementation.
 
-**Caching Mechanism:** Cached files will be evicted based on LRU（Last recently used）algorithm. 
+#### Caching Mechanism
+
+Cached files will be evicted based on LRU（Last recently used）algorithm. 
 If the image’s tag is latest, then they will be updated periodically. The cache clean and update periods 
 will be configurable.
 
-**Authn & Authz:** 
-* To prevent unauthorized proxies from accessing the Wasm modules, the communication between the Envoy and EG will be 
+#### Restrict Access to Private Images
+
+* **Client Authn with MTLS:** To prevent unauthorized proxies from accessing the Wasm modules, the communication between the Envoy and EG will be 
   secured using mutual TLS.
-* To prevent unauthorized access to the Wasm modules, the user who creates the EEP must have the appropriate permissions 
-  to access the OCI registry. For example, if two users create EEPs in different namespaces (ns1, ns2) accessing the same
-  OCI image, each must also create a unique secret with registry credentials (secret1 for user1 in ns1, secret2 for user2 in ns2).
-  EG will validate the provided secret against the OCI registry before serving the Wasm module to the target HTTPRoute/Gateway of that EEP.
-* To prevent unauthorized access to the Wasm modules, the download URL will be appended with a generated secret suffix 
-  that can be validated by the EG.
+* **User Authn with Registry Credentials:** To prevent unauthorized users from accessing the Wasm modules, the user who creates the EEP must have the appropriate 
+  permissions to access the OCI registry. For example, if two users create EEPs in different namespaces (ns1, ns2) accessing 
+  the same OCI image, each must also create a unique secret with registry credentials (secret1 for user1 in ns1, secret2 
+  for user2 in ns2). EG will validate the provided secret against the OCI registry before serving the Wasm module to the
+  target HTTPRoute/Gateway of that EEP.
+* **Unguessable Download URLs:** It's possible that users who have no permission to access a private OCI image could create
+  EEPs to bypass the EG permission check. For example, a user could create an EEP, inject a Wasm filter, and put the download
+  URL of a private OCI image in the Wasm filter configuration. To prevent this, we need to make the download URL unguessable. 
+  The download URL will be generated by EG and will be a random string that is impossible to guess. If a user can get the 
+  config dump the Envoy Proxy, they can still get the download URL. However, they won’t be able to do so without 
+  the permission to access the config dump of Envoy Proxy, which is a more restricted permission (usually Admin role).
 
 ## Alternative Considered