The risk isn't the AI. It's the access you bolt on around it.
Giving your team AI access is the easy part. The risk is not the model: every connected tool is an unscoped key, with no record of what it did.
Plenty. The subscription is the safe part. The damage starts the moment you connect that AI to your real systems, because every connection you add is an unscoped key, and almost nothing is writing down what the agent does with it.
A modern AI assistant is only as useful as the tools it can reach: your email, your CRM, your code, your database, your internal APIs. Each one is a click to add and, by default, wide open. The agent can use it as fully as the person who connected it.
This is not a knock on Claude, or on any model. The model is not the hole in the boat. The access you bolt on around it is.
The risk is not the model. It is the access around it.
When you connect a tool to an AI assistant, you are handing the agent a credential. Most tool connections grant broad access, because asking for narrow access is more work and the broad option just works. So the agent that was meant to read one calendar can often read every calendar, send mail as you, or query the whole database.
The model is not malicious. It does not need to be. All it takes is a confused instruction, a poisoned web page, or a tool that does more than you expected, and that broad access becomes the blast radius of the mistake.
Every connected tool is a master key
An over-privileged AI agent is one that holds more access than its task needs. It is the default state, not the exception.
Connect one tool for one job and the agent frequently inherits read and write access to an entire system: the whole repository, the full ticket queue, every record in the CRM. Each person who does this adds another key to the ring. The blast radius of any single error grows with every connection, and nobody is tracking the total.
Shadow MCP: the access you cannot see
The Model Context Protocol, or MCP, is the standard way to connect tools to AI agents. It is excellent, and that is part of the problem: it is so easy that people wire up their own.
Shadow MCP is when employees run their own local tool servers against sensitive internal systems, outside any central visibility. It is the AI-era version of shadow IT, except the connections can write, not just read, and they appear faster than any IT team can catalogue them. You cannot govern access you do not know exists.
No audit trail: you cannot answer "what happened?"
The first question after any incident is simple: what did it do, and to what. With most AI tool setups, you cannot answer it. There is no single record of which agent called which tool, on whose behalf, with what result.
That is a problem long before a breach. It is the question a compliance team asks on an ordinary Tuesday, and "we are not sure" is not an answer that survives an audit.
These risks are not hypothetical. In one publicly reported case, a Supabase MCP server could be manipulated into exposing an entire SQL database. In another, a GitHub MCP setup could be steered into reaching private repositories. Both were documented and discussed at length, and both came down to the same root cause: broad access with no boundary and no record.
Default access vs governed access
| Concern | Default setup | Governed access |
|---|---|---|
| Tool scope | Broad, as the user | Scoped to the task |
| New connections | Added ad hoc, per person | Assigned by role, centrally |
| Visibility | Unknown agents and servers | Known and catalogued |
| Record of actions | Scattered or none | One queryable audit log |
| Blast radius of a mistake | The whole connected system | The slice the task needed |
When this becomes a real risk
You can live with the defaults while AI is a couple of people experimenting. The risk becomes real when several things are true at once: more than a handful of people connect AI to live systems, those systems hold customer or financial data, and you could not produce a log of what the agents did last week if someone asked.
At that point the missing piece is not a better model. It is the layer that scopes each tool to its task and records every action, so you can give people powerful AI without giving everyone a master key. That governed layer is what Connor is built to be.
Frequently asked questions
- Is it safe to give my team AI access?
- The subscription is the safe part. The risk starts when the AI is connected to real systems: each connected tool is a credential, most grant broad access by default, and almost nothing records what the agent does with it. Safety is a property of how the access is scoped, not of the model.
- What is an over-privileged AI agent?
- One that holds more access than its task needs — which is the default state. Connect one tool for one job and the agent often inherits read and write access to the whole system: every calendar, the full repository, every CRM record. A confused instruction or a poisoned page turns that reach into the blast radius of the mistake.
- What is shadow MCP?
- Employees running their own MCP tool servers against sensitive internal systems, outside any central visibility. It is the AI-era version of shadow IT, except the connections can write as well as read, and they appear faster than any IT team can catalogue them.
- When do AI access risks become real?
- When more than a handful of people connect AI to live systems, those systems hold customer or financial data, and you could not produce a log of what the agents did last week if someone asked. At that point the fix is a layer that scopes each tool to its task and records every action.