AI Agent Identity And Permission Lifecycle Management For UK SMEs

Agentic Business Design

1 June 2026 | By Ashley Marshall

AI agents are becoming operational workers, not just software features. UK SMEs need to give every agent an owner, an expiry date, scoped permissions and a review cycle before it touches CRM, finance, HR or support systems.

Treat Every Agent As A Business Identity

The first mistake is to describe an AI agent as a feature. A feature sits inside a product. An agent can decide which tool to call, retrieve information, update a record, send a message, raise a ticket, create a quote or trigger a workflow. Once it can act across CRM, finance, HR or support, it is no longer just an interface. It has authority inside the business, so it needs identity governance.

The UK guidance already points in this direction. The NCSC introduction to identity and access management defines IAM as the policies, processes and systems that bind a person, or in some cases a system, to permissions. It also stresses least privilege, revocation and monitoring. AI agents fit the system side of that definition, but they behave differently from traditional service accounts because their actions are shaped by goals, context and tool access rather than fixed application logic.

This matters for SMEs because the early agent use cases tend to sit exactly where sensitive systems meet messy judgement. Sales teams want agents that update HubSpot, Salesforce or Pipedrive. Finance teams want agents that reconcile invoices in Xero, QuickBooks or Sage. HR teams want help with onboarding, absence notes and policy questions. Support teams want agents inside Zendesk, Intercom, Freshdesk or Microsoft Dynamics. These are good workflows, but they contain customer data, payroll data, commercial terms, health notes, complaints and payment information.

What this means in practice: do not let an agent borrow a founder's login, share an admin API key or run through an integration account nobody owns. Create a named agent record before deployment. Record its purpose, system connections, data categories, permitted actions, business owner, technical owner, creation date, expiry date and review date. If that sounds like too much process, compare it with offboarding an employee who had no HR record, no manager and unknown access. The risk is the same shape, but faster.

Ownership Is The Control That Makes Everything Else Work

Every agent needs a named owner because permissions are business decisions, not just technical settings. The owner is the person who can explain why the agent exists, which outcomes it is allowed to pursue and when it should be switched off. Without that owner, access reviews become theatre. The security team can see an integration, the operations team can see a workflow and the supplier can see an API token, but nobody can confirm whether the agent is still needed.

The latest identity data shows why this cannot be left informal. Veza's 2026 State of Identity and Access research, reported by Business Wire, found that dormant accounts represent 38 percent of all accounts, the average identity holds 96,000 entitlements and 824,000 orphaned accounts in the dataset had no human owner in HR systems while retaining live entitlements. That is enterprise scale data, but the lesson transfers directly to SMEs: orphaned access is not a large-company problem. It is what happens whenever systems grow faster than ownership records.

An SME should assign two roles to every agent. The business owner is accountable for the process and risk. The technical owner is accountable for configuration, credentials, logs and incident response. In a 40-person company, those roles may be held by the same person, but they still need to be written down. For a sales quote agent, the commercial director may own purpose and approval limits while the CRM administrator owns OAuth scopes and audit logs. For a support triage agent, the head of customer success may own escalation rules while the IT lead owns Zendesk or Microsoft Graph permissions.

What this means in practice: an agent request should not start with "connect it to the CRM". It should start with "who owns the outcome and who owns the access?" If either answer is missing, the agent stays in a sandbox. Ownership also gives staff somewhere to escalate when the agent makes a poor decision, leaks context between customers, writes a wrong note or starts using a tool in a way nobody expected. The owner is not there to slow adoption. The owner is there to make adoption reversible.

Expiry Dates Stop Useful Experiments Becoming Permanent Risk

SMEs often deploy agents experimentally. That is sensible. The dangerous part is when the experiment becomes permanent by accident. A trial support agent gets access to the helpdesk for a two-week pilot. A finance reconciliation agent is connected before month end. A marketing agent is given CRM export access for one campaign. Three months later, the original problem has changed, the person who approved the access has moved on and the token is still live.

