Transcripts are the sensitive asset, not the settings
Most teams think about chat access in terms of who can change the widget colour. The higher-value target is the archive: months of conversations containing order numbers, email addresses, complaints, and the occasional thing a customer should not have typed. Access control for live chat is mostly a question about history, and history quietly accumulates value to an attacker while nobody is looking at it.
One account per person, always
Shared logins are the most common and most damaging shortcut in small support teams. They destroy attribution — you cannot tell who answered a chat or who exported an archive — and they make offboarding impossible, because removing the account locks out everyone. Individual agent accounts cost nothing and buy you a real audit trail. If your team currently shares one login, fixing that is worth more than every other control on this page combined.
Be honest about how coarse the tiers are
In most live chat products, including MyLiveChat today, the meaningful distinction is administrator versus agent: administrators change configuration and see everything, agents handle conversations. That is a fairly coarse split, and it is worth saying plainly rather than pretending a fine-grained permission matrix exists. The practical consequence is that administrator is a role to grant sparingly — every extra administrator is another account that can change settings and reach the full archive. Count your administrators today; on most teams the number is larger than anyone intended.
Offboarding is the step everyone forgets
The day someone leaves is the day access control either works or does not. Disable the agent account immediately rather than at the end of the month, rotate any API tokens or webhook secrets they created, and confirm they no longer receive chat notifications on a personal device. Departures are rarely coordinated with whoever administers the chat tool, so the only reliable fix is a written checklist owned by someone who is told about departures — not an intention to remember.
Treat integration credentials as accounts too
API tokens and webhook endpoints are access, even though they have no face. A token that can read conversations deserves the same care as a login that can: issue it with the narrowest scope that does the job, give each integration its own token so one can be revoked without breaking the others, and review the list periodically for tokens nobody remembers creating. Anything you cannot explain should be revoked — if it was genuinely in use, you will find out quickly and can reissue it properly.
How MyLiveChat fits
MyLiveChat gives every agent their own login, so conversations and archive access are attributable to a person, and administrators can disable an account the moment someone leaves. Its v1 API tokens carry granular scopes, so an integration that only needs to read conversations can be issued a token that can do only that, and each token can be revoked on its own. Departments let you narrow which agents handle account-sensitive conversations in the first place, which is the cheapest form of access control there is.
Decide who needs transcript access at all
The usual reason a team has too many accounts is that access was granted for a one-off need and never revisited. A marketing colleague wanted to read a few conversations for messaging research; a developer needed to debug the widget; a manager wanted to see what customers were asking. All reasonable, and all still logged in a year later.
Work from need rather than seniority. Agents need the console because that is the job. Whoever administers billing and settings needs admin. Nearly everyone else who wants insight actually wants a summary — the top questions, a few illustrative quotes, the volume trend — which somebody can produce for them without a standing account. That reframing removes most of the awkwardness from saying no, because you are not refusing the information, only the seat.
Write the decision down. Even three lines naming who gets an account and why turns each future request into a lookup rather than a negotiation, and it gives you something to check the account list against.
The quarterly access review
Access review sounds like enterprise ceremony; at a small company it is fifteen minutes with the account list and a colleague who knows who still works here.
- Open the agent list and read every name aloud. Anyone you hesitate over is the finding.
- Check for shared or generic logins — a support@ account that several people use makes every transcript unattributable.
- Confirm each admin still needs admin. Admin tends to accumulate because it is faster than working out what the person actually needed.
- Check the integration credentials and API tokens alongside the human accounts; they are the ones that never get reviewed because they never leave the company.
- Note the date you did it. The review's value is being repeatable, not being thorough once.
Put it in the calendar attached to something that already happens quarterly, because a standalone reminder gets dismissed.
What to measure
Three simple counts tell you whether access control is real or aspirational. Accounts versus people: the two numbers should match, and a gap is either a departure that was never processed or a shared login. Admins as a share of accounts: if most of the team is an admin, the tier has stopped meaning anything. Days from someone leaving to their access being removed, which is the number that actually matters and the one nobody tracks; if you cannot answer it for the last person who left, that is your first finding.
Keep the expectations honest while you are at it. The role model here is deliberately coarse — administrators and agents, with granular scopes available on API tokens rather than on people — so do not design a policy that assumes finer separation than the product offers. The controls that carry the weight are the number of accounts, who holds admin, and how fast an account disappears when its owner does.
Deciding who gets a sign-in is the first half of this. The second is what happens when someone repeatedly gets one wrong, which what ten failed sign-ins actually locks walks through.
Once people have access, what they change is recorded in a trail with some notable gaps in it. What your ticket history actually records is worth reading before you rely on that trail to answer a question about who did what.