AI Agent Identities Need Joiner, Mover and Leaver Controls

Agentic Business Design

30 September 2026 | By Ashley Marshall

Your next privileged insider may not be a person. If an AI agent can read customer records, send messages or change systems, its identity needs an owner, an expiry date and a clean exit route.

An agent account is an operational role, not a technical detail

Businesses are beginning to give AI agents access to inboxes, customer records, document stores, finance systems and internal tools. That changes the nature of the deployment. A chatbot that only drafts text is a productivity tool. An agent that can retrieve confidential information, call an API or approve a workflow is an operational actor. Its identity determines what it can see, what it can change and how investigators can attribute an action after the event.

The practical mistake is to treat that identity as plumbing. Teams often reuse a developer account, a shared service principal or a long-lived API token because it gets a pilot moving quickly. The pilot then becomes production, the original owner changes jobs and nobody can say whether the credential is still needed. Human employees normally have a joiner, mover and leaver process. Their access is created for a role, changed when responsibilities move and removed when employment ends. Production agents need the same discipline, adapted for non-human work.

The UK National Cyber Security Centre makes the risk concrete in its August 2026 advice on managing the cyber risk of agentic AI. It asks organisations to consider everything an agent can access or influence, including credentials, networks, compute and data. It also warns that model safeguards are not a complete control. That means the business cannot delegate identity design to the model vendor.

What this means in practice is simple: no production agent should exist without a unique identity, a documented purpose and a named business sponsor. The identity is the control point that lets you restrict access, trace activity and stop the agent without disrupting unrelated systems.

The joiner process should start before the first credential is issued

A strong agent joiner process begins with purpose, not permissions. Write down the business outcome, the systems the agent needs, the data classification it will encounter, the actions it may take and the decisions that still require human approval. If those points are vague, access design will also be vague. Broad access is usually a symptom of an undefined role.

Next, assign two named responsibilities. The business sponsor is accountable for why the agent exists and whether it still delivers value. The technical owner is responsible for configuration, monitoring and recovery. Microsoft uses a similar distinction in its updated Entra Agent ID best practices, which recommends a sponsor and owner at creation time, descriptive metadata and a unique identity for each agent instance. The important point is not the Microsoft product. It is the operating pattern, which can be implemented with other identity platforms, cloud roles or an internal agent registry.

Credentials should then match the operating model. An autonomous service usually needs workload identity or a tightly scoped service credential. An assistant acting for a person should use delegated access so the person's existing policy and consent boundaries still apply. Production agents should not inherit a developer's full account, share one credential across several workflows or store secrets inside prompts. Prefer managed identities, short-lived tokens or certificates held in a secrets manager.

Finally, set the review and expiry conditions at creation. Record the launch date, owner, approved environments, allowed tools, maximum autonomy, credential rotation rule and next access review. Microsoft recommends periodic attestations every 6 to 12 months and at least annual certificate rotation. Higher-risk agents should be reviewed more often. An identity without a future review date is already becoming an orphan.

Mover controls matter because agents change faster than job descriptions

Agent permissions rarely remain static. A customer service assistant may begin by drafting replies, then gain permission to send messages, issue refunds or update a CRM. A finance agent may move from extracting invoice data to creating supplier records. Each change can create business value, but each also changes the possible impact of an error, compromised instruction or malicious input.

The mover process should therefore be triggered by changes to tools, models, prompts, data sources, workflow scope, environment or autonomy. Do not wait for an annual review if the agent gains a new connector today. Require a short change record that states what is changing, which permissions are new, what evidence supports the change and how the previous state can be restored. Then rerun the tests that matter for the expanded role.

The September 2026 ISACA recommendations for securing AI agents call for per-agent and per-workload identities, short-lived credentials, least privilege and reassessment when models, prompts, tools, permissions or memory behaviour change. That is a useful minimum standard because it connects identity governance to the release process rather than treating access as a one-off approval.

What this means in practice is that the permission increase should not be hidden inside a routine model update. If an agent moves from read-only retrieval to write access, that is a role change. It needs an owner approval, test evidence, updated monitoring and a rollback plan. Use separate identities for development, testing and production so an experimental agent cannot quietly inherit live access. Where possible, apply policies to a reusable blueprint, but keep individual identities for each running agent so logs remain attributable and one instance can be disabled without stopping the whole service.

Leaver controls need to remove the whole access path

Turning off an agent interface is not the same as removing its access. The underlying service principal may still exist. Refresh tokens may remain valid. Scheduled jobs may continue to run. Secrets may be copied into a deployment environment, connector or automation platform. A complete leaver process must remove the whole access path, not just the visible application.

Define clear triggers for retirement. These include the workflow being replaced, the business owner leaving, the supplier contract ending, the benefit falling below an agreed threshold, the agent failing a review or an incident making continued operation unsafe. Give every trigger an accountable decision maker. If ownership changes, either transfer sponsorship explicitly or suspend the agent until a new sponsor accepts responsibility.

