[Docs] Document connection access control in environments

content/en/cloud/concepts/identity-and-security/_index.md

@@ -57,7 +57,7 @@ It is tempting to assume that organization membership alone decides what a user
 
 * **Authentication — the organization's connected identity provider (IdP).** Each organization is connected to an identity provider that establishes *who* a user is. More than one organization can — and commonly does — share the same identity provider. An organization may instead **bring its own** identity provider (BYOC), in which case it authenticates against its own dedicated provider. See [Identity Services]({{< ref "cloud/guides/self-hosted/planning/identity-services/index.md" >}}).
 * **Generic authorization — keys → keychains → roles.** Permission [keys]({{< ref "cloud/concepts/identity-and-security/keys.md" >}}) roll up into [keychains]({{< ref "cloud/concepts/identity-and-security/keychains.md" >}}), which are assigned to [roles]({{< ref "cloud/concepts/identity-and-security/roles/_index.md" >}}), which are assigned to users. This decides *what operations* a user may perform — and it is evaluated per organization. The same person can hold different roles, and therefore a different effective set of capabilities, in each organization they belong to.
-* **Granular access — resource-access mappings.** A specific resource (for example, a single design) can be shared with an individual user. These mappings grant access to that one resource and **deliberately cross organizational boundaries**: a user does not need to be a member of an organization to open a resource in it when a mapping grants that access. This is by design — it is what makes cross-organization collaboration possible.
+* **Resource sharing and access mappings (granular access to a specific resource).** A specific resource (for example, a single design) can be shared with an individual user. These mappings grant access to that one resource and **deliberately cross organizational boundaries**: a user does not need to be a member of an organization to open a resource in it when a mapping grants that access. This is by design — it is what makes cross-organization collaboration possible.
 
 The practical consequence is that the same human can be a member of several organizations and have a *different* set of capabilities in each, while also being able to reach individual shared resources in organizations they do not belong to at all.
 

content/en/cloud/concepts/spaces/environments.md

@@ -46,6 +46,14 @@ Credentials in an Environment are the keys to securely authenticate and access m
 
 > See "[Credentials](https://docs.meshery.io/concepts/logical/credentials)" in Meshery Docs for more information.
 
+## Access Control for Connections and Credentials
+
+Access to a Connection and therefore its associated Credentials is allowed if **any** of the following is true:
+
+1. **Direct ownership:** The Connection Owner (UserID) matches the current user's ID.
+
+2. **Indirect access:** The Connection is assigned to an Environment that is linked to a Workspace, and the current user is a member of a Team that has access to that Workspace. In other words, if a user is a member of a team that has access to a workspace that is linked to an environment containing the connection, then the user automatically inherits access control and authorization over the linked Environments, Connections, Credentials, Designs, and Views.
+
 ## Example: Orbital Labs Environment Setup
 
 The following illustrates how Five and Zara set up multi-cloud environments at Orbital Labs, spanning AWS, GCP, and Azure. See [Meet Five and the Cast]({{< ref "cloud/getting-started/meet-five/_index.md" >}}) for the full seed inventory.