A short engagement still needs careful access
A contractor may need a deployment token, test account, or temporary VPN credential to complete one task. The sharing channel is only one part of the control. Start by limiting the credential itself, the systems it reaches, and how long it remains valid.
Make the permission fit the task
Create a dedicated account or token when possible. Grant only the required repository, environment, or operation. Set an expiry in the source system, if supported, and record who owns revocation. A KeySlip message can expire after 10 minutes, 1 hour, 1 day, or 7 days; that message expiry does not set the credential’s own lifetime.
Separate access from instructions
Put the credential and only the context the contractor needs in the message. Identify the target environment and intended use without adding unrelated customer data. KeySlip encrypts in the browser with AES-256-GCM. You may add a separate password using PBKDF2-HMAC-SHA256 (600,000 iterations); send it through a different channel.
Send it to one named recipient
Share the full link privately with the contractor you verified. The decryption key is carried after # in the link, so anyone with the complete link can attempt a read. Avoid putting the link in a ticket visible to a wider group. If the contractor uses an AI agent or automation to read the message, that system can see the plaintext too.
Revoke the credential in its source system
The first read consumes the message, even if the read errors, the connection times out, the page closes, or the password is incorrect. Keep a secure copy of anything you need before sharing. When the task ends, revoke or rotate the account or token in the system that issued it; deleting or consuming a KeySlip link does not revoke the underlying access.
Continue with the relevant workflow
For team processes and a guided pilot, visit KeySlip Teams. For a command-line handoff, see Share secrets from a terminal.