Give people the access they need

Permission is a decision about how far a mistake can travel. An assistant allowed to read a customer record can give a poor answer. An assistant also allowed to change that record and send messages can turn the same misunderstanding into several external consequences.

The same principle applies to people and conventional automation. Access should reflect the work someone needs to do, with extra care around actions that are difficult to undo.

Separate knowing from acting

A scheduler may need to see an invoice status without being able to edit the invoice. A reporting tool may need totals without customer contact details. A useful design separates these abilities even when the platform offers an easy “administrator” shortcut.

For AI tools, read access and action access deserve separate decisions. A connected assistant may be helpful long before it is appropriate for it to approve a refund or publish a change. Expanding access should follow an established need and evidence about the work.

The Canadian Centre for Cyber Security’s baseline controls provide a starting reference for limiting permissions. The practical question is the consequence of an error with this account—not how senior, trusted or convenient its user appears to be.

Separate people from automation

Give people individual accounts where the platform supports them. Keep integrations on appropriately restricted service credentials rather than tying the whole workflow to an employee’s personal account.

Record what each automated connection does and who is responsible for it. If an invoicing integration stops after a staff member leaves, the offboarding process may have exposed a dependency that should have belonged to the business all along.

Credentials belong in a suitable password or secrets manager, with access controlled there. A shared document containing passwords creates another place to maintain and protect.

Make access changes routine

Joining, changing roles and leaving should each trigger a short check. Confirm the permissions granted, remove what is no longer needed and review any integrations or devices associated with the account.

For temporary contractors, agree when access will end. Give someone responsibility for checking that it did. When a person changes roles internally, adding new permissions without removing old ones can gradually give them access far beyond their current work.

Keep a recovery path

The business needs a way to regain control if its usual administrator is unavailable. Identify who can recover the domain, hosting, payment and identity accounts, and verify that the recovery details belong to the business.

Protect that route carefully. Recovery access should not become a casual second login that everyone uses. Document when it may be used, who approves it and how its use is recorded.

Before launch, test a few meaningful boundaries: can a contractor view another contractor’s jobs, can an ordinary user change billing settings, and can a departing staff account still open a shared link? These checks turn an abstract permission plan into observable behavior.

Practical ownership explains the broader account responsibilities. Failure and recovery covers what must happen when the normal route is unavailable.