Why Your AI Employee Can't Access a Tool (and How to Fix It)

Key Takeaways

• "It can't access my tool" almost always comes down to one of four things: not connected, connected but in the wrong channel, missing the right permissions, or the data itself is out of scope.
• Start by asking your AI employee what it can see. A ten-second check tells you which of the four problems you actually have before you start changing settings.
• A connection and a channel are two different doors. A tool can be connected at the account level and still be unreachable in the channel where you are asking.
• Read access and write access are separate. "Look at this" can work while "change this" fails, and that usually means the connection needs write permission added.
• Scoped connections are a feature, not a bug. If it can reach one folder but not another, the connection was granted narrow access on purpose, and widening it is a deliberate choice.
• Most of these are two-minute fixes once you know which door is closed, and Viktor will usually tell you which one it is if you ask.

The tool is connected, so why is it acting blind?

You connected HubSpot yesterday. Today you ask your AI employee to pull this month's deals and it says it can't see them. The connection is right there in your settings, green and confirmed, so the natural reaction is to assume something is broken. Usually nothing is broken. Access to a tool is not a single on-off switch, it is a short chain of doors, and one of them is closed.

The good news is that there are only four doors, and each one has a quick, specific fix. Once you can tell which door is closed, you stop guessing and start solving. Here is how to diagnose it in a few seconds and fix whichever one is the problem.

First, ask it what it can actually see

Before you touch a single setting, ask the AI employee to tell you what it has access to. This one habit saves more time than any other, because it turns "it doesn't work" into a specific, fixable answer.

@Viktor what tools are you connected to right now, and in this channel what can you read and what can you change?

The reply tells you almost immediately which of the four problems you have. If HubSpot is not in the list, it is a connection problem. If it is connected but says it cannot act here, it is a channel problem. If it can read but not write, it is a permissions problem. If it can reach part of a tool but not the data you named, it is a scope problem. Now you are fixing the right thing instead of poking at random.

Door 1: The tool is not actually connected

Answer first: if the tool does not appear in the connected list, it was never linked, or a previous connection expired and needs to be renewed.

This is the most common case and the easiest to fix. Connections can lapse for ordinary reasons, most often because the login they were based on expired and needs to be refreshed, the same way any app occasionally asks you to sign in again. The fix is to reconnect the tool from your settings, which is a short, guided step. If you have never connected it at all, our full walkthrough of the two connection methods lives in How to Connect Any Tool to Your AI Employee.

One thing worth knowing: because connections are issued as revocable tokens rather than stored passwords, a lapsed connection never puts your account at risk. It simply stops working until you renew it, which is exactly the behavior you want.

Door 2: It is connected, but not in this channel

Answer first: your AI employee can only act in the channels it has been invited to, so a tool connected at the account level is still unreachable in a channel where the AI employee is not a member.

This one trips people up because the connection genuinely is fine. The AI employee just is not present in the room where you are asking. In Slack, the fix is to invite it to the channel the same way you would add a teammate. If you are working in a private channel or a group DM, it needs to be a member there specifically.

This is also a control you should be glad exists. The fact that access follows channels is what lets you keep the AI employee out of sensitive rooms on purpose. We cover how to use that boundary deliberately in How to Control What Your AI Employee Can Access. When a tool "will not work" in one channel but works in another, this is almost always why.

Door 3: It can read, but not write

Answer first: read access and write access are separate grants, so an AI employee can often see data in a tool while being unable to change or send anything.

If your AI employee can pull a report from a tool but cannot update a record, post a message, or send an email, the connection was granted read-only access. That is a safe default and often the right one. When you actually want it to act, you add write permission to that connection, deliberately, for that tool.

The reliable pattern here is to add write access and pair it with a checkpoint rather than turning everything loose at once. Anthropic's engineering guidance on building effective agents makes the same point: agents work best with clearly bounded permissions and a human in the loop on consequential actions. So when you grant write access, keep the first few actions in a "show me before you send" mode:

@Viktor now that you can post to Linear, draft the release note as an issue and show it to me here first. Do not create it until I say go.

You get the capability you were missing, without handing over more trust than you have tested.

Door 4: The data is outside the connection's scope

Answer first: if your AI employee can reach part of a tool but not the specific data you asked about, the connection was scoped to a narrower slice on purpose.

Many connections are granted access to specific data rather than everything, which is good practice. You might have connected one Google Drive folder instead of the whole Drive, one HubSpot pipeline instead of every object, or one repository instead of an entire GitHub organization. So when it can read your marketing folder but not your finance folder, that is scoping working as designed, not a failure.

The fix is a decision, not a bug report: if the task genuinely needs the additional data, widen the connection's scope to include it. If it does not, leave the scope narrow. Working backward from the task keeps you honest here. Grant the least access that lets the job get done, and nothing more.

The four doors at a glance

When something will not work, match the symptom to the door and you will know the fix immediately.

None of these require a support ticket. They require knowing which door is closed, which is exactly what asking the AI employee what it can see will tell you.

When to keep a door closed on purpose

It is worth remembering that a closed door is often the correct state, not a problem to solve. Stanford's 2024 AI Index reported a 32% year-over-year increase in publicly reported AI incidents, and a recurring theme is tools being handed broader access than the job required. Read-only connections, narrow scopes, and channel boundaries are the everyday controls that keep you on the safe side of that trend.

So before you widen access to make an error go away, ask whether the task actually needs it. Often the cleaner fix is to change the task, not the permissions. If the AI employee only needs to read a report, leave it read-only. If it only needs one folder, leave the scope at one folder. Fixing access is not about opening every door, it is about opening exactly the one the task needs and leaving the rest shut.

Frequently Asked Questions

My tool is connected but my AI employee says it can't use it. Why?

Most often because it is not a member of the channel where you are asking. A connection lives at the account level, but the AI employee can only act in channels it has been invited to, so add it to that channel and try again.

Why can it read from a tool but not make changes?

Read access and write access are separate. A read-only connection lets it look but not act. To let it create, edit, or send, add write access to that specific connection, ideally alongside a "show me before you send" habit.

My connection stopped working on its own. Did something break?

Usually not. Connections can expire when the underlying login needs to be refreshed, similar to any app asking you to sign in again. Reconnecting the tool from your settings fixes it, and because connections use revocable tokens, a lapse never exposes your account.

It can see some data in a tool but not other data. What's going on?

The connection was scoped to a specific slice, like one folder or one pipeline, rather than the whole tool. That is intentional. If the task needs the additional data, widen the scope; if not, leave it narrow.

How do I tell which problem I have?

Ask the AI employee directly what it is connected to and what it can read and change in the current channel. Its answer points you to the exact door that is closed before you change any settings.

Do I need admin access to fix these?

Reconnecting a tool and widening a scope are handled by whoever manages the connection, while inviting the AI employee to a channel can be done by anyone in that channel. Most fixes take a couple of minutes either way.

Access problems are usually a two-minute fix

When your AI employee cannot reach a tool, resist the urge to assume it is broken. Ask it what it can see, match the symptom to one of the four doors, and open exactly the one the task needs. Connection, channel, permission, scope. That short checklist turns a frustrating dead end into a quick fix, and it keeps you in deliberate control of what your AI employee can and cannot touch.

Add Viktor to your workspace and connect your first tool the right way

Related reading:

• How to Connect Any Tool to Your AI Employee
• How to Control What Your AI Employee Can Access
• Security Checklist for AI Tool Access