A small team I was helping brought on a part-time contractor last year to handle customer support tickets, someone who needed to look up account details to answer questions. The fastest way to get them set up, with everyone moving quickly, was giving them the same admin dashboard login the core team used, the one with full access to every customer record, every setting, every account across the entire product.
Why that felt reasonable at the time
Building a separate, scoped-down support view, one that only shows what a support role actually needs and nothing else, is real engineering work: deciding exactly what fields to include, building a distinct interface, testing it separately. The full admin dashboard already existed and already worked. Handing over the same login felt like the obvious shortcut for someone starting in a few days, with the scoped version treated as a nice-to-have for later.
What that access actually included
The full admin login could view every customer's complete billing history, could see and edit account permissions, could access internal notes never meant to be customer-facing, and could reach configuration settings entirely unrelated to answering a support question. None of that was necessary for the actual job: look up an account, answer a question, resolve a ticket. All of it came along anyway, because the access wasn't scoped, it was just handed over wholesale.
Why this is a bigger risk than it initially feels like
This isn't really about distrusting the contractor personally. It's that broad, unscoped access held by anyone outside the core team is a wider door than the job requires, and every additional person holding that door open is another place a mistake, a compromised device, or a simple misunderstanding about what shouldn't be touched can turn into a bigger problem than the role itself ever needed to allow.
What actually changed once I looked at it properly
- Built an actually scoped support view, even a simple one, showing only what a support ticket realistically requires: name, contact info, order or account status, nothing about billing internals or account configuration.
- Reviewed every non-core-team account with any kind of standing access and asked, specifically, whether their actual daily task required what they currently had, versus what was just convenient to grant on day one.
- Started treating 'give them the same access the core team has' as the shortcut it actually is, worth naming honestly as a shortcut rather than a real access decision, every time it comes up again.
The lesson wasn't about that specific contractor at all. It was that 'give them access to the customer database' is a sentence that sounds like a small, specific ask, and it's worth stopping to ask exactly what that access actually includes before handing it over, rather than assuming the fastest login to set up is the right amount of access to grant.