Most enterprise AI programmes have a deployment problem disguised as a deployment success. Teams build an agent, validate it, get it into production, and declare the work done. The launch is real. The value is often real too. But the moment the agent goes live, a second set of problems begins that nobody planned for.

Who owns this agent now that it is running? What happens when the person who built it leaves the organisation? When should the agent's access be reviewed, or reduced, or revoked entirely? What is the process for retiring it when the business problem it was built to solve no longer exists? And how does anyone know if it has quietly accumulated permissions it was never supposed to have?

These are not theoretical concerns. They are the operational reality of running AI agents at enterprise scale, and for the vast majority of organisations they remain largely unresolved. IBM's 2026 Tech Leader Study found that 77% of organisations say AI adoption is already outpacing their current governance capabilities. A separate survey found that only 21% of enterprises have a mature governance model in place to manage agentic AI risks. Deployment is accelerating. Lifecycle management is not keeping pace.

Every AI agent has a birth, a life, and a retirement. Without disciplined lifecycle management, organisations are building infrastructure they cannot control, cannot audit, and cannot safely decommission.

Why Agents Are Different from Every Other Enterprise System

Enterprise IT has governed software, devices, and user identities for decades. The frameworks are mature: joiners, movers, and leavers for human identities; change management and patching cycles for applications; asset registers for devices. Most organisations have invested heavily in these processes. The instinct is to extend them to AI agents.

That instinct is partly right but structurally incomplete, because agents differ from traditional systems in three fundamental ways.

First, they are autonomous. Unlike a piece of software that responds only when a user initiates an action, an agent can take actions, make decisions, and interact with other systems independently. A poorly scoped agent does not wait to be told it has overstepped its boundaries. It acts within whatever permissions it holds until someone notices.

Second, they proliferate far faster than any previous enterprise technology. A single employee with access to Copilot Studio or a similar low-code agent builder can create multiple agents in an afternoon. There is no natural governance checkpoint at the point of creation in most environments. Agents appear far more quickly than any formal IT process was designed to track.

Third, they blur the line between identity and tool in ways that existing governance frameworks were not built to handle. An agent can hold credentials, access sensitive data, trigger financial transactions, and act on behalf of users across multiple systems simultaneously. It functions as a non-human identity with real organisational permissions. But it has no employment contract, no performance review, and no natural end date unless one is deliberately imposed.

These three differences combine to create a governance gap that widens with every new agent deployed. Understanding the specific components of that gap is the first step to closing it.

The Four Lifecycle Problems

1. The Onboarding Gap

The agent equivalent of onboarding is the moment at which an agent is registered, scoped, and given a defined identity in the enterprise environment. In well-governed organisations, this process is deliberate: every agent receives a unique identifier, a defined purpose, a named owner, and precisely scoped permissions tied to that purpose.

In most organisations, this is not what happens. Agents are deployed through development pipelines, Copilot Studio environments, or direct API integrations with minimal formal registration. They receive whatever permissions are needed to function at the moment of deployment, which is almost always broader than the minimum required. Research consistently shows that permissions are granted generously at creation and rarely revisited afterwards.

The security consequence is immediate. An agent built to retrieve documents for a specific workflow ends up with read access to a far wider set of SharePoint directories than its task requires. A customer service agent provisioned with write access to a CRM for logging purposes has standing access to modify records it should only ever be reading. These are not malicious outcomes. They are the natural result of onboarding that optimises for speed over precision.

Effective onboarding requires treating every agent as a first-class identity from its first moment of existence: a unique registration, a minimum-privilege access grant tied to a named use case, a defined owner with accountability for that agent's behaviour, and a policy baseline that travels with the agent from creation.

2. The Ownership Gap

Ownership is the most overlooked element of agent governance, and the one that creates the most persistent risk over time. In most deployments, the person who builds an agent is also its de facto owner by default. When that person changes roles, moves teams, or leaves the organisation, ownership does not automatically transfer. The agent continues running. The access it holds remains active. The business logic it encodes may reflect assumptions that are now months or years out of date.

