Give each Bot its own accounts
The single most important setup step: Bot identities. Which accounts to create, how to scope them, where to store tokens, and what it costs in seats.
Why
Three reasons, in order of how often they bite: prompt injection (a Bot reading a hostile email can only misuse what it can reach), accountability (you can see which Bot did what), and revocation (a Bot that goes wrong gets its tokens pulled without locking you out of your own life).
The pattern
Email. sales-bot@, ops-bot@, finance-bot@ on your domain. This is the Bot's identity everywhere else. Google Workspace or Microsoft 365 users cost a seat each; the alternative of aliases doesn't work for tools that need a real login.
Tool seats. A user in HubSpot, a staff account in Shopify, a limited user in QuickBooks, a bot user in Slack. Pick the narrowest built-in role, or make a custom one. Where seats are expensive, decide whether the routine is worth the seat; sometimes the answer is a shared read-only export instead.
Tokens and API keys. Create them from the Bot's account, not yours. Scope them to what the routines do. Store them in connector settings or a knowledge file with restricted visibility. A token pasted into chat is a token in a transcript.
Spending. If a Bot ever needs to buy anything (it usually shouldn't), a virtual card with a low limit in the Bot's name, not your card.
What it costs
Typically two to five extra seats across your tools. Compared to one Bot with your owner session, it's the best money in the whole setup.
Approval gates
Even with its own account, a Bot that can send, pay, delete or post needs an approval step in the routine. Own accounts limit blast radius; approvals limit intent.
Verified 28 Aug 2026 · Facts about Grok Bot change during beta. See changelog.