Tool access per employee
Every connected app and MCP server is a per-employee switch — enabled means the employee can see and use it, disabled hides it entirely. Risky actions always stop for approval.
Tool access answers one question per employee and capability: should this employee see this tool at all? Everything else — the safety of what an employee does with an enabled tool — is handled by the approval gate, not by per-tool modes.
The model
| State | Employee may | When to use |
|---|---|---|
| Enabled | See the tool and use it, within the approval gate | The default — every connected app starts enabled |
| Disabled | Nothing — the tool is hidden from the employee entirely | Role boundaries, incidents, sensitive accounts, cleanup |
Two things make this safe:
- Risky actions always pause. Whatever is enabled, anything external or irreversible (send, post, publish, spend, delete) stops for a human decision — an inline approval card in chat, or the approvals queue. You allow once, allow for a session, or deny.
- Disabled means invisible. A disabled tool is removed from the employee's runtime configuration; the employee does not see it, cannot call it, and will not ask you for it by name.
Flip a switch
- Open the employee's channel and find Skills & tools in the right rail (or open Tool access → Employee access).
- Each connected app and custom MCP server has a switch.
- Flip it off to hide the tool from this employee; flip it on to restore access.
- Changes reach the running employee on its next provision.
Suggested boundaries
| Role | Keep enabled | Consider disabling |
|---|---|---|
| Research analyst | Web, shared files, read-heavy tools | Billing and CRM write tools it never needs |
| Sales operator | Gmail, CRM | Code and infrastructure tools |
| Content strategist | Docs, CMS, web research | Finance and billing tools |
| Finance operator | Stripe, spreadsheets | Social publishing tools |
| Engineering operator | GitHub, error tracking | Payment and outbound email tools |
Treat this as a starting point. The goal is a tight surface per role — not because an enabled tool is dangerous (approvals cover that), but because a smaller toolset keeps each employee focused and easier to reason about.
Review questions
- Does the role still need to see this capability?
- Is the connected account the correct one?
- Would an incorrect action affect a customer, money, code, or production data? (If yes, that action class stops for approval regardless.)
- Is a human clearly responsible for approvals in this workspace?
Access should stay one decision per tool: on or off. The approval gate carries the risk judgment so the switches don't have to.
GitHub code workflows
Connect GitHub, grant scoped access to an engineering AI employee, and keep code changes inside the repository review process.
Connected accounts and employee access
Understand the difference between a workspace connection and an AI employee's tool switch, and where the approval gate carries the risk decision.