fixes links

Author: benironside

solutions/security/configure-elastic-defend/elastic-defend-feature-privileges.md

@@ -19,7 +19,7 @@ You can create user roles and define privileges to manage feature access in {{el
 To configure roles and privileges, find **Roles** in the navigation menu or by using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). For more details on using this UI, refer to [](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-role-management.md) for {{stack}}, or to [Custom roles](/deploy-manage/users-roles/cloud-organization/user-roles.md) for {{serverless-short}}.
 
 ::::{note}
-Starting with version 9.1, {{elastic-defend}}'s feature privileges can be assigned on a per-space basis. For information about how to apply permissions to particular spaces, refer to [Fleet roles and privileges](reference/fleet/fleet-roles-privileges.md).
+Starting with version 9.1, {{elastic-defend}}'s feature privileges can be assigned on a per-space basis. For information about how to apply permissions to particular spaces, refer to [Fleet roles and privileges](/reference/fleet/fleet-roles-privileges.md).
 ::::
 
 To grant access, select **All** for the **Security** feature in the **Assign role to space** configuration UI, then turn on the **Customize sub-feature privileges** switch.

solutions/security/get-started/spaces-elastic-security.md

@@ -16,7 +16,7 @@ products:
 {{elastic-sec}} supports the organization of your security operations into logical instances with the [spaces](../../../deploy-manage/manage-spaces.md) feature. Each space in {{kib}} represents a separate logical instance of {{elastic-sec}} in which detection rules, rule exceptions, value lists, alerts, Timelines, cases, and {{kib}} advanced settings are private to the space and accessible only by users that have role privileges to access the space. 
 
 ::::{note}
-Beginning with {{stack}} version 9.1, you can control user access to features in and managed by {{fleet}} (including {{elastic-defend}}) on a per-space basis. This granularity helps you fine-tune which components each user can access and which actions they can perform. To learn more, refer to [Fleet roles and privileges](reference/fleet/fleet-roles-privileges.md), and [{{elastic-sec}} requirements](elastic-security-requirements.md).
+Beginning with {{stack}} version 9.1, you can control user access to features in and managed by {{fleet}} (including {{elastic-defend}}) on a per-space basis. This granularity helps you fine-tune which components each user can access and which actions they can perform. To learn more, refer to [Fleet roles and privileges](/reference/fleet/fleet-roles-privileges.md), and [{{elastic-sec}} requirements](elastic-security-requirements.md).
 ::::
 
 For example, if you create a `SOC_prod` space in which you load and activate all the {{elastic-sec}} prebuilt detection rules, these rules and any detection alerts they generate will be accessible only when visiting the {{security-app}} in the `SOC_prod` space. If you then create a new `SOC_dev` space, you’ll notice that no detection rules or alerts are present. Any rules subsequently loaded or created here will be private to the `SOC_dev` space, and they will run independently of those in the `SOC_prod` space.