@@ -6,15 +6,15 @@ fix(cloud-connection)!: a runtime holding the environment service key is platfor
 
 A runtime whose control-plane credential is the environment service key (`controlPlaneApiKey`, or `OS_CLOUD_API_KEY`, which the cloud sets on the environments it hosts) is connected by the platform, not by anyone on the runtime. It still registered the Cloud Connection page in Setup's Apps group, which read "Connected" and offered Disconnect. Disconnecting there cleared the runtime's stored device credential while the service key stayed in use, so the page went on reading "Connected", and the control plane was asked to revoke a connection the platform had made.
 
-Such a runtime now registers neither the page nor its navigation entry, and says so once at boot. A request to disconnect it is refused with `409` and `RESOURCE_CONFLICT`, after the sign-in and Setup Access checks and before anything is revoked or cleared. The message says the platform manages the connection.
+Such a runtime now registers neither the page nor its navigation entry, and says so once at boot. A request to disconnect it is refused with `409` and `RESOURCE_CONFLICT`, after the sign-in and capability checks and before anything is revoked or cleared. The message says the platform manages the connection.
 
-A self-hosted or local runtime, connected through the device-code flow, keeps the page and its disconnect unchanged. Its Cloud Connection entry moves from the Apps group to the Integrations group, after Webhooks, Datasources and Connect an Agent. That group requires `manage_platform_settings`, so a user who holds Setup Access without it, such as an organization administrator, no longer sees the entry. The connect and disconnect requests still take Setup Access alone.
+A self-hosted or local runtime, connected through the device-code flow, keeps the page and its disconnect unchanged. Its Cloud Connection entry moves from the Apps group to the Integrations group, after Webhooks, Datasources and Connect an Agent. That group requires `manage_platform_settings`, so a user who holds Setup Access without it, such as an organization administrator, no longer sees the entry.
 
 Clause-②: no (narrowing)
 
 <!-- adr-0087: not-required (no-migration-prescription) No metadata moves: no spec key, authorable spelling, object definition or stored shape is added, removed, renamed or re-shaped, and no exported declaration is removed or narrowed, so there is nothing for `objectstack migrate meta` to rewrite. What changes is what a runtime holding the environment service key serves: it no longer registers the Cloud Connection page or its navigation entry, and it refuses a disconnect it used to carry out. The navigation entry's new group is a value inside an exported constant whose type is unchanged. The other categories are closed on facts: the package publishes (not unpublished); no ADR-0087 id is named or touched (not registered or already-registered); and nothing exported is removed or narrowed (not runtime-interface-only, type-surface-only or runtime-export-retired). -->
 
 **BREAKING** (on a runtime holding the environment service key, a disconnect request it carried out is now refused, and the Cloud Connection page and its navigation entry are no longer served), shipped as `minor` under the launch-window convention for breaking changes.
 
-- **Unchanged:** a runtime without the service key, apart from the entry's group. The connection status answer is unchanged on every runtime.
+- **Unchanged:** a runtime without the service key, apart from the entry's group and the permission its connect and disconnect requests and its connection details require, which another change in this release raises to `manage_platform_settings`. The connection status answer is otherwise unchanged on every runtime.
 - **Nothing to rewrite:** a cloud-hosted environment's connection is the platform's to manage. A self-hosted server leaves `OS_CLOUD_API_KEY` unset, as the deployment guide says; one that sets it is platform-managed by this rule.
