Why Your AI Cannot Access a Tool, and How to Fix It

It is 8:40 on a Monday. You ask your AI assistant to pull this week's HubSpot pipeline before your 9:00 standup, the same request that worked fine on Friday, and it comes back with "I don't have access to HubSpot." Nothing changed over the weekend. Nobody touched the settings. And yet a connection that ran hundreds of times is now dead, ten minutes before you need it.

This guide is a practical playbook for AI connection troubleshooting: what actually breaks between an AI platform and the tools it talks to, why "it worked yesterday" is the most normal symptom in the world, and the exact order to check things in so you fix it in five minutes instead of ninety. The failure is almost never the AI and almost never the tool. It is one of four things in the auth layer between them, and each one leaves a distinct fingerprint.

The four ways an AI loses access to a tool

Every "AI cannot access X" incident I have seen resolves to one of four failure classes. Knowing which one you are in is most of the fix.

Expired or revoked auth. The OAuth token or API key the AI was using is no longer valid. Tokens expire on schedules, refresh tokens get invalidated, admins rotate keys, and password changes silently kill sessions. This is the most common class by a wide margin, and the easiest to fix: reconnect.

Missing scopes. The connection is alive, but it was authorized for less than you are now asking of it. You connected Gmail with read access months ago, and today you asked the AI to draft and send. The token is healthy; it just does not carry the send permission. Reconnecting without changing anything fixes nothing here, which is why this class burns so much time.

Permission mismatches. The connection and the scopes are both fine, but the underlying account cannot see the data. The AI is acting as you, and you do not have access to that private Jira project, that restricted Google Drive folder, or that other rep's HubSpot deals. The AI inherits your permissions exactly; it never exceeds them.

Wrong account pairing. The AI is connected to a real, working account, just not the one you meant. Personal Gmail instead of work Gmail. The agency's old HubSpot portal instead of the client's. Stripe test mode instead of live mode. Everything "works," and every answer is subtly or completely wrong.

The reason people lose an afternoon on this is that all four classes produce nearly identical surface symptoms: the AI apologizes and says it cannot access, cannot find, or cannot do the thing. You have to look one layer down to tell them apart.

AI connection troubleshooting: the diagnosis order

Check in this order. It runs from most common to least common and from cheapest to most expensive to verify, so on an average day you stop at step one or two.

Step 1: Check connection status where you connected it. Every serious platform has a connections or integrations page showing each tool's auth state. Look for "expired," "reauthorization required," or a timestamp showing when the connection last succeeded. If the platform says the connection is broken, believe it, reconnect, and retry your original request before investigating anything else.

Step 2: Read the actual error, not the summary. "I couldn't access Jira" is a paraphrase. The underlying API response is precise: a 401 means the token is dead (class one), a 403 means the token is alive but not allowed (class two or three), a 404 on a resource you know exists usually means the connected account cannot see it (class three or four). If your platform surfaces raw error details or logs, read them before touching anything.

Step 3: Try the same action as the connected human. Open the tool in your browser, logged in as the account the AI uses, and attempt the exact operation by hand. If you also cannot see that Jira project or that Drive folder, the AI was never going to. This single test cleanly separates permission mismatches from everything else, and people skip it constantly.

Step 4: Confirm which account is actually connected. Look at the email address or workspace name attached to the connection, character by character. you@gmail.com and you@company.com look interchangeable at a glance in an OAuth consent screen and behave completely differently. If your team runs several accounts per tool on purpose, get deliberate about it; there is a full playbook in managing multiple accounts with one AI.

Step 5: Reconnect with fresh consent. If steps one through four come back clean and it still fails, disconnect fully and reconnect, paying attention to the consent screen this time. Note which account you pick and which permissions are listed. A surprising number of "mystery" failures end here because the fresh consent screen reveals the real problem: a scope you never granted or an account you never meant to choose.

If you are setting up integrations for the first time rather than repairing them, start instead with how to connect any tool to your AI, which covers the happy path this article assumes went wrong.

Expired and revoked auth: the most common culprit

Auth expiry is boring, constant, and responsible for the majority of AI connection troubleshooting tickets, so it deserves specifics.

OAuth connections work on two tokens: a short-lived access token, often valid for about an hour, and a longer-lived refresh token the platform uses to mint new access tokens silently. You never see this cycle when it works. You see it when the refresh token itself dies, and refresh tokens die for reasons that feel random but are not:

• Password changes. As of mid-2026, per Google's OAuth documentation, changing a Google account password revokes existing refresh tokens for Gmail scopes. Someone resets their password on Sunday, and on Monday the AI "randomly" lost Gmail.
• Admin session policies. Workspace admins in Google Workspace, Microsoft 365, and Okta-governed environments can enforce maximum session lifetimes or revoke third-party grants in bulk. A quarterly security review at the company level looks, from your seat, like an unprovoked outage.
• Idle expiry. Some providers expire refresh tokens that go unused for months. The integration you connected in January and first exercised in June may simply be gone.
• Key rotation. For API-key tools like Stripe, rotating the key in the vendor dashboard instantly invalidates the copy your AI platform holds. Rotation is good hygiene; forgetting the AI held a copy is the bug.
• Manual revocation. Anyone can visit their Google, Atlassian, or HubSpot security settings and remove a third-party grant. People do this during personal security cleanups without realizing what depends on it.

