## Key Takeaways

- **You control access with two dials, not a settings maze.** Channels decide where your AI employee can operate, and per-tool connections decide what it can touch.
- **Channel access is your first boundary.** Your AI employee only reads and acts in the channels you invite it to. Leave it out of a channel and that channel is invisible to it.
- **Read access and write access are separate decisions.** Start a tool in read-only mode so it can look but not change anything, then add write access when you actually want it to act.
- **Scope the connection, not just the tool.** Good connections grant access to specific data, like one Google Drive folder or one HubSpot pipeline, instead of everything at once.
- **Access is reversible in one click.** You can revoke a tool or remove the AI employee from a channel at any time, and the access is gone immediately.
- **Least privilege is the whole game.** Grant the narrowest access that lets the task get done, widen it only when a real task needs it, and you keep control without slowing anyone down.

## The question every careful team asks before connecting anything

Before a good operator gives an AI employee access to Slack, Google Drive, or HubSpot, they ask the same thing a good manager asks before handing a new hire a set of keys: what exactly can it see, what can it change, and how fast can I take that back? It is the right instinct. The mistake is assuming the answer is buried in a complicated permissions panel. It is not. You control an AI employee's access with two simple dials, and once you see them, the whole thing stops feeling risky.

This matters because access is where trust is won or lost. Stanford's 2024 AI Index reported a 32% year-over-year jump in publicly reported AI incidents, and a large share of the ones that hurt come down to a tool getting more access than it needed. So here is exactly how to decide what your AI employee can reach, how to keep it narrow, and how to pull access back the moment you want to.

## What are you actually controlling?

Answer first: you are controlling two things, and they are independent. One is *where* your AI employee can operate, which in Slack means channels. The other is *what* it can touch outside Slack, which means the tools you connect and the access each connection grants.

Think of it as location and keys. A new hire can be in the building (a channel) without having a key to every room (a connected tool), and a key can open one filing cabinet (read-only) or let them rewrite the files inside (write access). Your AI employee works the same way. Nothing is all-or-nothing, and nothing happens by default. Every bit of access is something you granted and can revoke.

The rest of this guide is those two dials, one at a time.

## Dial one: which Slack channels can it see?

Your AI employee can only read messages and act in the channels you have invited it to. A channel it has not joined does not exist as far as it is concerned. This is the cleanest access control you have, because it maps to something everyone on the team already understands: who is in the room.

That gives you a few practical moves:

- **Keep it out of sensitive channels.** If a channel discusses legal, HR, or anything you would not want summarized by a teammate, simply do not invite it. There is no separate "hide this from the AI" toggle to forget, the boundary is membership itself.
- **Use a dedicated channel for its work.** Many teams create a channel like `#ai-tasks` and do the bulk of their delegation there, keeping the AI employee's footprint obvious and contained.
- **Remove it in one action.** If you ever want it out of a channel, remove it the same way you would remove a person. Access to that channel's history and future messages ends immediately.

Because access follows the channel, deciding channel membership is also deciding your access policy. That is a feature, not a coincidence.

## Dial two: read access vs write access

Answer first: read access lets your AI employee look at data in a connected tool. Write access lets it change or create things. They are separate grants, and you should almost always start with read.

Starting read-only is the single best habit for staying in control. In read-only mode, your AI employee can pull a report from HubSpot, read a doc in Google Drive, or check an issue in GitHub, but it cannot edit, delete, or send anything. You get all the "go find this out for me" value with zero risk of it changing something you did not expect.

When you are ready for it to *act*, you add write access deliberately, for that one tool, when a real task needs it. The progression looks like this:

| Access level | What it can do | Good first use |
| --- | --- | --- |
| No connection | Nothing in that tool | Tools you have not connected yet |
| Read-only | Look up and summarize data | "Pull this month's HubSpot pipeline" |
| Write | Create, edit, or send | "Draft and post a Linear update" |

You do not have to climb the whole ladder. Plenty of tools stay read-only forever because reading is all you want from them. The point is that moving from read to write is a choice you make, not a default you inherit.

## Scope the connection, not just the tool

There is a level below read-versus-write that careful teams use: scoping the connection to specific data. When a tool supports it, you can connect one Google Drive folder instead of the whole Drive, one HubSpot pipeline instead of every object, or one repository instead of an entire GitHub org.