@@ -0,0 +1,22 @@
+---
+'@objectstack/cloud-connection': patch
+---
+
+fix(cloud-connection)!: one rule for the Cloud Connection capability — the page's record and its three connection-changing requests require `manage_platform_settings`, like its Setup entry; a server holding the environment service key also refuses `bind/start` and `bind/poll`
+
+Clause-②: no (narrowing)
+Metadata-protocol: none
+
+<!-- adr-0087: not-required (no-migration-prescription) No metadata moves: no spec key, authorable spelling, object definition or stored shape is added, removed, renamed or re-shaped, and no exported declaration is removed or narrowed, so there is nothing for `objectstack migrate meta` to rewrite. What changes is which signed-in callers the Cloud Connection routes serve: the capability they read moves from `setup.access` to `manage_platform_settings`, and a server holding the environment service key refuses two more of them. The navigation entry's added `requiredPermissions` is a value inside an exported constant whose type is unchanged. -->
+
+**BREAKING** (a signed-in user who holds Setup Access, `setup.access`, without Manage Platform Settings, `manage_platform_settings`, such as an organization administrator under the default permission sets, can no longer connect or disconnect the server, and is no longer served the connection's details), shipped as `patch`: the change is to which callers the routes serve, not to the metadata protocol.
+
+The Cloud Connection page's Setup entry sits in the Integrations group, which requires `manage_platform_settings`. The page's routes still took `setup.access` alone, so an organization administrator, whose default permission set carries Setup Access but not Manage Platform Settings, was not shown the entry but could open the page by its address and connect or disconnect the server. One rule now covers the entry, the page and the routes:
+
+- **Refused now:** `POST /api/v1/cloud-connection/bind/start`, `POST /api/v1/cloud-connection/bind/poll` and `POST /api/v1/cloud-connection/unbind` answer a signed-in user who does not hold `manage_platform_settings` with `403` and the standard `PERMISSION_DENIED` code, and the message names that capability. Holding `setup.access` is no longer enough. The refusal still comes before any call to the cloud and before the stored credential is touched.
+- **Narrowed now:** `GET /api/v1/cloud-connection/status` serves `environmentId` and `connection` only to a user who holds `manage_platform_settings`. Every other caller, an organization administrator included, is served `bound`, `runtimeId` and `provider`, as an anonymous caller is.
+- **Declared on the entry:** the Cloud Connection navigation entry now declares `requiredPermissions: ['manage_platform_settings']` itself, the capability its group already required, so the entry and the routes read one rule from this package. The page carries no permission key of its own (a page has none); what it shows is served by these routes.
+- **Refused on a platform-managed server:** a server holding the environment service key (`controlPlaneApiKey`, or `OS_CLOUD_API_KEY`) already refused `unbind` with `409` and `RESOURCE_CONFLICT`. It now refuses `bind/start` and `bind/poll` the same way, after the sign-in and capability checks and before any call to the cloud or any write to the stored credential. A device connection completed there used to store a credential the service key always overrode, while presenting that key to the cloud, which could move the environment's cloud-side connection record. The message now says the connection cannot be connected or disconnected here, and that nothing was sent to the cloud and nothing was stored or cleared.
+- **Unchanged:** a user who holds `manage_platform_settings`, which the default platform-administrator permission set carries, is served exactly as before on a server without the service key. Anonymous callers still get `401`, and a session the authentication policy is holding still gets its `403`. The device-code flow's steps, the status answer for a permitted caller, and the four other session routes (`install`, `installation`, `installed`, `org-packages`) are unchanged.
+
+**Who acts:** a deployment that relies on organization administrators, or another set holding only Setup Access, to connect its server grants `manage_platform_settings` to those users, through a permission set or a position, and they are served as before.
@@ -59,9 +59,10 @@ needs no sign-in, and a `200` means the plugin is mounted.
 **The server does not hold the environment service key.** A server that holds
 `OS_CLOUD_API_KEY` (the cloud sets it on every environment it hosts) is
 connected by the platform, not from Setup. It registers no Cloud Connection page
-or Setup entry, says so once in its boot log, and refuses a disconnect with
-`409` (`RESOURCE_CONFLICT`): nothing is revoked and nothing is cleared. A
-self-hosted server leaves `OS_CLOUD_API_KEY` unset.
+or Setup entry, says so once in its boot log, and refuses the connect and
+disconnect requests with `409` (`RESOURCE_CONFLICT`): nothing is sent to the
+cloud, and nothing is stored or cleared. A self-hosted server leaves
+`OS_CLOUD_API_KEY` unset.
 
 **The server can reach the cloud.** Every call to the cloud is made by the
 server, not by your browser: the code request, the polling, the connection
@@ -78,18 +79,28 @@ the server reads as not connected until you connect it again.
 
 **The right people on each side.**
 
-- *On the server*, you sign in with a user of this server. The Cloud
-  Connection page is in the Setup app, which takes the **Setup Access**
-  permission (`setup.access`); the default platform-administrator and
-  organization-administrator permission sets carry it. The connect and
-  disconnect requests take the same permission: a signed-in user without
-  Setup Access is refused with `403` (`PERMISSION_DENIED`) before the server
-  calls the cloud. The page's Setup entry sits in the **Integrations** group,
-  which Setup shows only to users who also hold `manage_platform_settings`; the
-  default platform-administrator permission set carries both. A session
-  that the authentication policy is holding (an expired password, or
-  multi-factor sign-in required but not yet set up) is refused with `403`
-  until it is fixed.
+- *On the server*, you sign in with a user of this server who holds the
+  **Manage Platform Settings** permission (`manage_platform_settings`); the
+  default platform-administrator permission set carries it. One rule covers
+  the whole Cloud Connection page:
+  - Its Setup entry sits in the **Integrations** group, which Setup shows only
+    to users who hold that permission.
+  - The connect and disconnect requests take the same permission: a signed-in
+    user without it is refused with `403` (`PERMISSION_DENIED`) before the
+    server calls the cloud.
+  - The connection's details (the approving account, the organization, the
+    environment) are served only to users who hold it. Anyone else who opens
+    the page by its address is shown only whether the server is connected and
+    its runtime id, and the panel's **Connect** or **Disconnect** button is
+    refused with the message listed under [Connect](#connect).
+
+  Setup Access (`setup.access`) alone is not enough. The default
+  organization-administrator permission set carries Setup Access but not
+  Manage Platform Settings, so an organization administrator can open Setup
+  but cannot connect or disconnect the server. A session that the
+  authentication policy is holding (an expired password, or multi-factor
+  sign-in required but not yet set up) is refused with `403` until it is
+  fixed.
 - *In the cloud*, the approval is made by whoever signs in to the cloud
   account behind the link and approves the request. The server records that
   account's email as **Approved by**. Which cloud accounts may approve, and
@@ -135,6 +146,7 @@ button:
 | *The connection request was denied. Start again.* | The cloud answered `access_denied`. |
 | *Device authorization failed: …* | The cloud ended the request with another error, named after the colon. |
 | *Sign in to connect a cloud account.* (or *Sign in.* while waiting) | Your session on the server has ended. |
+| *Managing this runtime's cloud connection requires the `manage_platform_settings` capability.* | You are signed in without Manage Platform Settings (see [Before you start](#before-you-start)). |
 | *No cloud control plane configured.* | The plugin is mounted without a control-plane URL. |
 | a network error such as *fetch failed* | The server could not reach the cloud. |
 
@@ -216,14 +228,19 @@ account afterwards.
 
 ## Reference [#reference]
 
-The routes the Cloud Connection page uses, all on the server's own origin:
+The routes the Cloud Connection page uses, all on the server's own origin. The
+three that change the connection (`bind/start`, `bind/poll` and `unbind`)
+require Manage Platform Settings (`manage_platform_settings`) and answer `403`
+(`PERMISSION_DENIED`) to a signed-in user without it. On a server holding
+`OS_CLOUD_API_KEY`, the same three answer `409` (`RESOURCE_CONFLICT`) to a user
+who holds it, and nothing changes.
 
 | Route | Sign-in | What it does |
 |:---|:---|:---|
-| `GET /api/v1/cloud-connection/status` | not required | Every caller gets `bound`, `runtimeId` and `provider`. A signed-in user with Setup Access (`setup.access`) also gets `environmentId` and `connection`, the connection as the cloud reports it (the approving account and the organization). `bound` is `true` whenever the server holds a credential; `connection` is `null` when the cloud cannot be reached. |
+| `GET /api/v1/cloud-connection/status` | not required | Every caller gets `bound`, `runtimeId` and `provider`. A signed-in user with Manage Platform Settings (`manage_platform_settings`) also gets `environmentId` and `connection`, the connection as the cloud reports it (the approving account and the organization). `bound` is `true` whenever the server holds a credential; `connection` is `null` when the cloud cannot be reached. |
 | `POST /api/v1/cloud-connection/bind/start` | required | Asks the cloud for a device code; answers with `user_code`, `verification_uri`, `verification_uri_complete`, `interval`, `expires_in`. |
 | `POST /api/v1/cloud-connection/bind/poll` | required | Body `{ "device_code": "…" }`. Answers `{ "pending": true }` while the cloud waits for approval, and the connection once it is approved. |
-| `POST /api/v1/cloud-connection/unbind` | required | Disconnects; answers `{ "revoked", "cleared" }`. On a server holding `OS_CLOUD_API_KEY`, refused with `409` (`RESOURCE_CONFLICT`) and nothing changes. |
+| `POST /api/v1/cloud-connection/unbind` | required | Disconnects; answers `{ "revoked", "cleared" }`. |
 
 The settings that shape the flow are listed in
 [Environment variables](/docs/deployment/environment-variables#multi-tenant--cloud-control-plane):
@@ -232,7 +249,8 @@ id the server presents (default `objectstack-cli`), and `OS_RUNTIME_VERSION`
 sets the version it reports. `OS_CLOUD_API_KEY` and `OS_ENVIRONMENT_ID` belong
 to cloud-hosted runtimes; a self-hosted server leaves both unset. A set
 `OS_CLOUD_API_KEY` is used instead of the stored credential, and makes the
-connection platform-managed: no Cloud Connection page, and no disconnect.
+connection platform-managed: no Cloud Connection page, and no connect or
+disconnect.
 
 The Setup app itself, and how plugins add entries to it, is described in
 [Setup app](/docs/ui/setup-app). Running the server is covered in