diff --git a/app/services/clusters/agents/authorizations/ci_access/refresh_service.rb b/app/services/clusters/agents/authorizations/ci_access/refresh_service.rb
index 047a0725a2c188751fb9d7e8193f153c9bdfcb95..305eec7f7caa1c59cc4f9b26446142ea05913be8 100644
--- a/app/services/clusters/agents/authorizations/ci_access/refresh_service.rb
+++ b/app/services/clusters/agents/authorizations/ci_access/refresh_service.rb
@@ -7,7 +7,7 @@ module CiAccess
         class RefreshService
           include Gitlab::Utils::StrongMemoize
 
-          AUTHORIZED_ENTITY_LIMIT = 100
+          AUTHORIZED_ENTITY_LIMIT = 500
 
           delegate :project, to: :agent, private: true
           delegate :root_ancestor, to: :project, private: true
diff --git a/app/services/clusters/agents/authorizations/user_access/refresh_service.rb b/app/services/clusters/agents/authorizations/user_access/refresh_service.rb
index 4c3d059777addb66a87693821f23dda3349f02d9..ece49c936b1abc456f8ffc37b8ced2070c0ce505 100644
--- a/app/services/clusters/agents/authorizations/user_access/refresh_service.rb
+++ b/app/services/clusters/agents/authorizations/user_access/refresh_service.rb
@@ -7,7 +7,7 @@ module UserAccess
         class RefreshService
           include Gitlab::Utils::StrongMemoize
 
-          AUTHORIZED_ENTITY_LIMIT = 100
+          AUTHORIZED_ENTITY_LIMIT = 500
 
           delegate :project, to: :agent, private: true
           delegate :root_ancestor, to: :project, private: true
diff --git a/doc/user/clusters/agent/ci_cd_workflow.md b/doc/user/clusters/agent/ci_cd_workflow.md
index b540c459cdb4496714cacf5611459ebd3e2d3131..0b0e0a1d6c0a40139b751561218f3357806fb57d 100644
--- a/doc/user/clusters/agent/ci_cd_workflow.md
+++ b/doc/user/clusters/agent/ci_cd_workflow.md
@@ -18,6 +18,7 @@ DETAILS:
 > - Support for Linux package installations was [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5686) in GitLab 14.5.
 > - The ability to switch between certificate-based clusters and agents was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335089) in GitLab 14.9. The certificate-based cluster context is always called `gitlab-deploy`.
 > - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80508) from _CI/CD tunnel_ to _CI/CD workflow_ in GitLab 14.9.
+> - The [limit of agent connection sharing was raised](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149844) from 100 to 500 in GitLab 17.0
 
 You can use GitLab CI/CD to safely connect, deploy, and update your Kubernetes clusters.
 
@@ -80,7 +81,7 @@ To authorize the agent to access the GitLab project where you keep Kubernetes ma
 
    - Authorized projects must have the same root group or user namespace as the agent's configuration project.
    - You can install additional agents into the same cluster to accommodate additional hierarchies.
-   - You can authorize up to 100 projects.
+   - You can authorize up to 500 projects.
 
 All CI/CD jobs now include a `kubeconfig` file with contexts for every shared agent connection.
 The `kubeconfig` path is available in the environment variable `$KUBECONFIG`.
@@ -106,7 +107,7 @@ To authorize the agent to access all of the GitLab projects in a group or subgro
    - Authorized groups must have the same root group as the agent's configuration project.
    - You can install additional agents into the same cluster to accommodate additional hierarchies.
    - All of the subgroups of an authorized group also have access to the same agent (without being specified individually).
-   - You can authorize up to 100 groups.
+   - You can authorize up to 500 groups.
 
 All the projects that belong to the group and its subgroups are now authorized to access the agent.
 All CI/CD jobs now include a `kubeconfig` file with contexts for every shared agent connection.
diff --git a/doc/user/clusters/agent/user_access.md b/doc/user/clusters/agent/user_access.md
index 745ab0096e07132e51b2d297f58f66b27b5ae11d..8972dfa8f7fe5edb59d500ab059f5ac225a31009 100644
--- a/doc/user/clusters/agent/user_access.md
+++ b/doc/user/clusters/agent/user_access.md
@@ -14,6 +14,7 @@ DETAILS:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/390769) in GitLab 16.1, with [flags](../../../administration/feature_flags.md) named `environment_settings_to_graphql`, `kas_user_access`, `kas_user_access_project`, and `expose_authorized_cluster_agents`. This feature is in [Beta](../../../policy/experiment-beta-support.md#beta).
 > - Feature flag `environment_settings_to_graphql` [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124177) in GitLab 16.2.
 > - Feature flags `kas_user_access`, `kas_user_access_project`, and `expose_authorized_cluster_agents` [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125835) in GitLab 16.2.
+> - The [limit of agent connection sharing was raised](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149844) from 100 to 500 in GitLab 17.0
 
 As an administrator of Kubernetes clusters in an organization, you can grant Kubernetes access to members
 of a specific project or group.
@@ -39,8 +40,8 @@ To configure access:
 
 - In the agent configuration file, define a `user_access` keyword with the following parameters:
 
-  - `projects`: A list of projects whose members should have access.
-  - `groups`: A list of groups whose members should have access.
+  - `projects`: A list of projects whose members should have access. You can authorize up to 500 projects.
+  - `groups`: A list of groups whose members should have access. You can authorize up to 500 projects.
   - `access_as`: Required. For plain access, the value is `{ agent: {...} }`.
 
 After you configure access, requests are forwarded to the API server using