Access control will not stop every breach before it starts. What it can do is more modest and more useful: decide who is allowed to do what, so that a stolen password, a rushed click, or a leftover login does not become a tour of the whole business.
I have spent more than thirty years in IT, and I now help business owners put AI to work without handing it the keys to the business. The question I want owners to ask is not only "who can log in?" It is "who can read this, change that, pay someone, or speak for us — and who should not?"
Access is permission to act, not just a password
A login is a door. Access control is what that person, or that tool, is allowed to do after they walk through it. The owner who can approve payroll, the bookkeeper who can see invoices, and the software that can draft a reply should not all hold the same keys.
Least privilege is the practical name for that idea. People and tools get the access their job requires, not extra "just in case" rights that feel convenient until something goes wrong. Convenience is usually how access spreads: a shared administrator password, a vendor given the owner's login "for now," a cloud app left connected after a project ends.
When access is too broad, a single compromised account can reach email, files, banking, and customer records at once. When access is limited, the same incident may still happen, but the blast radius is smaller. That does not promise a business will escape harm. It makes harm less likely to run the length of the business.
Separate the daily account from the powerful one
Here is a recommended scenario. It is hypothetical, not a claim about a particular client.
Imagine an owner who uses one login for everything: ordinary email, the company bank, payroll, and the administrator settings for email and files. One convincing message, or one approved prompt on a phone, and an attacker does not just read mail. They can reset other people's access, create forwarding rules, or change who gets paid.
The better pattern is separation. Use a day-to-day account for ordinary work. Keep administrator rights on a separate account used only when something actually needs to be changed, then signed out. Do the same for anyone who can alter banking details, create new users, or export a customer list. Shared logins make this almost impossible: nobody can say who did what, and a departing person cannot be cleanly removed.
MFA helps. It does not finish the job.
Multi-factor authentication is worth turning on, especially on email, banking, and administrator accounts. It asks for something beyond the password — often a prompt, an app code, or a security key — which makes a stolen password less useful.
It has limits, and those limits matter. People can approve a prompt they did not initiate because it arrived while they were busy. Some phishing sites can sit between a person and the real login and capture a session after the extra step is completed. Text-message codes can be redirected if a phone number is taken over. MFA also does nothing to shrink what an account can do after a legitimate-looking sign-in succeeds. If the account is shared, or if it can administer everything, MFA may only delay the moment of damage.
Use MFA. Then still ask what that account is allowed to touch.
People change roles. Access should change with them.
Access control is not a one-time setup. People join, they change roles, and they leave. Vendors come and go. The access that made sense in January may be too much by June.
A joiner should receive only what the new role needs, not a copy of someone else's broader permissions. A person who leaves billing for sales should lose the payment system, even if they are trusted. When someone leaves the company, individual logins should be removed promptly, and any shared passwords they knew should be changed — including those for a mailbox, file share, or vendor portal. Forwarding rules and saved sign-in sessions deserve a look at the same time.
Even when nobody has left, access accumulates. A short, recurring review — who has administrator rights, who can move money, who can export customer data, which vendors still have a login — catches leftovers no one remembers granting. The review does not require a security department. It requires a named owner and a list.
Vendor access belongs on that list. A bookkeeper, payroll service, software implementer, or other outside helper should have their own identity, with only the rights the work requires, and a way to turn that access off when the work ends. Lending them the owner's username and password is convenient. It is also a standing invitation that can outlast the contract.
Do not give tools more authority than people
The same principle applies to software, including AI. A tool that can draft an email is useful. A tool that can send payments, change vendor bank details, reset passwords, or write to customers without a person approving the action has been given authority, not just assistance.
In my own business I use an AI assistant for routine client communication, but I do not grant it permission to send until I have reviewed the draft. That is an access decision as much as a quality check: the assistant may prepare the work; it is not authorized to act for the business on its own.
Owners should ask the same question before connecting any new system to email, files, or money: what can this tool do without a person in the loop, and is that more than we intended?
Reduce the chance, and limit the spread
Access control is foundational because other defenses assume it. Training people to pause and verify matters more if the person who fails still cannot reach everything. Backups matter more if an attacker cannot also administer the systems that hold them. MFA matters more if the account it protects cannot rewrite the rest of the business.
None of that stops every breach before it starts. A determined attacker, a tired click, or a clever message can still get through. What owners can do is make that path narrower and the damage smaller: decide who can do what, separate ordinary work from powerful rights, use MFA without treating it as complete, review access as people and vendors change, and keep a human in authority over consequential actions, including those suggested by AI.
Least privilege is not a product. It is the habit of asking, before anyone or anything gets the keys, whether they truly need them.
Jason Radney is the founder and CEO of Coast2Coast MSP in Tampa Bay. With over 30 years in IT, he helps business owners adopt AI and security practices safely.