# Backend API 18.0.0

### New Features

* Shared Nested Folder Management — Create, nest (up to 5 levels), rename, color-code, remove, and permanently delete shared nested folders with role-based permission enforcement.
* Independent Folder Sharing & Permission Overrides — Nested subfolders support independent sharing permissions that can differ from their parent. Inherited permissions can be overridden at any level without affecting sibling or ancestor folders.
* Folder & Record Access Management — View which users and teams have access to a folder or record, and grant, revoke, or modify access with role-based permission checks.
* Record Lifecycle in shared nested subfolders — Create, view, edit, remove, and permanently delete records at the vault root and within shared nested folders, all governed by role-based permissions.
* Record Ownership Transfer — Record owners and managers can transfer ownership of a record to another user who then receives full ownership capabilities.
* Contextual Create — Creating a record or folder while inside a SharedFolder or shared nested folder automatically applies the correct permission model for that context.
* Keeper Secrets Manager (KSM) in shared nested folders — Users with KSM privileges can create and share KSM applications at the vault root or within shared nested folders.
* Passkey Platform Enforcement — Administrators can now limit which passkey platforms are accepted at the time of use, based on enforcement policies.

{% hint style="info" %}
Nested Folders are available with v18.0 of Vault client applications. Contact your customer success manager at Keeper to activate this feature on your tenant.
{% endhint %}

### Improvements

**KA-7317:** Improved error handling during passkey registration to return more detailed and actionable error messages when an invalid friendly name is provided. Users now receive clear feedback identifying the specific issue with their input, making it easier to correct and complete passkey setup.

**KA-8247:** Users can now create a shared nested folder at the vault root level. Folder creation is restricted to users with the appropriate role-based permission.

**KA-8248:** Users can create nested subfolders within the vault folders up to a maximum depth of five visible levels.

**KA-8249:** Nested subfolders can have different sharing permissions than their parent folder. Changes to a parent folder's access do not overwrite direct overrides set on child or grandchild folders.

**KA-8250:** Users with access-management permission can override inherited permissions on a subfolder to create a unique access configuration. The override is preserved even when the parent folder's permissions change.

**KA-8251**: Users with the appropriate permission can edit a shared nested folder's title and color. This keeps the folder hierarchy clearly organized and visually distinct.

**KA-8252:** Users with remove permission can remove a shared nested folder from its parent. The folder and its contents are not permanently deleted by this action.

**KA-8253:** Users with delete permission can permanently delete a shared nested folder and all of its contents. Unauthorized roles are blocked from performing this action.

**KA-8254:** Users can view the subfolder structure within a shared nested folder according to their access level. Only folders the user is permitted to see are displayed.

**KA-8255:** Users can view record titles within a shared nested folder when they have the appropriate permission. Records outside the user's access scope are not shown.

**KA-8256:** Users can view which other users and teams have access to a specific shared nested folder, along with their assigned roles. All roles with folder access are visible to permitted users.

**KA-8257:** Users with access-management permission can grant, revoke, or modify folder access for other users and teams. Unauthorized roles are correctly denied from making access changes.

**KA-8259:** Users with view-records permission on a shared nested folder can view and decrypt record content within that folder. Users without sufficient permission are denied access to record content.

**KA-8260:** Users with edit-records permission on a shared nested folder can edit record content within that folder. Edits propagate to all users with access; view-only and unauthorized roles cannot alter content.

**KA-8270:** Users can create a new record at the vault root level. The record is created with shared nested permissions when the feature is enabled.

**KA-8271:** Users with add permission can create a new record directly within a selected shared nested folder. The record is automatically linked to that folder's permission model.

**KA-8261:** Users with remove permission can unlink a record from a specific shared nested folder without permanently deleting it. The record remains accessible in other locations where it is stored.

**KA-8262:** Users with delete permission can permanently delete a record from within a shared nested folder. Unauthorized roles are blocked from performing deletion.

**KA-8263:** Users with record-level delete permission can permanently delete a record regardless of its folder location. Only users with the appropriate role may perform this action.

**KA-8269:** Users with the appropriate permission can view record titles.\
Only titles within the user's access scope are visible.

**KA-8264:** Users with view permission can view the full content of a record, including login, password, and notes fields. Users without sufficient permission are denied access.

**KA-8265:** Users with edit permission can modify record content including title, login, password, and notes fields. Changes are visible to all users who have access to the record.

**KA-8266:** Users can view which other users and teams have access to a specific record, along with their assigned roles. All roles with record access are visible to permitted users.

**KA-8267:** Users with access-management permission can grant, revoke, or update access to a record for other users and teams. Unauthorized roles are correctly denied from making access changes.

**KA-8268:** Record owners and managers can transfer ownership of a record to another user.\
The new owner receives full ownership capabilities; unauthorized roles are blocked from initiating a transfer.

**KA-8272:** When a legacy SharedFolder is selected, creating a new record or folder uses the legacy permission model. Items created in this context follow legacy SharedFolder behavior.

**KA-8273:** When a shared nested folder is selected, creating a new record or subfolder uses the shared nested permission model. Created resources are linked to the selected folder and follow shared nested access rules.

**KA-8274:** The system prevents nesting legacy SharedFolders inside shared nested folders and vice-versa. Moving or copying folders across permission models is blocked.

**KA-8275:** Users with KSM privileges can create a Keeper Secrets Manager application at the vault root. The KSM application is created as a shared nested folder folder.

**KA-8276:** Users with KSM share privileges can share a KSM application with other users or teams using role-based access. The shared user receives the designated role on the KSM application.

**KA-8277:** Users with KSM privileges and add permission can create a KSM application within an existing shared nested folder. The application is attached to the selected folder context.

**KA-8278:** All shared nested folder functionality is controlled by a feature flag. Only enterprises with the feature flag enabled can access shared nested folder functionality.

**KA-8297:** Shared nested folders and legacy SharedFolders operate as completely isolated permission systems. Resources cannot be moved or copied between folder types that use different permission models.

### Bug Fixes

**KA-8523:** Strengthened access control validation for sub-node administrators requesting enterprise user data by node. vSub-node administrators are now properly restricted to only access data within their own node and authorized child nodes with cascading permissions.

**KA-8516:** Resolved an issue where BreachWatch was not detecting or displaying dark web breach alerts for newly created records. Breach monitoring now correctly processes and reports alerts across all account types including consumer, enterprise, and shared records.

**KA-8475:** Fixed an issue where PAM active seat count did not update when an invited user assigned to a PAM role accepted their invitation. The seat count change event now correctly fires upon user activation, ensuring accurate PAM license tracking.

**KA-8491:** Fixed an issue where record details were not accessible to users with View Only sharing permissions on non-shared nested folder accounts. Shared record information is now properly displayed for recipients with direct share View Only access.

**KA-8539:** Resolved an error where MSP administrators received an "object already exists" error when attempting to create a new Managed Company. MSP administrators can now successfully create Managed Companies without encountering duplicate object errors.

**KA-275:** Fixed an issue where the backup restore list did not include backups created after the restore verification code was sent. All available backups now display correctly regardless of when they were created relative to the restore code request.

**KA-8564:** Addressed security vulnerabilities by upgrading underlying networking dependencies to their latest patched versions. This update resolves known CVEs and strengthens the overall security posture of the application.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeper.io/release-notes/backend/backend-api/backend-api-18.0.0.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.