Sharing screen

The Sharing screen packages selected records from the active vault either as an encrypted internal bundle that another VaultPilot user can copy into their own vault, or as a passphrase-protected file that an external recipient opens offline.

External sharing is not a hosted portal, public link, or central PAM checkout service. VaultPilot does not keep the external package on the server, create an external recipient account or history row, or offer central revocation after that file has been handed out.

Access, roles, and license

Sharing needs the Sharing license feature and a license that is not read-only. Auditors cannot use secret workspaces.
The active vault must be unlocked before records can be viewed or packaged.
Sending an internal bundle requires the Owner or Admin role, Manager access to the source vault, and a writable license.
Creating an external package requires Manager access to the source vault and a writable license. A User can do this when they are a Manager of that vault.
Saving an incoming bundle requires Editor or Manager access to the active target vault and a writable license. It does not give access to the sender’s source vault.
An internal recipient must be another active user in the same organization, must not be an Auditor, and must have a registered public key. The 2FA state shown in the selector is for information only.

Do not treat an old, already-open screen as permission to change anything when the license is read-only or does not include Sharing. Reopen Sharing from the navigation and check the role, vault, and license state.

Three-step flow

The stepper contains Select, Send, and Result. You can move between steps, but the visible selection summary is the final scope check.

1. Select records

Passwords, Active Directory credentials, API keys, notes, certificates, and file records can be selected. Search covers title, username, URL, host, domain, and the record-type label. Use All or a type tab to narrow the list, then select one record, all visible records, or a visible type group.

Selected records can stay selected after a filter hides them. Select visible records adds only the current visible set to the existing selection. The top-level Clear selection clears every selected record, including hidden ones; Remove group removes only the visible records in that group. Before sending, check the total selected count and type summary so a hidden selection is not included by accident.

Files are decrypted only in the browser and encrypted again for the share. A file with missing or incomplete content stops packaging.

2. Set lifetime and uses

The lifetime is 1 to 720 hours (30 days), and the usage limit is 1 to 25. Shortcuts are offered for 1 hour, 24 hours, 3 days, 7 days, and 30 days.

For an internal bundle, the server enforces expiry, use count, and status.
For an external package, expiry is checked against the recipient device’s clock.
The external maximum-opens limit is counted only in the browser profile that opens the package. Another browser or profile, or cleared browser data, starts a new count. It is not an organization-wide limit, audit counter, or revocation.
A successful external open uses up one open before content is shown. A later file-download failure does not give that open back.

3. Choose a delivery method

The same selection and policy finish through exactly one of the internal or external paths below. They differ in storage, use counting, and revocation.

In Internal recipient, choose the target VaultPilot user and select Send selected items. The browser encrypts the selected records with a new key that only the recipient can open. The server stores only encrypted data and the share settings, never plaintext records or the open key.

An internal bundle containing files is built in steps:

The bundle is created first and shows as Preparing.
Files are encrypted again in the browser and uploaded one by one.
The bundle becomes ready only after every file has arrived complete.

The recipient sees only ready, unexpired bundles with uses left under Incoming shares. Save to my vault decrypts the bundle in the recipient’s browser and creates new records, encrypted for the active target vault. The use count changes only after all records are written. The bundle can be used again until its limit is reached; then it shows as Used.

This is not vault membership or live synchronization. Later changes to the source record do not reach the recipient’s copy.

When an Active Directory credential is shared, its link to the directory account travels with it. The same provider and user object must still exist in the organization, and the recipient must be able to write to the target vault. A removed provider, missing object, or duplicate managed credential is refused safely, and records created by that attempt are removed again.

Incoming and outgoing lists

Incoming shares is not history. It shows only bundles that can currently be accepted. Accepted, revoked, expired, used-up, or still-preparing bundles are absent.
Recent outgoing shares shows only your newest few internal bundles. The list shows share details only; the encrypted content is downloaded only when an eligible recipient opens it.
Display states are Preparing, Pending, Used, Expired, and Revoked.
The screen shows Revoke only for your own pending, unexpired bundle with uses left. Revocation blocks future opens; it does not delete copies already saved in a recipient vault or change source records.

External passphrase package

Create external package generates a strong share passphrase in the browser. The selected records are encrypted with it, and expiry, use limit, scope, and file details are sealed into the package so any change is detected.

Packages without files download as .json; packages with files use .pmshare.
The package and passphrase exist only on the result screen. An external package is not added to server history or Recent outgoing shares.
Use Copy package or Download package to keep the protected file. Download decrypter provides vaultpilot-share-decrypter.zip.
For direct delivery, use approved separate channels for the package, passphrase, and decrypter. At minimum, never send the package and passphrase through the same channel.
Finish and New share clear the package, passphrase, and selection. Save the package safely before finishing. Screen lock alone may not clear all sharing material; fully reload the page when abandoning the flow.

There is no revoke action after an external package is handed out. Creating a replacement does not invalidate the old file. If the package or passphrase reaches the wrong person, treat the package as openable until expiry and rotate or revoke every contained secret through its normal procedure.

SMTP delivery