This is least privilege in practice: grant the narrowest access that still lets the task get done. A useful way to make the decision is to work backward from the task. If the job is "summarize the deals in our new-business pipeline," the connection needs that pipeline, not your full CRM. If the job is "draft release notes from this repo," it needs that repo, not every repo you own. Scoping down does not make the AI employee less capable at its job, it just removes access it was never going to use.

Here is the kind of scoped request that keeps things tight:

```prompt
@Viktor using only the #new-business channel and our new-business pipeline in HubSpot, list every deal with no activity in 7 days and draft a nudge for each owner. Show me the drafts, do not send.
```

Notice three controls in one line: a single channel, a single pipeline, and "show me, do not send." That is scoped access and a human checkpoint working together.

## How do you take access back?

Answer first: instantly, from either dial, and without asking anyone. Remove the AI employee from a channel and it loses that channel immediately. Disconnect a tool and the access is revoked at once. Because OAuth connections are issued as revocable tokens rather than shared passwords, cutting one off does not require changing your own login anywhere.

This reversibility is what makes it safe to experiment. You are not making a permanent decision when you connect a tool or add it to a channel. You are making a decision you can undo in a click the moment it stops being useful, which means the cost of trying something is low and the cost of a mistake is contained.

## Keeping a human in the loop where it counts

Access controls decide what your AI employee *can* reach. A review-first habit decides what actually goes out the door, and it is the other half of staying in control. Even with write access granted, the reliable pattern is to have it draft and show you before it sends or changes anything that matters. Anthropic's engineering guidance on building effective agents lands on the same conclusion: bounded tasks with human checkpoints beat an agent given broad, unsupervised reach.

In day-to-day terms that means write access plus a "show me the draft" instruction, not write access plus blind trust. You keep the speed of delegation and the safety of a second pair of eyes. As the connection proves itself on low-stakes work, you can let more of it run without a checkpoint, on your timeline. For a fuller pre-connection checklist, see [Security Checklist for AI Tool Access](/blog/security-checklist-for-ai-tool-access).

## Frequently Asked Questions

### Can my AI employee read every channel in Slack?

No. It can only read and act in the channels you have invited it to. Any channel it has not joined is invisible to it, so channel membership is your primary access boundary.

### What is the difference between read and write access?

Read access lets your AI employee look at data in a connected tool, like pulling a report. Write access lets it change or create things, like editing a doc or sending a message. They are separate grants, and starting read-only is the safest default.

### Can I connect just one folder or one project instead of a whole tool?

When the tool supports it, yes. You can scope a connection to a specific Google Drive folder, a single HubSpot pipeline, or one GitHub repository, which follows the least-privilege principle of granting only the access a task actually needs.

### How do I revoke access?

Remove the AI employee from a channel to cut off that channel, or disconnect a tool to revoke its access to that tool. Both take effect immediately, and because connections use revocable tokens, you never have to change your own password.

### Does giving write access mean it can send things without me?

Only if you let it. The recommended pattern is to pair write access with a "show me the draft first" instruction, so it prepares the action and you approve before anything sends. You widen that trust as the connection proves reliable.

### Who decides these access settings?

Whoever manages the workspace controls tool connections, and anyone can control channel access by inviting or removing the AI employee from channels. Access follows channels and connections, not a per-person permission list.

## Set the boundaries, then delegate with confidence

Controlling what your AI employee can access is not a security project, it is two dials you already understand: which channels it is in, and what each connected tool lets it do. Keep both narrow to start, add write access only when a task needs it, scope connections to the specific data that matters, and remember you can pull any of it back in one click. Set the boundaries once and delegation stops feeling like a leap of faith.

[Add Viktor to your workspace and set access on your terms](https://viktor.com/?utm_source=blog&utm_medium=cta&utm_campaign=how-to-control-what-your-ai-employee-can-access)

Related reading:

- [How to Connect Any Tool to Your AI Employee](/blog/how-to-connect-any-tool-to-your-ai-employee)
- [Security Checklist for AI Tool Access](/blog/security-checklist-for-ai-tool-access)
- [How to Set Up Your AI Employee in Slack](/blog/how-to-set-up-your-ai-employee-in-slack)