## Key Takeaways

- **An AI employee should have the access of an employee, not the access of an admin.** The right mental model is membership: it sees the rooms it has been invited into, and nothing else.
- **Channel membership is the permission system.** Viktor reads a channel only if he is a member of it. Invite him with `/invite`, remove him like any other member, and the access changes with the membership.
- **Privacy follows the people in the conversation.** DMs stay between the participants. What happens in a private channel is only available to the members of that private channel, and access updates automatically when people join or leave.
- **Joining and leaving channels goes through approval.** Viktor does not wander into rooms on his own. Adding him to a channel or asking him to leave one is an explicit, visible action.
- **Sensitive actions are review-first by default.** Sending external emails or posting on your behalf starts as a draft you approve, so scope of access and scope of action are two separate controls.
- **You can narrow behavior with plain instructions.** "Only respond when mentioned", "stay out of the exec channels", "never post in #announcements" are standing rules you set in chat, not settings buried in a config page.

## The question behind the question

When a founder asks "can I control which channels the AI sees?", they are rarely asking about features. They are asking whether they can put an AI employee next to their finance channel, their hiring discussions, and their customer escalations without those three worlds bleeding into each other.

It is the same question you would ask about a new human hire, and the useful answer looks the same too. You would not give a new operations hire a master key to every room in the building. You would add them to the projects they work on, keep sensitive rooms invite-only, and expect them to ask before walking into a meeting. An AI employee should be held to exactly that standard, and this post walks through how that works in practice with Viktor in Slack and Microsoft Teams.

## Membership is the permission model

The core rule is simple: **Viktor sees a conversation only if he is a member of it.** There is no workspace-wide crawl behind the scenes and no separate access list to maintain. The channel roster you already manage is the access control.

That single rule produces the behavior you would expect from a careful colleague:

- **Public channels:** Viktor participates where he has been invited. A channel he is not in is a channel he does not read.
- **Private channels:** membership works the same way, with one addition. What happened in a private channel is only available to people who are members of that private channel. Viktor will not carry private-channel content into answers for someone who is not in the room.
- **DMs and group DMs:** visible to the participants of that conversation, nobody else. A teammate cannot ask Viktor what you discussed with him in a DM.
- **People join and leave:** access follows automatically. When someone leaves a private channel, they do not keep a side door into its history through the AI.

The last two points are where an AI employee differs most from a generic chatbot integration. Many bots operate with one shared identity: whatever the bot can see, anyone who can message the bot can effectively query. Viktor scopes answers per person, so each teammate can only draw on conversations that they themselves have access to. The AI never becomes a way to route around your own workspace permissions.

## Scope of access vs scope of action

Access control answers "what can it see?". The second control, which teams forget to ask about, is "what can it do without asking?".

These are separate dials, and they should be. You might be comfortable with your AI employee reading the whole support channel but still want every outbound customer email to pass a human. Viktor's default is review-first: sensitive actions like sending an email or posting on your behalf start as drafts, and you approve them before anything leaves the building. Even Viktor joining or leaving a channel goes through an explicit approval rather than happening silently.

Here is how the two dials combine across surfaces:

| Surface | Who can see the conversation | When Viktor responds | What leaves without approval |
| --- | --- | --- | --- |
| Public channel | Channel members | When @mentioned | Nothing sensitive; drafts wait for approval |
| Private channel | Channel members only | When @mentioned | Same, plus content never leaves the member circle |
| Group DM | Participants only | When addressed | Same |
| 1:1 DM | You and Viktor | Every message | Same |

The channel default is worth spelling out: in channels, Viktor works when @mentioned, the way you would tap a colleague on the shoulder. He is not injecting himself into every conversation just because he is in the room. In a 1:1 DM there is no ambiguity about who is being addressed, so you just talk.

## Setting boundaries in plain language

Because an AI employee reads instructions the way a person does, most scoping does not need a settings page. You state the rule once and it becomes standing behavior:

```prompt
@Viktor a few ground rules for this workspace: only respond in channels when
you are mentioned, never post in #announcements, and don't join any channel
unless someone on the team invites you.
```

This is also the answer to the "quiet AI" question we hear from teams who want help without noise. Common standing rules that work well:

1. **Mention-only mode.** "Only respond when explicitly mentioned" keeps Viktor silent in busy channels until called.

2. **No-go zones.** "Stay out of #exec and #people-ops" is a durable instruction, and since joining requires an invite and approval anyway, the rule has teeth twice over.

