Give AI tools access without sharing the owner’s login

Use supported delegated access, named team accounts or dedicated service identities where the software offers them. Keep owner recovery and administrative control with the business. Do not distribute the owner’s password as the normal way staff or assistants get work done.

NIST’s small-business guidance recommends limiting access to people who need it, restricting administrative privileges and removing access when needs change. It also recommends multifactor authentication for accounts that support it. Those measures complement each other; an extra sign-in factor does not limit what a signed-in account may do.

Write an action list before connecting a tool: read analytics, draft a dashboard, update a project status or send approved messages. Treat each as a separate capability. A reporting assistant may need read access but no ability to change billing, delete projects or manage other users.

Inspect the permissions the provider actually grants. A tool’s menu may hide a dangerous action while its underlying credential still permits it. When the available grant is broader than the job requires, record that limitation and choose a narrower account, project or integration where practical.

Use separate accounts or environments for unrelated businesses and sensitive functions. A label such as “finance assistant” does not create separation if the same runtime can reach every credential. The account and system permissions need to match the boundary you describe.

For a local agency, client delivery, company finances and personal accounts should not become one unrestricted pool. Document which projects an integration may access and who can approve broader access. Store secret values in the appropriate protected system, not in task descriptions or customer records.

• Purpose and accountable owner.
• Allowed applications, projects and actions.
• Credential location by reference, without its value.
• Date access was verified.
• Removal procedure and review date.

Before relying on the connection, verify how to disable the workflow and revoke the underlying grant. These may be different controls. Pausing a job does not necessarily invalidate its credential, and closing a chat does not necessarily stop a scheduled task.

Use a harmless read or controlled test to confirm the intended boundary. Include access review when a teammate leaves, a project ends or the assistant’s role changes. Durable access should mean a dependable setup with accountable limits, not permission that nobody remembers how to remove.