The technical runbook should disable the agent identity, revoke sessions and tokens, remove tool permissions, rotate any shared secret the agent could access, stop scheduled executions and preserve required audit evidence. It should also deal with data. Decide what happens to prompts, memory, logs, retrieved documents and generated artefacts under your retention policy and UK data protection obligations. Deleting the application while leaving a persistent memory store untouched is not complete retirement.

Build and test a kill switch before production. The NCSC describes four levels for network restriction, from unrestricted access at level 1 to no external network access at level 4, and recommends the ability to stop consequential activity. Identity suspension is one part of that control, but network, tool and orchestration controls may also be needed. Run a retirement drill on a non-production agent and record how long it takes to stop actions, revoke access and confirm there is no residual execution. If the team cannot prove that an agent has left, it has not left.

A lightweight register can work before you buy a specialist platform

There is a growing market for agent identity, security and governance tools, but most UK organisations do not need to begin with a large platform purchase. Start with an inventory that joins business ownership to technical access. A controlled spreadsheet, service catalogue or configuration repository can be enough for the first deployment if it has clear ownership and is kept current.

For each agent, record a unique name, business purpose, sponsor, technical owner, environment, model provider, data classification, connected systems, permitted actions, credential type, approval gates, monitoring location, review date and retirement procedure. Add a link to the test evidence and incident runbook. The register should distinguish an agent from the blueprint or application used to create it. Ten agent instances built from one template still need ten attributable identities if they operate independently.

Microsoft's August 2026 Entra Agent ID for Dataverse announcement provides a named product example of this direction. It focuses on attributing data access and changes to an agent identity, assigning administrative ownership and managing the agent as it is created, updated or retired. Businesses using AWS, Google Cloud, Okta or a custom stack should demand the same capabilities even if the implementation differs.

Automate only after the lifecycle is clear. Useful early automations include rejecting deployments without a sponsor, alerting before credentials expire, flagging identities with no recent activity, scheduling access attestations and disabling agents when a blueprint is withdrawn. Keep an exception route for urgent work, but require an expiry time and retrospective review. The aim is not to create a paperwork obstacle. It is to make safe deployment faster because the access pattern, evidence and retirement path are already defined.

The counterargument: human processes will slow autonomous work

The obvious objection is that joiner, mover and leaver controls were designed for employees and will make agents too slow to deploy. There is some truth in that concern. Copying a manual HR process line by line would create friction, especially when development teams create and retire agent instances frequently. The answer is not to abandon lifecycle control. It is to express the control as reusable policy and automation.

Define approved agent blueprints for common patterns such as read-only knowledge retrieval, internal drafting, customer communication and controlled transaction processing. Each blueprint can carry default permissions, data boundaries, monitoring requirements and approval gates. Low-risk instances can then be provisioned quickly within the template, while higher-risk changes trigger additional review. This is closer to infrastructure as code than an employee onboarding form.

Also separate creation speed from production authority. Teams should be free to experiment in isolated development environments with synthetic or non-sensitive data. The stronger gate belongs where an identity receives live data, external communication rights, financial authority or production write access. The NCSC's guidance is explicitly proportionate: greater autonomy and potential impact require stronger controls. That supports tiered governance rather than a blanket ban.

For a practical first month, inventory every active agent, name a sponsor, replace shared accounts, define four risk tiers and choose one retirement drill. Then set a policy that no new production agent receives credentials without a registry entry and expiry or review date. Measure how many identities lack owners, how many hold unused permissions, how long revocation takes and how often role changes bypass review. Those measures reveal whether the control works. The goal is not to make an agent look like an employee. It is to ensure machine speed does not outrun accountability.

Frequently Asked Questions

Does every AI agent need a separate identity?

Every independently operating production agent should have an attributable identity. Separate identities improve traceability and allow one agent to be disabled or reconfigured without affecting unrelated workflows.

Can an AI agent use an employee's account?

Avoid giving an autonomous agent a person's full account. If it acts for a user, use delegated access with the user's existing policy boundaries. Otherwise use a dedicated workload identity with narrowly scoped permissions.

How often should agent access be reviewed?

Review on every material role change and on a fixed schedule. Six to 12 months may suit lower-risk agents, but agents with financial, customer or production write access should be reviewed more frequently.

Who should own an AI agent identity?

Assign both a business sponsor who owns the purpose and outcome, and a technical owner who manages configuration, monitoring, credentials and recovery.

What should happen when an agent owner leaves?

Transfer sponsorship explicitly or suspend the agent until a new owner accepts responsibility. Review its permissions, credentials, scheduled tasks and data retention as part of the transfer.

Is disabling the agent application enough to retire it?

No. Revoke tokens, disable the identity, remove tool permissions, stop schedules, rotate exposed shared secrets and confirm that no residual process can still act.

Do small businesses need specialist identity software for agents?

Not necessarily. A well-maintained register, separate credentials, named owners, access reviews and a tested shutdown process can establish the lifecycle before a specialist platform is justified.

How does UK data protection law affect agent identity controls?

Identity and access controls support accountability, security and data minimisation under UK GDPR. They help show which system accessed personal data, for what purpose and under whose authority.