3. **Posting restrictions.** "Never post in #announcements, drafts only" separates the channels where Viktor may speak from the ones he may only read.

4. **Per-channel behavior.** "In #support, always reply in a thread" or "in #sales, keep answers to three bullets" scopes tone and format to the room.

If a rule matters, say it in the channel it applies to. The instruction becomes part of how Viktor operates there, visible to the team that set it.

## Rolling it out: a room-by-room pattern

Teams that are happiest with their AI employee's footprint tend to follow the same rollout shape. It takes about a week and requires no policy documents.

**Start with one working channel.** Pick the channel where the actual work happens, such as #support or #marketing, and `/invite` Viktor there. One room, real tasks, low stakes.

**Add the DM layer.** Individual teammates message Viktor directly for their own work. This costs nothing in terms of shared exposure, since DMs stay between the participants.

**Expand by invitation, not by default.** When another team wants in, they invite Viktor to their channel. Access grows exactly as fast as trust does, and every expansion is a visible membership change someone chose to make.

**Keep sensitive rooms clean.** Finance, legal, and people channels simply never get the invite, or get it last, once the team has seen how membership scoping behaves everywhere else. Nothing needs to be configured to make this safe. Absence of membership is the control.

The pattern mirrors how you onboard a person: probation in one team, then broader access as they prove themselves. The difference is that revoking access is one click and zero awkwardness.

## What this replaces

Before membership-scoped AI, teams typically chose between two bad options: a bot with workspace-wide read scopes that saw everything from day one, or no AI in chat at all, with people copy-pasting conversations into a chatbot window and losing the context and the audit trail in the process.

Membership scoping is the third option. It is less exciting than an "AI reads everything and knows all" pitch, and that is precisely the point. Your AI employee earns rooms the way a person does. If you want the deeper checklist for what to verify before connecting any AI to your company's tools, our [security checklist for AI tool access](/blog/security-checklist-for-ai-tool-access) covers the tool-connection side, and [how to connect any tool to your AI employee](/blog/how-to-connect-any-tool-to-your-ai-employee) covers the mechanics of granting it.

## Frequently Asked Questions

### How do I add Viktor to a channel, and how do I remove him?

Like any teammate: `/invite @Viktor` in the channel adds him, and removing him from the channel removes his access to it. In Microsoft Teams, the equivalent is adding the app to a team. There is no separate access console to reconcile against your channel list.

### Can Viktor read channels he is not a member of?

No. Membership is the boundary. If Viktor is not in a channel, its content is not available to him, and he cannot be asked to summarize or search it.

### If Viktor is in a private channel, can other teammates ask him about it?

Only members of that private channel can draw on its content. Someone outside the channel asking Viktor about it gets nothing, because access is scoped per person, not per bot. The same applies to DMs and group DMs, which stay between their participants.

### Can I make Viktor respond only when mentioned?

In channels, that is already the default behavior: Viktor works when @mentioned rather than reacting to every message. You can tighten it further with a standing instruction, for example telling him to never respond in a specific channel even when mentioned.

### Does Viktor join channels on his own?

No. Joining and leaving channels goes through an explicit approval flow. If you never invite him to #finance, he is not in #finance.

### What stops the AI from acting on something sensitive it read?

Two separate controls. Access scoping limits what he can read in the first place, and review-first drafts mean sensitive outbound actions like emails wait for a human approval before they go out. Reading a channel never silently becomes acting on the world.

### Does this work the same in Microsoft Teams?

The model is the same: Viktor works where he has been added, 1:1 chats stay private, and the same review-first behavior applies. If your organization gates app installs, your IT admin approves Viktor once in the Teams admin center and controls who can add him from there.

## Small footprint first, then earn the building

The best way to think about AI access is the way you already think about people access. Nobody starts with the master key. Invite your AI employee into one room where real work happens, let the team watch how membership scoping behaves, and let every additional door be a decision someone made on purpose.

[Add Viktor to one channel and see how a scoped AI employee works](https://viktor.com/?utm_source=blog&utm_medium=cta&utm_campaign=how-to-control-where-your-ai-employee-works)

Related reading:

- [Security Checklist for AI Tool Access](/blog/security-checklist-for-ai-tool-access)
- [How to Connect Any Tool to Your AI Employee](/blog/how-to-connect-any-tool-to-your-ai-employee)
- [Why Your AI Employee Should Live Where You Work](/blog/why-your-ai-employee-should-live-where-you-work)