diff --git a/docs/extend/plugins_authorization.md b/docs/extend/plugins_authorization.md
index 2380d370db11..d887a30a6d46 100644
--- a/docs/extend/plugins_authorization.md
+++ b/docs/extend/plugins_authorization.md
@@ -74,11 +74,14 @@ The sequence diagrams below depict an allow and deny authorization flow:
 Each request sent to the plugin includes the authenticated user, the HTTP
 headers, and the request/response body. Only the user name and the
 authentication method used are passed to the plugin. Most importantly, no user
-credentials or tokens are passed. Finally, not all request/response bodies
-are sent to the authorization plugin. Only request/response bodies where
-the `Content-Type` is `application/json` are sent to the authorization plugin;
-bodies of any other `Content-Type` are not visible to the plugin and cannot
-be used for enforcement, even though the daemon may still act on this data.
+credentials or tokens are passed.
+
+> [!NOTE]
+> Authorization plugins enforce requests to the Docker daemon's HTTP API only. gRPC method
+> calls, whether dispatched natively or upgraded through `POST /grpc`, are not subject to authorization.
+> Furthermore, HTTP request/response bodies where the `Content-Type` is `application/json` are forwarded;
+> bodies of any other type are not visible to the plugin and cannot be used for enforcement,
+> even though the daemon acts on this data.
 
 For commands that can potentially hijack the HTTP connection (`HTTP
 Upgrade`), such as `exec`, the authorization plugin is only called for the