Field note
Agentic AI security checklist for SMEs
An agent that can take action needs a smaller permission set, shorter-lived credentials, visible logs and a tested way to stop it.
An AI assistant produces an answer. An AI agent may read a mailbox, call a tool, update a record or trigger another workflow. That difference turns a quality problem into a security and operations problem.
The National Cyber Security Centre's May 2026 guidance recommends careful, incremental adoption: start with tightly bounded, low-risk tasks and apply established security controls from the outset. For an SME, that means treating the agent like a new service account with an unusually flexible decision layer.
Decide whether the task needs an agent
Do not use autonomy to avoid fixing a bad process. First ask whether a normal rule, form, scheduled script or approval workflow can do the job with less uncertainty.
A suitable first agent task is repetitive, easy to verify and cheap to reverse. Examples include preparing a draft status report from a named folder or classifying support tickets without sending replies.
A poor first task changes supplier bank details, deletes records, grants access, deploys code or communicates externally without review. The issue is not that these actions can never be automated. It is that a first pilot has not earned the evidence needed for that authority.
Build an agent access matrix
List every system the agent can reach. For each one, record:
- the exact data it can read;
- the exact actions it can take;
- the credential or delegated identity it uses;
- the maximum duration of that access;
- the human approval point;
- the logs available; and
- the person who can revoke access.
“SharePoint access” is too broad. “Read access to the current support-policy library; no access to HR, finance or personal drives” is testable.
Apply least privilege twice: limit both the data and the actions. An agent that only needs to draft a customer reply does not need permission to send email. An agent checking invoices does not need permission to edit supplier records.
Avoid long-lived power
The NCSC recommends temporary credentials where possible and revoking elevated access when a task is complete. This reduces the value of a compromised token and limits the damage from a misunderstood instruction.
Do not place shared admin passwords or permanent API keys in prompts, documents or agent memory. Use a dedicated identity, narrow scopes, expiring credentials and a separate approval for elevated actions. Test expiry: the agent should fail safely, tell the operator what happened and avoid retrying forever.
Assume connected content can be hostile
Agents inherit known language-model risks, including prompt injection. A supplier email, web page, support ticket or document may contain text that tries to redirect the agent or extract data.
Separate instructions from evidence. Treat external content as untrusted input. Do not allow a document to expand permissions, select a new tool or override the system's approval rule. For high-impact actions, validate structured fields against normal business rules rather than trusting the agent's interpretation of prose.
Monitor actions, not only chats
A conversation log is not a complete audit trail. Record tool calls, target systems, changed records, approvals, errors and credential use. Alert on behaviour such as:
- access outside the expected folder or business hours;
- repeated failed actions;
- unusually large reads or exports;
- a new destination or recipient;
- attempts to use a blocked tool; and
- a sudden rise in volume after a prompt or model change.
Give one person operational ownership and another person authority to review risk. The owner should know how to pause the agent, revoke its identity and identify records changed during an incident.
Write the failure playbook before launch
The NCSC's test is blunt and useful: if you cannot understand, monitor or contain an agent's actions, it is not ready for deployment.
A short failure playbook should cover:
- how to stop new actions;
- how to revoke credentials;
- how to preserve logs;
- how to identify and reverse changes;
- who decides whether customers or regulators need to be informed; and
- what evidence is required before restart.
Run one exercise during the pilot. Simulate a malicious document or an agent sending an action to the wrong test record. A kill switch that nobody has used is only a diagram.
Expand one permission at a time
Keep the first pilot read-only or draft-only. Add one action only after the team has measured accuracy, reviewed failures and confirmed the logs. Do not widen data access and action authority in the same release; if something breaks, you will not know which change caused it.
An AI governance review can turn the access matrix, owner list, evidence and stop conditions into a control set the business can maintain.