The SMTP action on the result screen uses VaultPilot’s configured email to send one recipient the package file, the decrypter ZIP, and short instructions. The passphrase is not attached. The screen warns you to use another channel but asks for no confirmation, so a sent email does not prove how the passphrase was delivered.

When SMTP is used, the package passes briefly through the VaultPilot server and your mail service. VaultPilot does not keep it as a stored share.

Size and request limits

Path	Enforced limit
Internal bundle	At most 250 records and 1 GB of files.
Internal create request	Each sender can keep only a limited number of pending bundles, and repeated creation in a short time is paused for a while.
Encrypted record body	Each vault and organization has a storage limit that current records and their history share.
Direct external download	Selected files total at most 1 GB; the 250-record limit does not apply.
External package through SMTP	The package can be at most 12 MB and 250 items. A larger package cannot use built-in email; use an approved manual delivery path.

Partial and non-transactional states

Each of these steps can stop partway:

Internal creation stops partway: A bundle with some of its files can remain. It shows as Preparing for the sender and is hidden from the recipient. Retrying creates another bundle instead of resuming the old one. Check the outgoing bundle and Audit Log first; revoke the incomplete bundle when appropriate.
Incoming acceptance stops partway: Records are written one by one and the use count changes last. On failure, records created by that attempt are removed again. If that cleanup also fails, the screen says so; only then check the target vault and audit before retrying.
Concurrent acceptance: A double click or two sessions can both import records before the count updates. Use one operator and one session.
External generation and audit are separate: The package and passphrase appear on the result screen before the audit entry is written. If that entry fails, the screen can report a failure while the package already exists. Check the result screen and audit history before generating again.
SMTP audit has two stages: The send is recorded before the email goes out; if that record cannot be written, no email is sent. The delivery record afterwards can be missing even when the email was sent. The first record alone is not proof of delivery, and a missing delivery record is not a reason to send again right away.

Audit and evidence

Creating an internal bundle, finishing its files, accepting it, and revoking it are each recorded in the audit history. Records created in the recipient’s vault can have their own entries.
Creating an external package locally records only a general share entry; no package is stored on the server.
Email send and delivery entries hold only redacted details such as item and use counts, size, expiry, and a message reference. Package content, passphrase, recipient address, and file name are never recorded.
Missing audit evidence does not prove that nothing happened; a send entry alone does not prove email delivery.

Screen states

State	Operator response
Records or bundle list loading	The panel may show no placeholder. Wait for the next automatic refresh and check the session.
No shareable records	Check the active vault, unlock state, search, and type filter.
No eligible internal users	Your own account, disabled users, Auditors, and users who have not finished account setup are excluded. Check user state privately.
Empty incoming/outgoing lists	There is no separate error card; a failed load can look empty. Check the session and network before treating emptiness as proof.
Preparing	The internal bundle exists, but its files are not complete. Check or revoke it before creating another package.
Pending	The internal bundle is ready and has at least one use left.
Used / Expired / Revoked	The bundle cannot be accepted again. Copies already in recipient vaults are unaffected.
Incoming share failed	Assume some records or files may exist; inspect the target vault before retrying.
External generation failed	The package and passphrase may still exist. Check the result screen and audit before creating another package.
SMTP failed or outcome unclear	Compare the audit entries, the screen result, and your mail server’s records; do not resend blindly.
Decrypter error	Separate wrong passphrase, modified package, expiry, used-up opens, browser data, and version problems; never ask for a screenshot of decrypted content.

Before you act

Confirm the active vault, system and vault roles, the Sharing feature, and a writable license.
Check the total selected count, type summary, and selections hidden behind filters.
Check file total, package size, lifetime, and use limit against the chosen delivery path.
Confirm the internal recipient’s identity privately; the recipient chooses and unlocks the target vault.
Explain that an external package cannot be revoked centrally and that its maximum opens is counted only in one browser.
Decide the channels for the package, passphrase, and decrypter before creation; never include the passphrase in the email.
If an outgoing bundle or a target-vault save is incomplete, check the bundle lists, the target vault, and Audit Log before retrying.

Safe evidence

Safe to share: internal or external path, broad package state, approximate time, item and file counts, size range, lifetime and use policy, the redacted error message, a shortened bundle reference, and whether the email was sent.
Keep private: package content, share passphrase, decrypted contents, record titles and usernames, file names, recipient name and email, full bundle references, encrypted data, vault name or ID, the email message, and full-screen captures.
Never place the package and passphrase in the same evidence bundle. If either was exposed, the external file cannot be revoked; rotate or revoke the contained secrets.

When to stop

Stop when the selection is uncertain, the target user cannot be confirmed, files are incomplete, the Active Directory provider or target object can no longer be confirmed, an existing bundle is Preparing, the screen reports incomplete cleanup, the external result conflicts with the audit history, the email outcome is unclear, or the package and passphrase shared a channel. Do not create a second package or accept again until an internal review has matched the redacted references, time, status, and audit evidence.

Operator notes

Internal sharing is a limited, server-tracked encrypted delivery; acceptance creates independent copies in the recipient vault. External sharing is an offline file handoff; after it is handed out, control depends on package expiry, the recipient device clock, a per-browser open count, and disciplined secret rotation. Do not describe both models as one continuing “active share.”

Back to Documentation