Illustrative Example: Password-Gated Client Links for a Hypothetical Agency

Illustrative example. This walkthrough is hypothetical and is provided to demonstrate how yas.sh features could be applied to an agency. It does not describe a real customer, and all figures, metrics, and quotes are illustrative only and do not represent actual customer results.

The hypothetical scenario

Northbeam is a fictitious 40-person digital agency running paid media, branding, and web projects for ~25 active clients. Every engagement produces deliverables: strategy decks, media plans, design previews, and performance reports — 120+ documents a month.

The problem

Deliverables shipped three ways, all wrong:

• Email attachments hit mailbox limits (one 90MB brand deck bounced three times), versioned into confusion ("final_v2_FINAL"), and lived in inboxes forever — a client's old strategy deck is still sitting in a former employee's mailbox.
• Shared drives were the opposite failure: too open. Folders intended for one client were visible to anyone with the link, and access never expired.
• Generic file share links (the "anyone with the link can view" kind) offered no gate, no expiry, no visibility into whether the client had even opened the file.

Two real incidents drove the change: a deck for a competing client was accidentally shared with the wrong account, and a media plan link circulated to a vendor who was not supposed to see rates.

The requirements

• Deliverables must be gated — a password the client can't miss, delivered separately.
• Everything must expire — decks for a pitch that already happened should stop working on a date.
• The team needs visibility — did the client open it? When? From where?
• No new tools for clients — the gate must be a web page, not an app.
• Bulk-friendly — 120+ deliverables a month means per-document setup must take seconds.

The solution

Northbeam standardized on yas.sh password-protected links in one sprint.

The delivery playbook:

1. Project lead uploads the deliverable to the client's own drive (still the storage layer — yas.sh is the access layer).
2. A short link is created pointing at the file, with a password and an expiry tied to the milestone:

curl -X POST https://yas.sh/api/v1/links \
  -H "Authorization: Bearer yas_live_..." -H "Content-Type: application/json" \
  -d '{"originalUrl":"https://drive.client.com/final-deck-q3","customAlias":"acme-q3-deck","password":"<generated>","expiresAt":"2026-09-30T23:59:59Z","title":"Acme Q3 Strategy Deck"}'

1. The client gets the link by email; the password arrives by Slack DM or SMS — the two-channel rule.
2. When the client opens it, the gate page asks for the password, verifies it (bcrypt, rate-limited), and redirects to the file. The open is recorded in analytics.
3. On the expiry date, the link returns 410 Gone — the deliverable's public life is over by design.

The automation layer: account managers use the dashboard for one-off decks and a saved script for recurring reports (weekly performance PDFs get a fresh link every Friday, expiring the following Friday — a rolling window that never leaves a report publicly reachable for more than a week).

Results after six months

The two-channel password rule took a week to become muscle memory. The expiry policy eliminated the "client asked for the old deck" class of requests entirely — the answer is a fresh link, not a hunt through a shared drive.

What the team says

"We went from hoping files stayed private to designing their death. Every deliverable now has a handshake (password), a lifespan (expiry), and a receipt (analytics). The clients actually like it — the gate feels professional, and the 410 page tells them the link is done instead of leaving them with a broken URL."

— Operations Director, Northbeam Agency

Lessons for agencies

1. Two channels or nothing — link by one channel, password by another; this single rule prevented every future leak.
2. Expiry is a feature clients understand — "this link is valid until the 30th" is clearer than any permission matrix.
3. Visibility replaces anxiety — open timestamps answer the question every account manager asks twice a week.
4. Scripts beat dashboards at volume — recurring deliverables are a cron job, not a ritual.

Build the same playbook

The pieces are free to start: password-protected links, expiry, and the API for the automation layer. The password links guide documents the security model Northbeam relies on.

The principle this illustrative scenario demonstrates

This scenario is illustrative — a realistic, hypothetical walkthrough of how an agency would protect client deliverables — not a claim about a real engagement. The reusable principle is password-gated, expiring, auditable access: an agency shares client decks through links that require a password, expire after a set time, and record when they were opened. The walkthrough exists to show why that combination matters and how to set it up, because the same pattern protects any sensitive-but-shareable material. The transferable value is in the method, not in any specific figure.

Why gated access fits agency workflows

Agencies live on shared deliverables — decks, specs, proposals — that must reach the client but should not be broadly accessible. A plain shared link leaves that material exposed to anyone who gets it. Layering controls fixes the exposure without adding a heavy platform: a password gate stops casual and accidental access, an expiry makes a leaked link useful only for a limited window, and an audit record shows when access happened so the agency can respond to unexpected opens. The three controls together contain the risk of sharing sensitive work.

The trust and accountability angle

For an agency, controlled sharing is also a trust signal. Delivering a client's work through a gated, expiring link shows care about confidentiality, which reinforces the agency's professional credibility. And the audit record provides accountability — if a deck surfaces unexpectedly, the agency can check the access history rather than guess. This is the same "named access and evidence" discipline described in the teams and permissions and security material, applied to external sharing instead of internal access.

Applying the pattern more broadly

Because the scenario is illustrative, the practical value is in the transferable sequence: classify what you are sharing, apply the appropriate control (password, expiry, audit) for its sensitivity, communicate the access path clearly to the legitimate recipient, and monitor for unexpected activity. That sequence generalizes to any team sharing sensitive material with outside parties. The walkthrough is designed to teach that pattern rather than to report a client result.