Security

Staff work and external access are different trust surfaces

The person opening a public share and the employee working in a content workspace should not inherit the same assumptions.

Different users bring different risk

Staff usually arrive through organisation identity, have ongoing membership and work across many resources. External recipients may need only one document for a short period. Treating those populations as one session model either gives outsiders too much or makes internal work unnecessarily awkward.

A separate external-sharing surface lets the product design recipient proof, expiry, rate limits and content delivery around the actual use case.

Separation limits credential confusion

Employee cookies and bearer tokens should not become accidental credentials on a public share endpoint. Likewise, a recipient token should not unlock the authenticated workspace API. Keeping those boundaries explicit reduces the chance that one class of credential is accepted in the wrong place.

It also makes architecture reviews easier because the threat model for each surface can be discussed directly.

Audit can still connect the story

Separation does not mean losing context. The product can connect staff share creation with recipient proof and external content access through stable object and share identifiers.

That gives the organisation a complete record without pretending the participants all belong to the same identity domain.

Keep the surfaces distinct

Staff workspace access and recipient share access should remain separate session models. Mixing them either over-grants outsiders or makes internal work awkward.