BluOps

Workflows

7 min read

How Agencies Should Share Client Credentials (And Where It Goes Wrong)

How Agencies Should Share Client Credentials (And Where It Goes Wrong)

Short answer: Most agencies share client credentials in Slack DMs, email threads, or pasted into a task description. All three have the same fatal property — the credential is permanent, unscoped, and invisible. Nobody knows who has it, nothing expires, and there's no revoke. The fix isn't a stricter policy. It's using a sharing method where access is scoped to a person, bounded by time, revocable on demand, and logged — so that offboarding a contractor or ending a client relationship is one action rather than an archaeology project.

Where credentials actually end up

Run this test on your own agency. Search Slack for password, login, API key, and credentials. Then search your project management tool for the same terms.

What comes back is usually:

  • Slack DMs and channels. Searchable forever by anyone in the workspace with access to that channel, including people who joined afterward.

  • Email threads. Forwarded, replied-to, sitting in the sent folder of someone who left last year.

  • Task descriptions and comments. The worst one, and the most common in agencies running everything in one tool.

  • A shared spreadsheet called something like "Client Access" that hasn't been reviewed in two years.

None of these are decisions anyone made. They're what happens when a credential is needed at 4pm and the fastest route wins.

The ClickUp-specific version of this problem

If your delivery runs in ClickUp, credentials in task descriptions carry three compounding risks.

1. Whoever can see the task can see the credential

Everything inside a shared location is visible to whoever it's shared with — descriptions, comments, custom fields. A credential in a task description is exposed to every guest, contractor and team member with access to that List.

2. Visibility can widen without anyone touching the credential

Several ordinary actions change who can see a location. Moving a Folder or List from a private Space to a public one makes its tasks public. A task pulled into a public Space via Tasks in Multiple Lists becomes visible to everyone with access to that Space. The credential didn't move — the walls around it did.

3. It outlives everyone

Offboard a contractor and you remove their access to the workspace. You don't rotate the credential, because nobody remembers it's in a task description from fourteen months ago. They no longer have access to the task. They still have the password.

The exposure isn't the moment you paste it. It's every month afterward, during which the credential is still valid and you've stopped thinking about it.

What good actually requires

Four properties. A method missing any one of them is leaving a hole.

  • Scope — this specific person gets this specific credential, not "everyone in the channel"

  • Expiry — access ends at a set time by default, rather than persisting until someone remembers to clean up

  • Revocation — you can cut access immediately without rotating the underlying password

  • Visibility — a record of who accessed what and when, so offboarding is a lookup rather than a guess

Slack, email and task descriptions have none of these. That's the whole problem — not that they're insecure in transit, but that they create permanent unscoped copies nobody tracks.

The options, honestly compared

A team password manager

1Password, Bitwarden and similar are genuinely good and most agencies should be running one. Vaults scope access by team, sharing links can carry expiry, and rotation is straightforward.

Where they fall short for client work: they're built for your team, not your clients. Sharing outward means generating a link and sending it through some other channel — usually Slack or email, which is where the credential ends up anyway. The client also has no persistent place to find it later, so they ask again, and you generate another link.

Use one regardless. This isn't an either/or. Internal credential hygiene needs a password manager whatever else you do.

A one-time secret link

Services that generate a self-destructing URL. Better than pasting into Slack, and free.

Where they fall short: no identity — anyone with the URL opens it. No record of who used it. And the link still travels through Slack or email, so the delivery channel is unchanged.

Task descriptions and Slack

Covered above. The honest assessment is that this is what most agencies do and it fails all four requirements.

Credential sharing inside the client portal

The client already has a portal for their projects and invoices. Credentials live there too, scoped to them.

Why this fits agency work specifically: credential exchange with clients is bidirectional and ongoing. They send you access to their ad account, their CMS, their analytics. You send them access to something you built. That's not a one-time secret — it's a recurring part of the relationship, and it belongs where the rest of the relationship lives.

How this works in BluOps

BluOps includes credential sharing on every plan — not an add-on, not a higher tier.

  • Choose what to share, with whom, and for how long. Scope is set per credential and per person.

  • Access auto-expires at the time you set. The default outcome is that access ends, rather than access persisting until someone cleans up.

  • Revoke instantly at any point, without rotating the underlying credential.

  • Access is logged — who opened what, and when.

  • Credentials are encrypted at rest.

Because it sits in the same portal as their projects, files and invoices, the client has one place to look — which is what stops the "can you resend that login" message.

What to do this week

  1. Run the search. Slack and your PM tool, for password, login, API key, credentials. Don't fix anything yet — just see the volume.

  2. Rotate anything found in a task description or public channel. Treat it as exposed, because functionally it is.

  3. List everyone who left in the last 18 months and note which credentials they would have had. Rotate those.

  4. Pick one method and make it the only one. Two acceptable channels means the fast one wins under pressure, and the fast one is Slack.

  5. Add credential rotation to your client offboarding checklist — the step everyone skips, because the relationship ending feels like the end of the risk.

Frequently asked questions

Is it safe to put client passwords in ClickUp task descriptions?

No. Everything inside a shared location is visible to whoever has access, including guests and contractors, and visibility can widen through ordinary actions like moving a Folder between Spaces. The credential also persists after people are offboarded, because nobody remembers it's there.

How should agencies share passwords with clients?

Through a method that scopes access to a person, expires by default, can be revoked without rotating the credential, and records who accessed it. Slack, email and task descriptions fail all four. A team password manager handles internal sharing well; client-facing sharing is better handled where the rest of the client relationship lives.

Is a password manager enough for client credential sharing?

For your internal team, yes, and every agency should have one. For clients it's partial — outward sharing usually means sending a link through Slack or email, and the client has no persistent place to find the credential later, so they ask again.

What should we do about credentials already sitting in Slack and ClickUp?

Rotate them. Anything in a searchable channel or a task description should be considered exposed regardless of who currently has access, because you can't establish who has seen it historically.

Should credentials be rotated when a contractor leaves?

Yes, and it's the step most commonly skipped. Removing someone's workspace access doesn't invalidate a password they already have. Any credential they could reach during their engagement should be rotated at offboarding.

Does BluOps credential sharing cost extra?

No. It's included on all plans, with scoped access, expiry, instant revocation, access logging, and encryption at rest.

The short version

Credentials in Slack, email and task descriptions aren't risky because of how they travel. They're risky because they're permanent, unscoped, and invisible — nobody knows who has them, nothing expires, and there's no revoke.

Run the search on your own workspace this week. Whatever you find has been there longer than you think, and some of it belongs to people who no longer work with you.

See how credential sharing works in the portal — 7 days of full access is $1.