The DSIT AI Cyber Security Code of Practice is explicit that AI security should cover the lifecycle of the system, including secure design, deployment, maintenance and end of life. It also says AI systems that interact with other systems or data sources should only receive permissions required for functionality and should be risk assessed. An expiry date turns that lifecycle principle into something an SME can actually operate.

Expiry does not mean every agent must die every month. It means access is time-bound by default. A low-risk research agent that reads public web pages may have a twelve-month review. An agent that reads CRM notes may have a ninety-day expiry. An agent that can create refunds, amend payroll data or send customer emails should have a much shorter approval period, step-up approval for sensitive actions and automatic disablement if the review is missed. The principle is simple: the more sensitive the system and the more autonomous the action, the shorter the access window.

There is a common objection here: "we do not put expiry dates on ordinary software integrations." That is partly true, but agents are not ordinary integrations. A fixed integration usually performs a narrow transaction. An agent can combine retrieved context, instructions, tool calls and user prompts into new action paths. Even when the agent is reliable, the surrounding business process changes. New CRM fields appear. New HR policies are added. Finance approval rules change. Suppliers change API scopes. An expiry date forces the company to ask whether the access still matches the reality of the workflow.

Scoped Permissions Beat Borrowed Human Access

The most convenient way to launch an agent is often the worst way to govern it: let it act as a human user or give it a broad service account. That may work during a demo, but it breaks auditability. If a support agent updates a complaint note under "[email protected]", did Ashley do it, did the agent do it, or did a prompt from a third-party email cause the agent to do it? When the same identity covers human action and autonomous action, incident response becomes guesswork.

Recent CSA data reported by ITPro found that 68 percent of organisations cannot accurately distinguish AI agent activity from human activity. The same report said 31 percent allow agents to operate under human user identities, 74 percent say agents often receive more access than necessary and 79 percent believe agents create new access pathways that are difficult to monitor. Those figures describe exactly the problem SMEs should avoid before it becomes embedded.

The better pattern is a distinct agent identity with scoped permissions. In Microsoft Entra ID, that may mean an application registration with restricted Microsoft Graph permissions and conditional access controls. In Google Workspace, it may mean a service account or OAuth client with only the required scopes. In Salesforce, HubSpot, Xero, Sage, Zendesk or Intercom, it means choosing the narrowest API scopes, limiting which objects can be read or written and separating read-only research from write-capable execution. For higher-risk workflows, use approval queues rather than direct write access.

What this means in practice: create separate agents for separate jobs. Do not give one general "office agent" access to CRM, invoices, HR records and support tickets. A CRM enrichment agent should not be able to issue refunds. A finance reconciliation agent should not be able to export the full customer database. A support summarisation agent should not be able to edit payroll notes. Scoped permissions make the failure smaller, the logs cleaner and the business case easier to defend. They also help staff trust agents because the system boundaries are visible rather than implied.

Access Reviews Need Evidence, Not A Spreadsheet Ritual

Many SMEs hear "access review" and picture a quarterly spreadsheet that nobody wants to read. That is the wrong model for AI agents. The review should be a short evidence-based decision: keep, reduce, suspend or retire. The owner should be able to see which systems the agent accessed, what actions it took, which permissions were unused, where it hit policy blocks and whether any staff overrode its recommendations. If that evidence is missing, the review should fail.

The UK Government's April 2026 CYBERUK announcement said nationally significant incidents handled by the NCSC more than doubled in 2025 and announced a further GBP 90 million to strengthen cyber resilience, including for small and medium sized businesses. The same announcement pushed three practical actions: board-level responsibility, NCSC Early Warning and Cyber Essentials across supply chains. Agent access reviews sit neatly inside that wider direction. They turn cyber resilience from a policy statement into routine operational control.

An effective review asks six questions. Does the agent still have a valid business owner? Is the purpose still current? Are any permissions unused or broader than needed? Did the agent touch restricted data, such as payroll, health, complaints, special category data or payment details? Were any actions blocked, reversed or escalated? Has the underlying supplier, model, connector or business process changed since approval? These questions are simple enough for an SME operations meeting, but strong enough to catch most permission drift.

