If an AI agent uses your account to work in the CRM, shared inbox or finance system, you have lost one of the simplest security controls before it does any work.
The agent needs its own identity. That gives you a clean record of what it did, lets you limit its access and allows you to stop it without locking a member of staff out of their job.
My rule is blunt. An AI agent never borrows a human login.
The NCSC advice is specific
The National Cyber Security Centre has published interim advice on managing the cyber risk of agentic AI. It recommends assigning every agent its own unique identity in a class that distinguishes it from people and other systems.
The guidance describes credentials as part of an agent’s potential “blast radius” when it behaves unexpectedly. Those credentials include API keys, OAuth grants, SSH keys and authenticated sessions. Each one carries the permissions of the identity behind it.
The NCSC also warns about agents running inside a normal user’s environment. They may be able to use credentials already available to that user account, whether you meant to share them or not.
This can happen without anyone typing a password into a prompt. A browser session is already signed in. A developer’s laptop has cloud credentials saved locally. A desktop application holds a token. The agent inherits a route into the system because the person running it already had one.
A borrowed login hides who acted
Most business systems record an actor beside a change. That record is valuable only when the actor is real.
If a person and an agent share an account, the audit trail cannot tell them apart. A customer record changes at 14:07, an email leaves at 14:08 and a price changes at 14:09. The log says one employee did all three. You now need to reconstruct the event from several systems and hope their timestamps line up.
A shared identity also gives the agent every permission the employee has. The person may need broad access because their role involves judgement and exceptions. The automated task may need to read one queue and draft one response. Sharing the account quietly turns a narrow job into broad authority.
Stopping the agent becomes harder as well. Changing a password or terminating a session can interrupt the employee. Leaving the session active preserves the risk. A separate agent identity gives you a clean switch.
An agent account is more than another email address
The exact form depends on the system. It might be a service account, an OAuth application, an API client, a dedicated operating-system user or a bot identity provided by the software.
The label matters less than four properties:
- The identity belongs to one agent or one tightly defined workflow.
- Logs distinguish its actions from human activity.
- Its permissions can be set independently.
- Its access can be revoked without disrupting anybody else.
Avoid one shared “AI automation” account for every workflow. Separate identities reduce the area affected by a fault and make each log useful. A document classifier and a payment workflow should not share credentials because they happen to use the same model.
Give the identity a plain name that describes the job. Record its owner, purpose, systems, permissions and review date. Somebody should be able to find that record during an incident without hunting through an old project folder.
Permissions should follow the task
A separate account with administrator rights is still a bad setup. Start from no access and add the few actions the workflow needs.
Write down the task as verbs. Read new enquiries. Look up an existing customer. Draft a reply. Add a private note. Move an item to a review queue.
Then compare those verbs with the permissions being requested. If the token can delete records, export the full customer database or change user access, remove those rights unless the written task requires them. Convenience during setup is a poor reason to leave permanent authority behind.
Keep high-impact actions behind human approval. Payments, refunds, account changes, contract commitments and customer messages deserve separate consideration. The agent can prepare the action while a person decides whether it happens.
Read access needs the same discipline. An agent does not need every document because it might be useful one day. Give it the smallest relevant data set and expand only when a tested case requires more.
Keep credentials away from the agent where possible
The NCSC recommends restricting the credentials available to an agent and using credentials with the shortest practical lifetime. It also suggests a proxy for some uses, so a request can receive a credential without exposing the credential to the agent itself.
That pattern limits what a compromised or confused agent can do. The agent asks an approved service to perform a defined request. The service checks the destination and action, adds the secret and records the result. The raw credential never appears in the conversation or tool output.
At a smaller scale, the same principle still applies. Keep tokens in a secret store rather than prompts, documents or shared spreadsheets. Scope each token to one service. Rotate it. Set an expiry where the platform allows one. Never give the agent access to a folder full of unrelated credentials.
Logs need to answer practical questions
A useful agent log tells you which identity acted, when it acted, which system and record it touched, what type of action it attempted, whether a person approved it and what the system returned.
Protect those logs from alteration and deletion. The NCSC notes that agent transcripts, access logs, proxy records and network traffic can all support oversight and an investigation. It also warns that logs may contain sensitive data, so access to the evidence needs controls of its own.
Start autonomous runs during office hours. Watch the first real cases while the people who understand the workflow are available. Overnight and weekend operation can follow when the permissions, alerts and stop process have survived real use.
Test the stop control before launch
Every agent with permission to act needs an immediate stop route. Stopping the visible agent process may leave scheduled jobs, active sessions or connected services running.
Test the full route. Disable the agent identity, revoke its token and confirm that another action fails. Check whether queued actions remain. Record who can perform the stop and how the business handles the work while the agent is off.
The NCSC advises organisations to retain the ability to halt autonomous activity and rapidly restrict network access or communication with the model. A written emergency procedure is useful. A procedure somebody has tested is far better.
Run a 15-minute identity check
List every AI tool that can read or change a business system. For each one, answer these questions:
- Does it have its own identity?
- Can the logs separate its actions from a person’s actions?
- Are its permissions limited to the written task?
- Can it reach credentials that belong to the person or machine running it?
- Who reviews its access and when?
- Can you revoke it now without interrupting a member of staff?
- Have you tested that revocation?
Any unclear answer is a job to fix before the agent gets more access.
This is also a useful test when buying an AI product. Ask the supplier how identities work, which permissions it requests, how long tokens live, what the logs show and how you disconnect it. Vague answers here will become your problem after launch.
When I design AI automation for an existing business workflow, identity and permissions come before autonomy. The commercial reason is straightforward. A separate, limited account reduces incident recovery time, makes customer actions defensible and lets the business stop one workflow without taking staff offline.
Give every agent its own account. Limit that account to the job, keep its credentials separate, protect the logs and test the stop control. Do those four things before giving it permission to act.