What access to your systems does an AI worker need?
Only what its job needs: its own account, the fewest rights that do the work, the route the software maker publishes, and access you can remove any day.
·
5 minute read
An AI worker needs only the access its job needs, and no more: an account of its own in each system it works in, the fewest rights that get the job done, a connection through the route the software's maker publishes, and all of it removable by you on any day. It does not need your password, an administrator's rights or anything to do with your bank. Who grants the access, and who can take it away, is a named person in your firm.
What the law and the standards say
Three sources apply across the UK. The first two are law and the third is a recommended standard. How your firm meets them is for you and whoever looks after your IT.
UK GDPR's security principle. Personal data must be processed with appropriate security, "using appropriate technical or organisational measures". The Information Commission's Office (ICO) says there is no single standard: what is appropriate depends on your circumstances and the risk. It does say that data should be accessed, altered, disclosed or deleted only by those you have authorised, and that when you use a processor you choose one that gives sufficient guarantees about its security and put the requirement in the contract.
The Computer Misuse Act 1990. It is an offence to cause a computer to perform any function with intent to secure access to a program or data, knowing that access is unauthorised. Access to a system is something its owner authorises.
Cyber Essentials. The National Cyber Security Centre describes it as the minimum standard of cyber security the Government recommends for organisations of all sizes. One of its five controls is user access control: control who can access your data and services, and what level of access they have.
Together they say what an owner knows from hiring people: you decide who gets in, and you give them what the job needs.
How access is given to an AI worker
An AI worker's access is set up the way a careful firm sets up a new starter.
Start from the job. The role's specification lists each system the worker uses and what it does there: reads the diary, writes a note on a record, attaches a document. Access follows that list.
Its own account. The worker has a login or a key of its own in each system, never a member of staff's. That is what lets the system's own history, and the worker's log, show what the worker did as distinct from what your people did.
The fewest rights that do the work. Read-only where reading is enough. Where it writes, only to the records and fields the job covers. No administrator role.
The maker's own route. The worker connects through the way in that the software's maker publishes and your licence allows. The first step with any system is to confirm that with you. Where a maker forbids automation of an account, as LinkedIn does, that account stays in a person's hands; our guide to moving LinkedIn applicants into an ATS shows how the work is split in that case.
Removable. You, or your IT provider, can disable the account or revoke the key without asking anyone. When the role ends, the access ends.
Within that access, the same controls apply as everywhere else: high-impact actions wait for a person's explicit approval, and every action is logged.
What an AI worker is never given
Access to your bank, your payment run or a card terminal. An AI worker never moves money.
A person's own password, or a personal account.
Administrator rights, or the ability to create users or change permissions.
Systems and folders outside its job, such as HR files for a worker that keeps the CRM up to date.
What stays with a named person
Granting access. An owner, a director or the person who runs your IT approves each system and each level of access, in writing.
Reviewing it. Someone looks at the list on a schedule you set and asks whether each line is still needed.
Removing it. The same person can switch it off.
Reading the log. The person the worker reports to checks its work, as they would a new colleague's.
If an outside firm manages your IT, bring them in at the start. Our page for MSPs and IT support firms is written for the people whose clients will ask this question.
What depends on your licences, your policies and the contract
Whether a system can be connected at all depends on its maker's terms and on the licence you hold. Your own policies decide who may approve access and how often it is reviewed. The written contract covers the security the provider keeps, what you may audit and inspect, and what is deleted or returned at the end. Who on their side can reach your data is a question to ask before you sign it. On where data is held, our statement is one sentence: Your data is stored in the UK, and is never used to train AI models.
What to ask before you grant access
Which systems will the worker touch, and with what rights in each?
Does it have its own account, or does it borrow one of ours?
Does the maker of each system permit the connection on our licence?
How do we switch its access off ourselves?
Which of your people can see our data, and is that logged too?
For any one job, the worker would have an account of its own and a short written list of what it can open, agreed with you and your IT provider before anything is connected, and everything outside that job would stay closed to it. One job's list is the place to begin. Talk to our agent.
Carlos Oliveira
Founder of The AR Dept
Losing billable hours to this process every week?
Check if your team’s routine admin can be handed to an AI worker.
