How to Introduce AI Without Giving It Uncontrolled Access

Why does access decide how much an AI mistake costs?

Most AI conversations begin with capability: what can it do? The more useful question is narrower. What can it reach, and what can it change without asking? A model that writes a weak summary wastes five minutes. The same model with write access to your accounting software, an email account and your customer records can spend a fortnight of someone’s time being confidently wrong in public. Capability decides how useful a system is. Access decides what a mistake costs.

The principle behind this is old and dull, which is why it holds. NIST defines least privilege as designing a system so that each entity is granted the minimum resources and authorisations it needs to perform its function. Nothing in that changes because the entity is now a language model. What does change is that the entity decides for itself which of its permissions to use, and it can be argued into using them by the contents of a document it was asked to read.

What does read before write mean in practice?

Split any system you are considering into two halves. Reading is looking at documents, records, messages and past work. Writing is changing something in the world: updating a record, sending a message, issuing a credit note, booking a slot. Reading can expose information. Writing creates work, spends money and reaches customers. The two deserve different levels of trust, and they can be granted months apart.

A read-only first release is not a wasted release. The system prepares the work and a person completes it, which is close to how the human decision should be designed into the workflow in any case. Meanwhile you collect the things you will want before widening access:

• Real cases, including the awkward ones no demo ever contains.
• A correction rate measured by the people reviewing the output.
• A cost per completed item based on actual volumes, not an estimate.
• Evidence of which formats, languages and requests defeat it.
• Time for the team to learn where the system is dependable.

Write access then becomes something a system earns, one action at a time, on evidence you could show a sceptical colleague.

Should the system use its own account or a person’s login?

Its own. Give each AI system a named service account created for that workflow, with permissions granted to it directly. Borrowing an employee’s login is the common shortcut and it costs you three things. You cannot tell from a log whether the person or the system acted. You cannot switch the system off without locking out the person. And it inherits every permission that colleague has collected over six years, including the ones nobody remembers granting.

One account per system per environment is a sensible rule, and the staging account should never hold live credentials. Give the account an owner, a review date and the narrowest role your software allows. If your accounting package offers only administrator or read-only, that is a real constraint, better discovered during scoping than during a rollout.

There is one useful exception. When a system answers questions from internal knowledge, the safer design is for it to act with the permissions of the person asking, so a question cannot return a document that person could not already open. Scheduled workflows have no person to inherit from, which is precisely when a tightly scoped service account matters most.

How do you grant permissions per action rather than per system?

Connect the CRM is not a permission. It is a bundle of several dozen. The work worth doing before a build takes an afternoon: list every tool the workflow touches, then write down, for each one, what the system may read and what it may change. Anything absent from that list is refused by default rather than allowed by oversight.

The OWASP GenAI Security Project calls the failure mode excessive agency: damage done when a system holds more functionality, more permissions or more autonomy than its task requires. Its guidance is refreshingly practical. Keep the set of available tools small, avoid open-ended ones, and check authorisation inside the system being changed rather than trusting the model to restrain itself.

Where should the system run before it touches live data?

Build and test in a separate environment with copies of your data, masking personal details wherever the workflow does not need them. A staging copy of your customer table carries the same obligations as the original, so it is not the place to relax about who has access.

Then run a dry run in production. The system works on live inputs, prepares the action it would take and records it, but executes nothing. For two or three weeks you compare what it would have done against what the team actually did. That comparison is the most honest evaluation available to you, and it costs nothing but attention. It also exposes the failures worth rehearsing: a tool that times out, a duplicate document, a record that changed halfway through the job.

How should keys, secrets and vendor terms be handled?

Every connection needs a credential, and credentials spread. Keep them in a secrets manager or the vault your platform provides, never in a prompt, a spreadsheet or a code repository. Issue one per system per environment so that revoking one stays narrow, rotate them on a schedule, and revoke them when a contractor, a vendor or a workflow goes away. If a key ever appears in a chat message, treat it as compromised and replace it that day.

Then read the terms of the services you connect. The UK National Cyber Security Centre’s guidelines for secure AI system development treat supply chain security and secure deployment as parts of the lifecycle rather than afterthoughts, and the same logic applies to a business buying a service. Four questions cover most of it: whether your inputs are used to improve the vendor’s models, how long prompts and outputs are retained and who can read them, which sub-processors and regions are involved, and how your data is exported and deleted when you leave.

Write the answers down beside the system rather than trusting a sales call. Where personal data is involved they carry legal weight as well as commercial weight, which our guide to India’s data protection framework takes further, and the exit terms belong with vendor lock-in.

What about staff pasting company data into public AI tools?

This is usually where the real exposure sits, and it is almost never on anyone’s register. People paste a customer email, a draft contract or a supplier price list into whichever free tool is open in the browser, because it saves twenty minutes and nobody told them otherwise. A ban announced by email does not fix it. It moves the same activity onto personal phones, where you can see none of it.

What works is a pairing: an approved route plus a short written rule. Give people accounts on tools your business controls, with the data settings you chose, and publish an acceptable-use note somebody will actually read. One page is enough.

• Which tools are approved for work, and on which accounts.
• What must never be pasted anywhere: customer personal data, identity and bank details, passwords, unreleased pricing.
• What always needs a person’s check before it reaches a customer or a regulator.
• That any output is a draft, and the person who sends it owns it.
• Who to ask when the rule is unclear, and how to report a mistake without blame.

Then check whether the approved route is genuinely easier than the shortcut. If signing in takes four steps and the free tool takes none, people will keep taking the shortcut, whatever the policy says.

What does a staged rollout actually look like?

1. Read-only, one team, real work. Nothing the system produces leaves the building unchecked.
2. Dry-run writes. The system prepares actions and logs them; people still do the doing.
3. Narrow writes with approval on every case, inside one workflow and one set of records.
4. Raise limits one action type at a time, only where the correction rate supports it.
5. Widen to a second team after the first has run a full month, including a month-end.
6. Book the review date now, and agree in advance what would make you narrow access again.

None of this is expensive. It is mostly a matter of deciding things in a particular order, and of writing down decisions that would otherwise live in one person’s head. At BYBO, access rules, approvals, logging and failure handling are part of how we work on every build, and our Infrastructure & Governance work supports teams that need those foundations across several systems, or a review of what is already running.