This is what security researchers call the orphan agent problem. Autonomous AI agents with persistent access and no active owner are security landmines. Nobody is reviewing their behaviour. Nobody is assessing whether their permissions are still appropriate. Nobody will notice if their outputs have drifted or if their credentials have been quietly compromised.

Gartner predicts that 40% of enterprise applications will incorporate task-specific AI agents by end of 2026. If each of those agents has even a modest probability of becoming ownerless within its operational lifetime, the cumulative risk across a large enterprise deployment is significant.

Resolving the ownership gap requires three things: a formal ownership model that treats agent ownership as an organisational accountability rather than a default assumption, automated processes that trigger ownership reviews when the registered owner changes role or leaves, and escalation paths that ensure ownerless agents are either assigned or decommissioned rather than left running indefinitely.

3. The Permission Creep Gap

Agents accumulate permissions over time. This is not usually deliberate. It is the cumulative result of operational pressures: the agent needs access to a new data source to complete a task, a developer grants the additional permission to unblock the workflow, and nobody formally reviews whether the original permissions should be reduced as a result.

The pattern is called permission creep or access creep, and it is one of the most documented problems in AI agent security. Research published in 2026 found that 70% of enterprises report their AI systems already have more access than equivalent human roles performing the same work. This is not because anyone made a deliberate decision to over-privilege AI agents. It is because permission grants are easy and permission reviews are rare.

The risk compounds in multi-agent architectures, where agents can interact with and delegate to other agents. A vulnerability in one agent with overly broad permissions can have consequences that cascade across the entire agent network. The principle of least privilege, a foundational security concept applied rigorously to human identities, has not yet been systematically extended to non-human identities in most enterprise environments.

Closing this gap requires scheduled access certifications that apply the same rigour to agent permissions as to human user permissions, automated policy enforcement that prevents agents from acquiring access outside their defined scope, and runtime monitoring that flags unusual access patterns before they become security incidents.

4. The Expiry Gap

Unlike a human employee, an AI agent has no natural end date. Unlike a software licence, it does not expire unless someone sets an expiry date. Unlike a contractor engagement, it does not conclude when the project it was built for concludes. Agents can run indefinitely, long after the workflow they were designed to support has changed, the team they were built for has been restructured, or the data source they connect to has been deprecated.

This creates a class of agents that are technically active but operationally stale. They hold access to systems they no longer need. They may be connected to data sources whose governance requirements have changed. They are consuming compute and licensing resource without generating corresponding value. And because nobody is reviewing them, their existence in the organisation's security perimeter is effectively invisible.

Effective lifecycle governance requires deliberate expiry policies: default time limits that require agents to be actively recertified to continue operating, automated decommissioning workflows that trigger when an agent has been inactive beyond a defined threshold, and retirement processes that ensure all credentials, access tokens, and system integrations are cleanly revoked rather than simply abandoned.

What Good Agent Lifecycle Management Looks Like

Agent lifecycle management (ALM) is the end-to-end practice of governing an AI agent from the moment it is created to the moment it is decommissioned. It borrows from familiar enterprise frameworks, software development lifecycle practices, identity governance, and operational monitoring, while extending them to address the specific properties of autonomous agents.

The most mature implementations of ALM share several common characteristics.

• A centralised agent registry that provides a complete, current inventory of every agent in the enterprise environment, including who owns it, what it is authorised to access, when it was last reviewed, and what its current status is.

• Identity-first provisioning that assigns every agent a unique, verifiable identifier from the point of creation, with permissions granted through the same access control frameworks used for human identities, never through shared service accounts or hardcoded credentials.

• Automated lifecycle policy enforcement, including default access expiry, inactivity-triggered review workflows, and ownership transfer processes that activate automatically when the registered owner leaves or changes role.

• Continuous monitoring and anomaly detection that tracks agent behaviour at the execution level, flagging unexpected access patterns, unusual tool invocations, or privilege escalation attempts in real time rather than retroactively.