The fingerprint of this class: the failure is total for that tool, arrives suddenly after flawless operation, and reconnecting fixes it completely. If reconnecting fixes it for a day and then it breaks again, look at admin policies or an unverified OAuth app status, not at the reconnect button.

Missing scopes: connected, but not for that

Scopes are the itemized permissions granted at connection time: read email, send email, read contacts, manage deals, read repositories, write issues. The consent screen you clicked through listed them; almost nobody reads that list.

The failure pattern is distinctive: everything you used to do still works, and only the new thing fails. The AI has summarized your inbox for months, and the first time you ask it to send a reply, it cannot. It has read Jira issues forever, and the first transition-this-ticket request dies. That asymmetry, old actions fine and new action failing, is the scope fingerprint, and it is why step-one reconnecting often fails: many OAuth flows re-grant the same scopes you had before unless the platform explicitly requests broader ones.

The fix is to reconnect through a flow that requests the missing scope, and to actually read the consent screen this time to confirm the new permission appears. Two habits prevent the class entirely:

• Grant for intended use, not first use. When you connect a tool, think about what you will want in three months, not just today. If AI-drafted replies are plausibly in your future, include send scope now. An extra consent line today is cheaper than a mid-workflow failure later.
• Audit scopes when your usage changes. Moving from "AI reads my CRM" to "AI updates deal stages on my instruction" is a scope event. Treat it like one.

Deciding which tools deserve broad grants versus minimal ones is really a question about which integrations matter for your workflow, which is covered properly in which integrations your AI actually needs.

Permission mismatches: the connection is fine, the account is not

This is the class that generates the most confused support threads, because every diagnostic in the platform shows green. The connection is healthy. The scopes are broad. And the AI still cannot see the thing.

The principle to internalize: an AI connected through your account has exactly your permissions, no more. It is not a superuser. If you cannot open the finance team's Drive folder in your browser, the AI cannot summarize it. If the Jira project is restricted to the platform squad, your AI gets a 404 just like you would. If HubSpot's team permissions hide other reps' deals from you, your pipeline questions get partial answers with no warning that anything is missing.

Partial visibility is the nastiest variant. A hard failure announces itself; a permission mismatch that hides thirty percent of the data produces confident, wrong answers. Ask "how many open deals do we have" against a rep-scoped HubSpot view and you get a real number that is silently missing everyone else's deals. This is one reason cited answers matter: in Skopx, every chat answer cites the source records it drew from, so when a number looks off you can see exactly which records the connected account could reach and notice what is absent.

Fixing a mismatch means fixing it in the tool, not in the AI platform: ask the Jira admin for project access, get added to the Drive folder, have the HubSpot admin widen your team visibility. For team deployments, decide deliberately whose account backs each connection. A sales-manager-level account backing the CRM connection answers pipeline questions completely; an individual rep's account answers them from one seat's view. Teams building out a full stack of assistants should settle this ownership question early; how to build an AI workforce treats connection ownership as a first-class design decision, because it is.

Wrong account pairing: right tool, wrong identity

Everything works and everything is wrong: that is the wrong-account class. It happens at connection time, in one distracted click on an OAuth screen, and then lies dormant until an answer is inexplicably off.

The classic setups:

• Personal versus work Google. Your browser was signed into your personal Gmail when you connected, the OAuth picker defaulted to it, and now "summarize my unread email" summarizes newsletters and receipts instead of work.
• Multiple portals or workspaces. Agencies hold seats in many HubSpot portals; consultants sit in several Slack workspaces and Notion spaces. The consent screen asked which one, once, months ago.
• Sandbox versus production. Stripe test mode and live mode, Salesforce sandboxes, staging databases. Connecting the test environment yields plausible-looking data that is entirely fictional. If revenue numbers look strangely round or strangely small, check the mode before checking the math.
• Shared or service accounts. A connection made under a departed employee's account, or a generic ops@ login, behaves differently from what any current teammate expects, and dies entirely when that account is deactivated.

Diagnosis is direct: read the connected identity on the connections page and compare it to what you intended, exactly. Prevention is procedural: before connecting anything, check which account your browser is signed into, and use a browser profile per identity if you juggle several. On the OAuth account picker, slow down for the two seconds it takes to read the email address you are clicking.

The four failure classes at a glance

The table doubles as the diagnosis order in miniature: the classes higher up are more common and cheaper to test, so work top to bottom.

Provider-specific gotchas worth knowing

A few recurring traps, tied to the tools teams connect most. Provider behavior changes, so treat these as mid-2026 field notes and confirm against current vendor docs.

Google (Gmail, Drive, Calendar). Password changes revoking Gmail-scoped refresh tokens is the big one. Also, per Google's docs, OAuth apps still in "testing" status get refresh tokens that expire after roughly seven days; if a connection through a smaller platform dies weekly on schedule, that is likely the cause, and it is the platform's verification status, not your setup.

