How to Share an API Key Securely

Create a key for the recipient and task

Do not copy a production administrator key simply because it already exists. Create a separate credential with the smallest useful set of resources, actions, environments, source addresses, and lifetime. A dedicated key gives you a clear item to revoke and avoids interrupting unrelated systems when access ends.

Record the owner, purpose, creation date, expected expiry, and revocation procedure in your internal system without recording the secret value there. If the platform supports short-lived tokens, workload identity, delegated authorization, or a secrets manager, prefer those controls over a manually shared long-lived string. Delivery security cannot compensate for unlimited permissions.

Verify the person and separate context from the secret

Confirm an unusual request through a known number, existing company account, or scheduled call. A message from a new address is not identity proof. Send the service name, account, endpoint, and setup instructions separately from the key so one intercepted item has less immediately useful context.

Create a browser-encrypted SecretLink containing only the key. Choose one-time access when the recipient is ready, or the shortest expiration that allows for time-zone and support delays. If you add an access password, communicate it through a genuinely separate channel rather than placing it beside the complete link.

Understand what the encrypted handoff changes

Strumio encrypts the message in the sender's browser with AES-256-GCM and puts the random decryption key in the URL fragment. The service stores ciphertext rather than the readable key. Expiration and one-time retrieval reduce future access to that stored encrypted payload.

The complete URL is still a bearer capability and must be protected. A browser extension, compromised endpoint, clipboard manager, screenshot, forwarding recipient, or logging tool can expose a key after decryption. One-time access blocks a later Strumio retrieval; it does not prevent the first viewer from copying the credential.

Deliver, confirm, and remove temporary traces

Tell the recipient when the link will arrive and ask them to open it on a trusted, updated device. Confirm successful setup without asking them to paste the key back into email or chat. They should place it directly into an approved secret store or protected environment variable rather than a source file, issue tracker, build log, or shell-history command.

Delete the Strumio message when it is no longer needed, but treat that as delivery cleanup rather than credential revocation. Search code review, CI logs, terminal history, and support transcripts if accidental copying is possible. Rotate immediately if the link reached the wrong person or appeared in an untrusted system.

Operate and retire the credential safely

Monitor usage for unexpected sources, times, regions, methods, or volumes. Set an owner-visible expiry reminder and test revocation before an incident. When a contractor leaves or the integration changes, issue a replacement, deploy it, verify service health, and revoke the old key rather than leaving overlapping access indefinitely.

For recurring automation, move away from person-to-person key sharing. Use workload identities, vault injection, managed secret references, or individually attributable access. An encrypted link is useful for a focused bootstrap handoff, not a complete secrets-management, auditing, or incident-response system.

Related guidance

When an encrypted delivery link is appropriate, Create a free Strumio account.