• Formal decommissioning processes that ensure retired agents have all credentials revoked, all system integrations cleanly disconnected, and all data access properly audited before the agent is removed from the registry.

The joiner-mover-leaver model that most enterprise identity teams already apply to human employees translates directly to agents. Every agent should enter a formal onboarding workflow, undergo access recertification when its scope or capabilities change, and follow a structured offboarding process when it is retired. The framework is not new. Applying it to non-human identities is.

The Connection to Agent 365 and Enterprise Tooling

Microsoft's Agent 365 platform, which reached general availability in May 2026, is designed to address several of these lifecycle problems within the Microsoft ecosystem. Its Observe pillar provides a centralised Agent Registry with relationship mapping and risk signals. Its Govern pillar delivers lifecycle policy enforcement through Entra Agent ID, automated expiry rules, and ownership management workflows. Its Secure pillar extends Defender and Purview to treat agents as first-class security identities with their own access controls and audit trails.

For organisations running Microsoft-centric environments, Agent 365 provides much of the infrastructure that mature ALM requires. But the platform is infrastructure, not a programme. The policies, ownership models, access review cadences, and decommissioning processes that make ALM effective are organisational decisions that require deliberate design before the tooling can enforce them.

The organisations that will derive the most value from Agent 365 are those that arrive with a clear ALM framework already defined: they know what their onboarding requirements are, they have an ownership model established, they have made decisions about default access expiry periods, and they have a retirement process that does not depend on individuals remembering to clean up after themselves. The platform enforces the framework. It does not replace the need to have one.

What Enterprises Should Do Now

The lifecycle problem compounds with every new agent deployed without a governance framework to manage it. The practical steps to address it are not complex, but they do require a deliberate decision to treat agent governance as a programme rather than a policy document.

• Build the registry before you need it. Start with a complete inventory of what is currently running, including agents that IT did not formally deploy. The gap between what teams believe is running and what is actually running is typically significant.

• Define the ownership model explicitly. Every agent needs a named owner with defined accountability, a clear handoff process for when that owner changes role, and an escalation path for agents that become ownerless.

• Set default expiry from day one. Agents that are not actively recertified should expire automatically. The default should be structured expiry, not indefinite operation.

• Apply the minimum-privilege principle consistently. Agents should receive only the access required for their defined purpose at the time of deployment. Access reviews should be scheduled and enforced, not left to individual initiative.

• Treat decommissioning as a formal process. Retiring an agent means revoking credentials, disconnecting integrations, and completing an audit, not simply switching it off. The residual access that orphaned or carelessly retired agents leave behind is a significant and preventable risk.

• Connect ALM to your existing identity governance programme. Agent lifecycle management is not a new discipline invented for AI. It is an extension of the identity governance practices that already exist in the organisation. The most effective implementations build on those frameworks rather than creating parallel processes.

The Governance Gap Is a Choice

The agent lifecycle problem is not caused by bad technology or bad intentions. It is caused by the natural tendency of deployment timelines to outrun governance design. Teams move fast to capture AI value. Governance catches up later, if it catches up at all.

The organisations that are ahead of this curve are not moving more slowly. They are moving more deliberately. They defined their ALM framework before they scaled their agent deployments, they built ownership models before they had orphan agent problems, and they set expiry policies before they had stale agent problems.

The gap between deploying AI agents and governing them is not a technology gap. It is a programme design gap. And unlike the technology, which continues to evolve rapidly, the governance framework is something every organisation can define and implement now, regardless of which platforms or models they use. The question is not whether to build the lifecycle framework. It is whether to build it before the risk accumulates or after.

Want to understand where your enterprise stands on agent lifecycle readiness, and what a governance framework should look like for your environment?

VE3 works with enterprise teams across the UK and beyond to design and implement agent governance frameworks, from registry and ownership models through to Microsoft Agent 365 deployment and ongoing ALM programme design. Get in touch to start the conversation.