A Send link is a shareable URL that points to encrypted content and contains the information needed for access. In this model, the link itself can function as a bearer secret, so anyone with the active link may retrieve the shared item unless additional controls such as a password or expiry are enabled.
Expanded Definition
A send link is a shareable URL that grants access to encrypted content, so the link itself becomes an access credential rather than a simple pointer. In practice, that means possession of the active URL can be enough to retrieve the item unless the sharing system adds compensating controls such as a password, expiry, revocation, or recipient verification.
This boundary matters because send links sit between convenience and bearer-secret risk. They are not the same as ordinary public link, and they are not necessarily equivalent to full account-based authorization. In security terms, the trust model shifts from “who is signed in” to “who has the live link,” which is why definitions vary across vendors and implementations. Some products bind the link to a recipient, while others treat it as a portable secret that can be forwarded, stored, or exposed like any other credential.
The key misunderstanding is assuming encryption alone makes the link safe. Encryption protects the content at rest and in transit, but the send link can still be the decisive access token.
Examples and Use Cases
Send links are common in workflows where users need quick sharing without creating a full collaboration space. The same mechanism can be helpful or risky depending on how long the link remains valid and how broadly it can be forwarded.
- A finance team sends a vendor a link to review an encrypted contract draft before signature.
- A security team shares a sensitive incident report with a consultant using a time-limited link instead of email attachments.
- A product manager distributes a design package to external reviewers who should not get ongoing repository access.
- A legal team uses an expiring link for privileged documents, then revokes it after the review window closes.
- A user forwards a send link through chat, unintentionally expanding access beyond the original recipient.
The tradeoff is speed versus control: send links reduce friction for external sharing, but every extra minute of validity increases the window in which the link can be copied, cached, or replayed. The OWASP Non-Human Identity Top 10 is useful here because it frames bearer-style access as an identity problem, not just a sharing convenience.
Security Implications
Mismanaged send links can create unauthorized disclosure even when the underlying content is encrypted. If the link is treated as harmless metadata, organisations may overlook it as a bearer secret and miss that the URL alone can satisfy access. That failure mode is especially damaging when links are indexed in chat logs, browser history, endpoint telemetry, ticketing systems, or forwarded email threads.
When access controls are weak, the blast radius is broader than a single file. A live send link can expose confidential documents, regulated data, source material, or operational records to anyone who obtains it. NHIMG research notes that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage, which is relevant because send links behave like secrets when they are not tightly bounded.
Common symptoms include links that never expire, links that cannot be revoked cleanly, and links that remain valid after the business need has ended. In those cases, the security failure is not encryption itself but uncontrolled persistence of access.
Domain and Governance Relevance
Send links matter in NHI governance because they often function as short-lived, identity-like access artifacts. When a link authorizes retrieval of protected content, the organisation still needs ownership, lifecycle control, and revocation discipline, even if no named account is involved.
That becomes especially important in machine-to-machine or automation-heavy workflows. Agents, service desks, content pipelines, and integrations may generate or consume send links at scale, which turns a convenience feature into an access-governance issue. If those links are created outside a clear policy, security teams lose visibility into who can access what, for how long, and under which conditions.
For NHI programs, the practical question is not only whether the content is encrypted, but whether the access path is inventoryable, expirable, and revocable like any other privileged secret. Send links therefore sit close to the same governance concerns that apply to API keys, tokens, and shared credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Send links act as bearer secrets that must be protected, expired, and revoked. |
| NHI-03 — Access Scoping and Least Privilege | A send link grants access scope that should be narrowly bounded to the intended recipient. | |
| NHI-04 — Rotation and Revocation | Compromised or stale send links need fast invalidation just like other identity credentials. | |
| Recommendation — Treat send links as secrets and enforce expiration, revocation, and exposure controls. Limit each send link to the smallest necessary audience and shortest practical access window. Revoke inactive or forwarded send links promptly and verify invalidation actually takes effect. | ||
| CIS Controls v8 | 6.3 — Data Recovery | Shared encrypted content still needs controlled access and recovery-oriented protection. |
| 3.4 — Data Protection | Send links are a data access path that can expose sensitive information if unmanaged. | |
| Recommendation — Protect shared sensitive content with controlled distribution and recovery-aware handling. Classify and protect send links as access channels to sensitive data. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | A send link can function as a bearer credential if it is exposed or forwarded. |
| Recommendation — Hunt for exposed send links as credential-like artifacts in logs and message trails. | ||
Related resources from NHI Mgmt Group
- What is the difference between public link control and standard access review?
- How can security teams keep recovery processes from becoming the weakest link?
- What breaks when interactive components are trusted to send actions directly to agents?
- Which framework best frames the link between patching and identity security here?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