For agents touching personal data, the review should also connect to UK GDPR accountability. The ICO said in May 2026 that its 2026/27 work will include an AI code of practice, dedicated guidance on agentic AI and consumer support for an increasingly personalised AI landscape, as set out in its response on safe AI-powered innovation. SMEs do not need to wait for more guidance to act. If an agent processes personal data, record purpose, lawful basis, data minimisation, retention and human oversight now. That evidence will be useful whether the question comes from a customer, a regulator, an insurer or a board member.

The Counterargument: Will This Slow AI Adoption?

The strongest counterargument is practical: SMEs do not have the security teams, IAM platforms or governance committees that larger enterprises have. If every agent needs an owner, expiry date, scoped permissions and review, will the business lose the speed that made agents attractive in the first place? It is a fair concern. A five-person leadership team cannot operate enterprise bureaucracy, and a small operations team should not need a three-month approval cycle to automate ticket triage.

The answer is proportional governance. Low-risk agents should move quickly. A research assistant that reads public web pages, drafts internal notes and cannot access business systems can be approved with a light record. A customer support agent that reads historic tickets needs a stronger record. An agent that can write to CRM, send customer emails, alter invoices, create refunds, amend HR data or trigger payments needs proper ownership, short-lived credentials, action logs and review. The control should match the blast radius.

Vendors are moving in this direction because the problem is becoming visible. TechRadar reported that Okta planned an AI agent IAM platform for discovering, registering and managing agents, including shadow agents, and cited Okta figures that 88 percent of organisations had reported AI agent security incidents while only 22 percent treated agents as identity-bearing entities. The product names will change, but the pattern is clear: discovery, registration, scoped access, central disablement and audit trails are becoming normal parts of agent operations.

For UK SMEs, the immediate move is not to buy a heavy governance platform on day one. Start with a simple agent register, a permission checklist and a review calendar. Use the identity controls already inside Microsoft Entra ID, Google Workspace, your CRM, your finance platform and your helpdesk. Separate read from write. Put high-risk actions behind human approval. Set expiry dates on API tokens where the platform allows it. Review agents before renewal, not after an incident. That is not a drag on adoption. It is how the business keeps the right to use agents in sensitive workflows without creating a pile of invisible access debt.

Frequently Asked Questions

Does every AI agent really need its own identity?

Every agent that can access business systems or data should have a distinct identity or clearly attributable workload identity. Agents that only draft text locally may not need full IAM treatment, but once they read or write CRM, finance, HR or support data, separate identity is the cleaner and safer approach.

Can an SME manage this without an enterprise IAM platform?

Yes. Start with a simple agent register, named owners, scoped API credentials, expiry dates and a quarterly review. Use the controls already available in Microsoft Entra ID, Google Workspace, your CRM, helpdesk and finance software before buying specialist tooling.

What should go in an AI agent register?

Record the agent name, business purpose, connected systems, data categories, permitted actions, business owner, technical owner, creation date, expiry date, review date, credential location, logging location and approval status.

How often should AI agent access be reviewed?

Review frequency should match risk. Low-risk read-only agents may be reviewed every six to twelve months. Agents with customer data, HR data, finance access, write permissions or external communications should be reviewed every thirty to ninety days.

Should agents ever use a human employee's account?

Only as a temporary exception in a tightly controlled pilot, and even then it should be logged and replaced quickly. Borrowed human access makes audit trails unclear, complicates incident response and can leave permissions live after the pilot ends.

What is the biggest permission mistake with AI agents?

The biggest mistake is giving a general-purpose agent broad access because nobody has mapped the workflow properly. Separate jobs into separate agents, keep read and write permissions apart and put sensitive actions behind human approval.

How does this relate to UK GDPR?

If an agent processes personal data, the organisation still needs purpose limitation, data minimisation, access control, retention, transparency and accountability. Agent logs, ownership records and review evidence help demonstrate those controls.

What should happen when an agent's owner leaves the business?

The agent should be suspended or reassigned before the owner's account is closed. Owner departure should trigger an access review, just like a joiners, movers and leavers process for staff.