When a business starts using AI agents, the first technical question is usually how much the agent should be able to reach. The tempting answer is everything: the CRM, the accounting package, the shared drive, the mailbox, the ticketing tool. The reasoning sounds sensible. An assistant that can see more should be able to do more, and fewer integration walls means fewer excuses for it to say "I cannot help with that".
In practice, broad access is one of the quickest ways to turn a useful pilot into a liability. More access does not make an AI better at a task. It makes the consequences of a wrong answer, a misread instruction or a compromised credential larger. The better design question is not "what can we connect?" but "what is the least this agent needs to touch in order to do this job well?"
Access is not capability. An agent with the keys to six systems still has to know which record is authoritative, which action is allowed, and who is accountable when it gets it wrong.
Why wider access feels like progress
Connecting a new system to an agent is visible, demonstrable progress. A demo in which the assistant answers a question by pulling from the CRM, the invoicing tool and last year's contracts looks impressive. It also hides the cost, because a demo has no bad data, no ambiguous customer names and no one who is surprised by what the agent did next.
There is also a tooling reason. Many integrations are set up with a single service account or a personal login that already has wide rights, because that is the quickest way to get the connection working. The permissions then stay as they were on day one. Over time the agent holds the access of a senior administrator while performing the work of a junior clerk. We describe that pattern in agent permissions broader than the task requires.
The principle that predates AI
None of this is a new idea. The principle of least privilege, defined by the US National Institute of Standards and Technology as a security principle under which a system or user is given only the minimum access needed to perform its function, has guided access design for decades. The UK National Cyber Security Centre's zero trust approach makes a related point: access decisions should be made deliberately for each request, rather than granted broadly because something sits inside the network. Microsoft's zero trust guidance describes the same stance, which is to verify explicitly and limit access to what is needed.
What AI changes is the speed and the autonomy. A human clerk with excessive access is limited by working hours and by habit. An agent acting on a mistaken instruction can touch hundreds of records before anyone looks. The same principle applies, but the margin for error is thinner.
Five ways broad access makes an agent worse
1. More sources means more conflicting answers
When an agent can read from several systems, it will meet several versions of the truth: three spellings of the same customer, two price lists, a contract in the shared drive that differs from the one in the CRM. Unless it has been told which system is authoritative, it will pick one, and it will do so confidently. This is the problem we discuss in why bad data becomes more dangerous when AI can take actions. Narrow access to well-governed data usually beats broad access to messy data.
2. Read access becomes disclosure risk
An agent that can read the whole shared drive can also repeat what it finds. A question from a junior employee about leave policy may surface a salary schedule if the underlying permissions were never tidied. In South Africa, this is also a compliance matter. The Protection of Personal Information Act requires that personal information is processed for a defined purpose and kept secure, and an agent that wanders across employee, customer and supplier records makes that purpose very hard to demonstrate.
3. Write access multiplies errors
Reading a wrong figure is an annoyance. Writing it to the accounting system, sending it to a customer or changing a supplier's bank details is an incident. Every system an agent can change is a system where an error becomes a transaction. The cost of these errors is easy to underestimate, as we outline in the financial risk of uncontrolled system access.
4. Credentials become a bigger target
An agent connected to many systems usually holds many credentials or tokens. If one is exposed through a misconfigured tool, a leaked prompt or a compromised supplier, the attacker inherits everything that credential can reach. Splitting access into small, task-specific connections limits the damage to one task rather than the whole business.
5. Accountability gets vague
When an agent can do anything, nobody is quite sure what it is supposed to do. The NIST AI Risk Management Framework emphasises that organisations should define roles, responsibilities and boundaries for AI systems and be able to map their context and intended use. A narrowly scoped agent has an obvious owner and an obvious purpose. A broadly scoped one has neither.
A practical way to decide how much access an agent needs
Instead of starting from the systems available, start from the task. For each job you intend to give an agent, answer the following in writing.
- What exactly is the task? "Draft a reply to supplier statement queries" is a task. "Help finance" is not.
- What information does it need to complete the task? List fields and record types, not just systems. A reply to a statement query may need the supplier's open invoices and payment dates, but not their bank details or contract terms.
- Does it need to read, suggest or act? Treat these as separate levels of access. Many valuable use cases only need the first two.
- What is the worst outcome of a wrong action? If the answer involves money leaving the business, personal information being exposed or a customer receiving the wrong commitment, require a human to approve the action.
- Who owns the agent, and who reviews its access? Access should be reviewed on a schedule, and removed when the task changes or ends.
This exercise often shrinks the first deployment considerably. That is a feature. A smaller scope is easier to test, easier to explain to staff and far easier to trust.
An illustrative example
The following is a hypothetical case. A Durban distribution company with 80 staff gives an AI assistant read and write access to its accounting system, order system and shared drive so that it can "answer anything about customer accounts". Within a month the assistant has correctly answered dozens of questions. It has also quoted a discount from a superseded price list, copied a customer's credit limit into an email to the wrong contact, and flagged a legitimate payment as duplicate and put a hold on it.
The company then redesigns the setup. One agent drafts answers to account queries using read-only access to current invoices and payments. Anything that changes a record goes to a credit controller as a proposed action. Price and credit data are read from a single designated source. The agent answers fewer kinds of question, but the answers are right, and staff use it.
What to check before you widen access
Before connecting an agent to one more system, it is worth asking whether the foundations are in place. Our piece on what AI agents need before they can do useful work lists the basics: clear process definitions, trustworthy data, defined ownership and a way to see what the agent did. If those are missing, extra access only spreads the weakness around. And if you are still deciding where agents belong at all, where AI agents add value and where they add unnecessary risk is a useful companion.
- Can you list every system and data type the agent can reach today?
- Is each connection using its own credential, rather than a shared administrator login?
- Is there a log of what the agent read and changed that someone actually looks at?
- Can you switch off one connection without breaking the others?
- Would you be comfortable explaining the agent's access to a customer, an auditor or the Information Regulator?
Start narrow, widen on evidence
The safest and most productive pattern is to begin with the smallest useful scope, measure how the agent performs, and widen access only when there is evidence that it is both needed and safe. Each extension should be a deliberate decision with an owner, not a side effect of a connector being available. Businesses that work this way often find that a modest, well-bounded agent delivers more value than an all-seeing one, because people trust it enough to use it.
Sources and further reading
- least privilege - Glossary - CSRC (last verified 10 October 2026)
- Zero trust architecture design principles (last verified 10 October 2026)
- Zero Trust as a security foundation (last verified 10 October 2026)
- AI Risk Management Framework (last verified 10 October 2026)
Related Mellorca reading
- How to Design Alerts for Automation Failures
- When Copy-and-Paste Is Really an Integration Problem
- Why Switching Software Is Not Always the Answer