Who is accountable when an AI agent keeps running after its creator leaves?

When the agent outlives its creator, who actually owns the risk?

The accountable owner is the organisation, because the agent is operating as an organisational capability even if a single employee created it. If offboarding is treated as a human HR event only, the organisation can lose control of active credentials, permissions and decision paths. That turns a personnel change into a governance gap with real operational and security consequences.

What matters is not who first configured the agent, but who can still change, stop, review and revoke it. An agent that continues to act after its creator leaves must have a remaining owner of record, a revocation path, and an inventory entry that survives personnel turnover.

The same rule applies whether the agent is a simple automation or a more autonomous AI agent. If its authority was borrowed from a personal account, the organisation has effectively delegated business action to an identity that may disappear without a clean handoff. That is why ownership, approval and offboarding must be tied to the agent lifecycle, not just the employee lifecycle.

Why personal-account linkage makes offboarding fail

When an agent is tied to a personal account, the control surface becomes fragile. The creator may leave, the account may be disabled, but any long-lived token, cached session, API key or delegated grant can remain active if revocation is not coupled to the agent itself. The result is an orphaned automation that can still reach systems the organisation expected to be shut down.

This is where lifecycle design matters more than intent. A creator may believe they “own” the agent informally, but business ownership requires explicit assignment, change approval and revocation authority. Without those, the organisation cannot prove when the agent was last reviewed, who accepted its risk, or whether its permissions still match current business need.

In practice, this is a governance and access-control problem at the same time. It is also why agent identity and authorisation need to be treated as durable enterprise objects, not side effects of a person’s login state. NHIMG’s Agentic AI Identity Guide covers the identity, delegation and retirement model that prevents this ownership gap.

What good ownership looks like in production

Good ownership means the organisation can answer four questions at any time: who is responsible, what can the agent do, how is it revoked, and what evidence shows it was reviewed. If any of those answers depend on a departing employee’s account, the control is too weak for production use.

Practitioners should expect the owner of record to be a business or technical function, not an individual developer. The agent should have an explicit service owner, a lifecycle state, a revocation procedure, and a review cadence that is independent of staff turnover. That is especially important for agents with tool access, external API reach, or any ability to change data, send messages, or trigger workflows.

A strong pattern is to separate creation from custody. The creator can propose the agent, but a team or platform owner must approve its standing access, monitor its use, and remove or rotate its credentials when the agent is retired or reassigned. If the organisation cannot do that, it has not implemented accountable ownership, only convenient delegation. NHIMG’s AI Agent Authorisation Guide is the most direct companion for deciding how much action an agent should be allowed to take.

Risk and Threat Considerations

An agent that keeps running after its creator leaves can become an orphaned privilege path. The risk is not just continuity, it is unauthorised continuity: stale credentials, unreviewed permissions, and a missing human owner can let the agent keep acting long after the organisation has lost situational awareness. That creates exposure even if no attacker is involved.

Failure mechanism: The employee lifecycle ends, but the agent lifecycle does not. If tokens, secrets, delegated grants or embedded credentials are not independently revoked, the agent continues to authenticate and act under authority that no longer has an accountable owner.

Impact: The organisation may face uncontrolled access, delayed detection of misuse, configuration drift, and difficulty proving who approved the remaining access. In a compromise scenario, the same orphaned access path can be abused for data exposure, destructive actions, or lateral movement. NHIMG’s AI Agent Observability, Audit and Incident Response Guide is useful here because revocation alone is not enough if you cannot attribute what the agent did before shutdown.

Practitioner Guidance

What to verify: Verify that every production agent has an owner of record, a retirement state, and a documented revocation path that does not depend on the creator’s personal account.

Decision rule: If the agent can still authenticate after the creator is removed, treat it as an orphaned enterprise identity and prioritise revocation, ownership reassignment and blast-radius review before anything else.

What good looks like: The organisation can disable the agent, rotate its credentials, and explain who approved its standing permissions without asking the departed employee’s manager.

Practitioner takeaway: The key judgement is to treat the agent as an organisational asset with its own lifecycle, because accountability only exists when ownership and revocation survive personnel changes.

Related resources from NHI Mgmt Group

• Who is accountable when a service account or AI agent keeps access after offboarding?
• Who should be accountable when a shadow AI agent keeps broad access after its original owner changes roles?
• Why is single-provider AI agent governance not enough for enterprise security?
• What should teams do when an AI agent keeps access after a project ends?