HubSpot. The portal picker at connection time is the whole game for multi-portal users. Also, HubSpot permissions are layered (user, team, and object-level visibility), so pipeline answers inherit whatever slice the connected user sees.

Atlassian (Jira, Confluence). OAuth grants are per site, and project-level permission schemes are famously intricate. "Cannot find issue PROJ-123" from an AI usually means the connected user lacks Browse Projects on that project, not that the issue is missing.

Stripe. Restricted API keys are the right practice, but a key restricted to read-only charges will fail the first time you ask about customers or payouts, which presents exactly like a scope failure because it is one. And test versus live mode is a wrong-account failure wearing a different hat.

Slack. Tokens are workspace-specific, and a bot-style grant only reads channels it has been added to. "Summarize #incidents" fails quietly if the integration was never invited to #incidents.

Preventing the next failure: AI connection troubleshooting before it breaks

Connections will keep breaking; auth expiry is a feature of the security model, not a bug. What separates calm teams from firefighting teams is how early they find out.

Make connection health visible on a cadence. The worst version of this problem is the automation that has been silently failing for two weeks before anyone notices the report stopped arriving. Scheduled work should fail loudly: in Skopx, workflows keep a full run history with retries and versions, so an auth failure shows up as a red run you can see, not an absence you have to notice. The broader discipline of catching quiet breakage is its own topic, covered in monitoring automations for silent failures.

Put tool status in front of someone daily. A morning briefing that reports what moved across your tools has a useful side effect: when a tool stops contributing, its silence is visible the next morning instead of at month end. Skopx's morning briefing reports what moved and what is slipping across connected tools, which in practice makes a dead connection about eighteen hours old when found rather than eighteen days.

Assign an owner per connection. Every connection should have a named human who knows which account backs it and gets asked first when it breaks. Connections made by whoever happened to be setting things up that day become orphans the moment that person changes roles.

Reconnect on identity events. Password change, key rotation, offboarding, SSO policy update: each of these should trigger a two-minute check of the connections that identity backs. Put it in the offboarding checklist explicitly; departed-employee connections are the most common source of mystery outages months later.

Read consent screens. Slowest advice, highest yield. Nearly every scope and wrong-account failure was visible, in plain text, on a screen someone clicked through in under a second.

FAQ: AI connection troubleshooting questions

Why does my AI say it lost access when nothing changed on my end?

Because something changed on another end. Token expiry timers, admin policy sweeps, provider-side security events, and password resets by teammates all invalidate credentials without any action from you. "Nothing changed" almost always means "nothing changed that I could see." Check the connection status page first; it usually names the moment the credential died.

Do I need to reconnect my AI after changing a password?

For Google accounts with Gmail scopes, yes, plan on it: password changes revoke existing refresh tokens per Google's documented behavior as of mid-2026. For most other OAuth tools a password change does not kill tokens, but SSO-governed environments often revoke sessions broadly on credential changes. The safe habit is to glance at your connections page after any password or SSO event.

Why can my AI read data from a tool but not write to it?

That is the scope fingerprint. Read and write are separate permissions granted at connection time, and your original consent covered read only. Reconnect through a flow that requests the write scope, and confirm the new permission actually appears on the consent screen before approving. If write access then fails only for specific records, you have a second, separate issue: the connected account's in-tool permissions.

How do I find out which account my AI is actually connected to?

The connections or integrations page should show the identity (email address, workspace, or portal name) attached to each tool. Read it exactly, not approximately; personal and work emails differ by a domain. If the platform does not show identity, ask the AI something only one candidate account could answer, like a message you know exists in only one inbox, and see which reality comes back.

Should one admin own all tool connections, or should each person connect their own?

For personal-productivity tools like email and calendar, individuals must connect their own; anything else is both a privacy problem and a data problem. For shared systems like the CRM, the data warehouse, or billing, a deliberately chosen account with appropriately wide visibility gives complete answers and survives individual departures. The failure mode to avoid is accidental ownership: shared infrastructure riding on whichever individual clicked connect first.

The connection shows healthy but answers are missing data. What is that?

Almost always a permission mismatch with partial visibility: the connected account sees a slice of the data, and the AI faithfully reports the slice. Test by running the same query by hand as that account. Prefer platforms where answers cite their sources, because citations make the missing slice visible instead of silently absorbed into a wrong total.

The short version

When your AI cannot access a tool, resist the urge to re-ask the question five different ways. Check connection status, read the real error, try the action by hand as the connected account, verify the identity, then reconnect with fresh consent. Four failure classes cover essentially every case: dead auth, missing scopes, permission mismatches, and wrong-account pairing, and each has a fingerprint you can spot in under a minute once you know it. Then make the next failure boring: visible run history, a daily surface where silence is noticeable, a named owner per connection, and two seconds of actual reading on every consent screen. The teams that treat connections as infrastructure with owners and monitoring stop having mystery outages; the teams that treat them as one-time setup steps have them forever.