docs: mark matching API and related features as alpha

api/envoy/config/common/matcher/v3/matcher.proto

@@ -22,7 +22,7 @@ option (udpa.annotations.file_status).package_version_status = ACTIVE;
 // As an on_no_match might result in another matching tree being evaluated, this process
 // might repeat several times until the final OnMatch (or no match) is decided.
 //
-// This API is a work in progress.
+// This API is currently considered experimental and is a work in progress.
 message Matcher {
   // What to do if a match is successful.
   message OnMatch {

api/envoy/extensions/common/matching/v3/extension_matcher.proto

@@ -18,6 +18,8 @@ option (udpa.annotations.file_status).package_version_status = ACTIVE;
 // Wrapper around an existing extension that provides an associated matcher. This allows
 // decorating an existing extension with a matcher, which can be used to match against
 // relevant protocol data.
+//
+// This API is currently considered experimental and is a work in progress.
 message ExtensionWithMatcher {
   // The associated matcher.
   config.common.matcher.v3.Matcher matcher = 1 [(validate.rules).message = {required: true}];

api/envoy/extensions/filters/http/composite/v3/composite.proto

@@ -26,6 +26,7 @@ option (udpa.annotations.file_status).package_version_status = ACTIVE;
 // :ref:`ExecuteFilterAction <envoy_api_msg_extensions.filters.http.composite.v3.ExecuteFilterAction>`)
 // which filter configuration to create and delegate to.
 //
+// This API is currently considered experimental and is a work in progress.
 message Composite {
 }
 

docs/root/configuration/http/http_filters/composite_filter.rst

@@ -3,6 +3,11 @@
 Composite Filter
 ================
 
+.. attention::
+
+   The composite filter is experimental and is currently under active development.
+   Capabilities will be expanded over time and the configuration structures are likely to change.
+
 The composite filter allows delegating filter actions to a filter specified by a
 :ref:`match result <arch_overview_matching_api>`. The purpose of this is to allow different filters
 or filter configurations to be selected based on the incoming request, allowing for more dynamic

docs/root/intro/arch_overview/advanced/matching/matching_api.rst

@@ -3,6 +3,11 @@
 Matching API
 ============
 
+.. attention::
+
+   The matching API is experimental and is currently under active development.
+   Capabilities will be expanded over time and the configuration structures are likely to change.
+
 Envoy makes use of a :ref:`matching API <envoy_v3_api_msg_config.common.matcher.v3.Matcher>`
 to allow the various subsystems to express actions that should be performed based on incoming data.
 

docs/root/intro/arch_overview/security/threat_model.rst

@@ -77,9 +77,10 @@ case, an extension will explicitly state this in its documentation.
 Core and extensions
 -------------------
 
-Anything in the Envoy core may be used in both untrusted and trusted deployments. As a consequence,
-it should be hardened with this model in mind. Security issues related to core code will usually
-trigger the security release process as described in this document.
+Anything in the Envoy core may be used in both untrusted and trusted deployments, with the exception
+of features explicitly marked as experimental. As a consequence, it should be hardened with this model
+in mind. Security issues related to core code will usually trigger the security release process as
+described in this document.
 
 The following extensions are intended to be hardened against untrusted downstream and upstreams:
 

source/extensions/filters/http/composite/BUILD

@@ -46,7 +46,7 @@ envoy_cc_extension(
     srcs = ["config.cc"],
     hdrs = ["config.h"],
     category = "envoy.filters.http",
-    security_posture = "robust_to_untrusted_downstream",
+    security_posture = "unknown",
     deps = [
         "//include/envoy/registry",
         "//include/envoy/server:filter_config_interface",