6 Corporate AI Restrictions Nobody Warns You About
Last updated: October 2026
You clicked the connector, it asked you to sign in, and then nothing happened. Or it connected to something and cannot see the system you actually needed. Or a request went to your administrator and you have no idea whether that queue is measured in hours or quarters. This post is the map of where those walls actually sit, drawn from a full research pass I did for one professional on a locked-down enterprise stack, plus a student whose work mail is blocked to AI tools outright and whose approval request on a separate account was still pending when the lesson ended. Six restrictions, in the order people hit them, and what still works while you wait.
In this post: the connector does not run on your laptop · the workaround costs more than the block · approval is a queue · reading is not writing · admin setup is not integration · security review
1. The connector does not run on your laptop
This is the single fact that explains most of what confuses people, and almost nobody is told it.
When you add a connector, the thing that reaches out to your target system is not the app on your desk. It is a service in the vendor's cloud, calling your system over the public internet. Anthropic's own custom connector documentation states it without hedging: "Servers hosted on a private corporate network, behind a VPN, or blocked by a firewall won't connect, even if you can reach them from your own machine."
Read that last clause twice, because it is the part that costs people weeks. You can open your company's internal ticketing system in a browser tab right now. That proves nothing about whether a connector can reach it, because you are inside the network and the connector is not.
| Where the system lives | Can a hosted connector reach it | What you are left with |
|---|---|---|
| Vendor-hosted cloud (the public service) | Yes, subject to admin approval | Normal connector setup |
| Self-hosted inside your firewall | No | A local connector, run from a machine on your network |
| Reachable only through the VPN | No | Same as above |
| Files on your own disk | No connector involved | Works today, nothing to approve |
The practical consequence is a fork in the road. Anything that needs to reach inside your network pushes the work into the terminal tool, because that is the surface that can run a connector locally, using your machine's own network access. Anything cloud-hosted or fully local can stay in the friendlier desktop app.
If the answer turns out to be your company's own instance, that is not the end of it, it just moves the work. Connecting the terminal tool to a self-hosted Jira and Confluence is the step-by-step version of that route, including the parts IT has to approve first.
The fix: before you plan anything, find out for each system whether it is the vendor's cloud version or your company's own instance. One question to a colleague in IT. It decides everything downstream.
2. The workaround costs more than the block
Here is the item I would most like people to read before they get creative, because the blocked connector is an inconvenience and the workaround is the thing that ends careers.
A student I worked with cannot give any AI tool access to his work mail, because his employer blocks it on security grounds. His other mail account, on a different provider, works fine. So he arrived at the obvious workaround: download the messages he needs as PDF files, then re-upload them to the provider that is not blocked, where he can work on them freely.
Look at what that actually does. The restriction was never about whether a tool is capable of reading mail. It was about where work data is allowed to sit and who is able to audit it. Downloading it and re-uploading it somewhere unblocked defeats precisely the control that was put in place, in a way the blocked connector never did. He was not being careless. He was being resourceful against an obstacle, which is how nearly every one of these situations starts.
The awkward truth is that your employer's restriction and your workaround are usually aimed at the same risk, and only one of them is documented. If your company has ruled on which tools may touch company data, the personal account route is not a clever gap in the policy, it is the policy's actual subject. The rules for keeping a chat assistant safe on company data are the short version of what a reviewer will ask you.
The fix: never solve an access problem by moving the data to an account your employer cannot see. Solve it by shrinking the task to the material that is already allowed to be where you are working.
3. Approval is a queue, not a switch
People treat administrator approval as a yes or no answer that arrives the same afternoon. It is a ticket, sitting in a queue, behind the quarter's priorities.
In a first lesson with the same student we tried to connect a mail account, using one of the accounts where it was at least possible. The request went in, it needed an administrator to approve it, and it was still pending when the session ended. Nothing was broken and nothing was refused. It simply was not answered, and no part of the interface tells you what a normal waiting time looks like.
Those two situations are worth separating, because they look identical from your side of the screen and they are not the same thing at all. A pending request is a queue, and queues move. His work mail was never in a queue: his employer had already made a decision, and no amount of patience changes a decision that has already been made. Find out which of the two you are actually in before you build a plan around waiting.
For a large office suite the gate is bigger than most people expect. The Microsoft 365 connector needs a Global Administrator to grant one-time consent for the whole tenant before any individual in that tenant can connect at all. So the answer to "can I connect my own account" is not yours to give, and it is not your manager's either. It is one person in an identity team who has probably never heard of you. Even after that consent is granted, conditional access policies can still block your specific sign-in, which is a second gate wearing the same clothes as the first. And a personal account of the same brand will not substitute, because the connector wants the work tenant.
So stop waiting passively and send something that can be answered in one reply:
Subject: Approval request, read-only AI connector for my work account
I would like to connect an AI assistant to my work account, read only.
Three questions:
1. Will a Global Administrator grant tenant-wide consent for this connector?
2. If consent is granted, do our conditional access policies allow my sign-in?
3. If the answer is no, is there an approved alternative I should use instead?
I do not need permission to create, edit or send anything. Reading my own
documents is enough for what I am doing.
That last paragraph is doing real work. Most refusals I have seen are refusals of write access that nobody ever asked for.
Half an hour spent finding out which of these six applies to you is the half hour everybody skips, and it is most of what a first 1-on-1 session with someone in your situation actually is.
The fix: send the questions in writing on day one, in a form that can be answered yes or no, and keep working on something else while the queue moves.
4. Reading is not writing
Suppose the consent comes through and the connector goes green. There is a limit inside that success which surprises almost everyone.
The Microsoft 365 connector is read-only. Claude can search and read what is in your document library, your drive, your mail and your chat history, and it cannot create a document, edit one, save a file back or send a message through that connection. It is an input, not an output.
That distinction matters because of how people imagine the workflow. The picture in their head is a loop: it reads the old proposals, writes the new one, and files it in the right folder. What you actually get is the first half. It reads the old proposals, produces the new one where you are working, and you save it yourself. Ten seconds of your time, and a completely different mental model of what you have bought.
The part worth appreciating is that the read half is the half that was hard. Getting your own material into the model is what makes the output sound like your organisation rather than like a generic template. Filing a document was never the bottleneck. If anything, the read-only boundary is the version of this a security reviewer will approve fastest, which makes it the version worth asking for.
The fix: design your workflow so the last step is a human saving or sending something. Ask for read access first, because it is both the valuable half and the approvable half.
5. "Can it set up our service desk" is admin configuration, not an integration
This one comes up whenever somebody gets excited and volunteers AI for a project at work. The request sounds like an integration problem and it is mostly a permissions problem.
Standing up a service desk means creating a project, defining request types and the fields on them, building queues, and setting the routing rules that decide who sees what. All of that happens inside the ticketing tool, performed by an account with administrator rights in that tool. No connector performs it for you, because a connector is a door, not a job title.
| What you are asking for | Who actually does it |
|---|---|
| Design the intake flow, request types and fields | Claude, and this is the genuinely hard part |
| Draft the documentation, templates and canned replies | Claude, quickly |
| Create the project, the queues and the routing rules | A tool administrator, clicking in the tool |
| Query or populate it once it exists | Claude, if it has access |
Say that split out loud before anyone commits to a date. The design work is where the thinking is, and it is the part you can deliver this week with no access to anything. I walked through the whole shape of that job in can Claude set up your Jira service desk, including which parts are a genuine time saving and which are you plus an administrator in a room.
The fix: split any "can it set up X" request into design, documentation and configuration. Own the first two, name who owns the third, and put that in writing before the deadline is set.
6. Security review is a separate gate from "it works"
For a self-hosted system, there is a route that works technically. You run a connector locally, on a machine that is on the corporate network, authenticated with a token you generate yourself. I have seen it deliver. It is also the point where four separate conditions all have to be true, and each one is somebody else's decision.
The machine has to have network access to the internal server, on the network or through the VPN. You have to be allowed to create a personal access token on that system, which administrators can and do restrict. Your security team has to accept a third-party community component holding a token to an internal system, because for most self-hosted products there is no official first-party connector to point at. And it runs in the terminal tool rather than the friendly one, which is a skills question rather than a policy question but it is still a condition.
The third of those is the one people underestimate. You are not asking permission to use a well-known product. You are proposing to run community-maintained software that holds credentials to internal company data, which is precisely the category a security review exists to examine. The conversation goes better when you frame it accurately and early: it runs locally on my machine, with a token I generated, and no company data leaves the network through it. If it helps to explain what the component actually is, the plain-English explanation of MCP is short enough to forward.
And if the review says no, that is a legitimate answer rather than a failure of your argument. The decision tree for what to do next, by the specific shape of your restriction, is laid out in when your company blocks Claude Cowork.
The fix: ask the security question before the technical one. "Will you permit a local connector holding a token to our internal server" decides whether the rest of the work is worth starting.
Start here
Do not start with the blocked thing. Start with the work that needs nothing from anybody, because for most professionals it is the larger half of the week.
Generating slide decks, drafting and restructuring documents, turning a folder of your own files into something usable, writing the intake design nobody has had time to write: none of that touches a connector, an administrator or a firewall. It runs on files that are already on your machine and already allowed to be there. In every engagement I have run against a locked-down stack, this is where the first real hours came back, and it happened in week one rather than after the approvals.
- List the five tasks that eat your week, and mark every one that only touches material already on your laptop.
- Do those first, this week, with no ticket and no waiting.
- Send the three approval questions from item 3 in parallel, then treat whatever comes back as scope rather than as a verdict on the whole idea.
If you are sitting behind one of these six right now and cannot tell which, bring it to a free Discovery Call and we will work out which paths your company will actually approve before you spend a month on one it will not.
From the session logs of AI Tutor Code: 1-on-1 Python and AI tutoring for working professionals. The restrictions above come from real engagements inside real companies, lightly anonymised.
Written by Michael Murr for AI Tutor Code: private 1-on-1 online tutoring for professionals learning Python, AI tools, Data Science, ML, and LLM engineering. 200+ students taught, 3,000+ hours delivered.
Related articles
Keep reading on related topics.
Enjoyed this article?
You can master this and more with a dedicated 1-on-1 tutor.
Book a Free Discovery Call