Collaboration-link phishing uses legitimate cloud sharing or messaging platforms to deliver a fake login page or malicious prompt. The link can pass gateway checks because the destination is real, so the control problem shifts to validating the identity and context behind the invitation.
Expanded Definition
Collaboration-link phishing is a delivery pattern in which attackers abuse legitimate collaboration services to host or route a deceptive login page, file request, or approval prompt. The abuse is not in the transport itself but in the identity assumptions made by the recipient, which is why the link can appear credible even when the destination is hostile. In NHI and IAM environments, the term covers invitations, shared documents, message-thread actions, and embedded app prompts that impersonate trusted business workflows. Guidance varies across vendors on whether a malicious cloud-hosted page counts as phishing only when credentials are harvested or also when an AI agent is tricked into granting access; no single standard governs this yet. The operational distinction from ordinary phishing is that reputation checks on the platform may pass while the invitation context remains unauthenticated. For governance, the relevant question is who initiated the link, what authority they had, and whether the request aligns with expected collaboration patterns, not merely whether the domain is known. The most common misapplication is treating a real collaboration URL as inherently trustworthy, which occurs when defenders inspect the domain but not the sender context or the downstream permission request.
For related NHI governance context, see Ultimate Guide to NHIs and the identity-focused controls in NIST Cybersecurity Framework 2.0.
Examples and Use Cases
Implementing collaboration-link phishing defenses rigorously often introduces friction for legitimate sharing, requiring organisations to weigh faster collaboration against tighter verification and user experience constraints.
- A finance lead receives a shared document link in a chat platform that opens a cloned SSO page, where the real risk is not the hosting service but the fake sign-in flow attached to it.
- An AI agent with mailbox access follows a calendar invite or thread link and approves an external app connection without checking sender legitimacy or task relevance.
- A contractor posts a file request in a project workspace, but the request leads to a credential prompt that captures session tokens rather than the file itself.
- A service account notification includes a collaboration link to “review access,” but the page actually requests OAuth consent for a malicious application.
These patterns align with NHI exposure trends described in The State of Secrets Sprawl 2025, where collaboration and project management tools are frequent leak paths. The broader identity and trust model also maps to NIST Cybersecurity Framework 2.0, especially where access decisions depend on validating origin, not just destination.
Why It Matters in NHI Security
Collaboration-link phishing matters because NHI environments often allow bots, service accounts, and AI agents to act on messages, files, and approvals with real authority. Once a collaboration link is abused, the attacker can inherit trust paths that bypass traditional perimeter controls and move directly into secrets, API keys, token grants, or automated workflows. NHIMG research shows that 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent, which underscores how quickly a benign-looking invite can become an enterprise incident. The issue becomes more severe when an agent or integration can click, consent, or share on behalf of a user without a human review step. In practice, the control objective is to verify sender identity, request provenance, and entitlement scope before any link-driven action is allowed. The most common business impact is not the initial click but the subsequent compromise of downstream credentials and permissions after a trusted workflow has been abused.
That is why the Ultimate Guide to NHIs is relevant here: collaboration abuse often exposes over-privileged non-human identities before teams realise the invitation was malicious. Organisations typically encounter account takeover, token misuse, or unauthorized sharing only after the link has been opened and an access grant has already been executed, at which point collaboration-link phishing becomes operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret exposure and trust abuse in NHI workflows. |
| NIST CSF 2.0 | PR.AC-1 | Addresses identity proofing and access validation before authorization. |
| OWASP Agentic AI Top 10 | LLM-04 | Agentic prompt and action abuse can turn shared links into unsafe execution paths. |
Require sender validation and secret-safe handling before any collaboration link can trigger access.
