Who is accountable when an agent keeps acting after the authorising user is gone?

When the user is gone, what keeps the agent accountable?

Accountability does not disappear with the original user session. It shifts to the governing process that defined the delegation, the scope, and the stop condition. If an agent keeps acting after the authorising user is gone, the real failure is not just the lingering action, it is the absence of ownership for revocation, exception handling, and review of what the agent was still allowed to do.

The practical question is whether the delegation was designed as a bounded act or an open-ended standing permission. An agent that can continue without expiry, renewal, or explicit retirement is operating on a control gap, not on a clean handoff. That is why AI Agent Authorisation Guide is relevant here: it frames per-action authorization, task-scoped access, and human approval gates as the mechanism that keeps delegated authority attributable.

In governance terms, accountability should be assigned before the agent is allowed to act, not after it misbehaves. The owning team needs a clear answer to who approves scope changes, who can terminate the connection, and who is responsible for reviewing denied or unexpected actions when the original user context no longer exists. That aligns with IAM and IGA Basics, because this is fundamentally a lifecycle and entitlement question as much as it is an access question.

An agent that outlives the authorising user also raises a lifecycle problem: the delegation may have started as legitimate, but it becomes stale if nobody re-certifies it. A clean operating model needs provisioning, review, rotation, and offboarding steps for the delegated relationship itself, not just for the human account behind it. NHI Lifecycle Management Guide is useful because it treats offboarding and visibility as first-class controls, which is exactly what failed when the agent kept running.

What usually fails in delegated agent accountability

The common failure is assuming the person who first approved the agent remains responsible forever, even after context changes. In practice, the agent may still hold credentials, tokens, or a live trust path that no one is actively supervising. That is why ownership must be attached to the delegation record, the policy that granted it, and the team that can revoke it, not only to the departed user or the original business request.

Another weak point is over-broad authorization. If the agent has more standing access than the task needs, then persistence after the authorising user is gone becomes a larger problem because the blast radius is already too wide. Authorisation Models Guide supports the design choice here: policy-based and relationship-aware authorization should constrain what the agent may do at each step, rather than relying on a single approval event.

The same issue appears when the human and machine boundaries are blurred. If a team cannot tell whether the agent is acting under delegated authority, inherited access, or a reused credential, accountability becomes hard to assign and hard to audit. Human vs Non-Human Identity helps clarify that the governance model must separate user intent from machine execution, especially where shared access paths are involved.

Who should own the decision to stop, review, or escalate?

The owning team should own the delegation, but not every decision is theirs alone. Security or identity governance should own the policy shape, the application or platform team should own operational retirement of the agent connection, and the business owner should own whether the delegated function still has a valid purpose. The key is that no single person should be forced to infer responsibility after the fact.

For stronger control, the process should define three distinct decision points: who may approve the original delegation, who may change its scope, and who may retire it when the authorising user is no longer present. That separation avoids the common mistake of treating approval as equivalent to ongoing accountability. In practice, the review path should also capture denied actions, because those events often reveal that the agent is still trying to act outside its intended context.

Where agents are involved in broader autonomy or delegated workflows, the right control pattern is to keep authority bounded and observable. Agentic AI Identity Guide is relevant because it frames agent registration, delegated authority, and retirement as part of the lifecycle, which is the only reliable way to preserve accountability after the original user disappears.

Risk and Threat Considerations

When an agent keeps acting after the authorising user is gone, the main risk is stale delegated access with no live owner. That creates an easy path to overreach, accidental misuse, or abuse of a trust relationship that was never meant to be permanent. The longer the agent remains active, the more likely its authority outlives the business need that justified it.

Failure mechanism: Delegated access persists after the human context has expired, so the agent continues to execute under an obsolete approval state. If the access path is not tied to expiry, recertification, or automatic retirement, neither the platform nor the organisation has a reliable trigger to stop it.

Impact: Unattended delegated authority increases the chance of unauthorized actions, excessive privilege use, and poor auditability. It also weakens incident response because responders have to reconstruct who owned the delegation, who could revoke it, and whether the agent was still acting within its intended scope.

Practitioner Guidance

What to prioritise: Treat every delegated agent permission as time-bound and owner-bound. If you cannot name who revokes it after the authorising user leaves, the control is incomplete.

What to verify: Confirm that the delegation record includes an expiry condition, a named retiree or owning team, and a review path for unexpected or denied actions. The cleanest control is one that can be proved from logs and policy history, not just from tribal knowledge.

Common mistake: Teams often secure the initial approval but forget the termination path. That leaves a “valid” agent running long after the business intent has changed, which is exactly where accountability becomes ambiguous.

Practitioner takeaway: Accountability for a continuing agent belongs to the process that can still answer three questions, who owns it, who can stop it, and who reviews what it did after the original user context ended.

Related resources from NHI Mgmt Group

• Who is accountable when an application keeps access after a user leaves the directory?
• Who is accountable when a service account or AI agent keeps access after offboarding?
• Who is accountable when an AI agent acts after the user is offline?
• Who is accountable when a connected integration keeps access after a user disconnects it?