Your AI Agent Needs an Offboarding Plan

A pilot ends on Friday. Its agent still has a Monday schedule, access to the customer system, and a queue of unfinished work. The project tracker says complete. The automation has no corresponding instruction to stop.

This is a hypothetical example, but it points to a concrete operating responsibility: someone has to close the agent's assignment as deliberately as they opened it.

On October 15, ServiceNow announced AI Passport and expanded AI governance capabilities. The company describes runtime authorization, scoped delegation, and precision revocation, alongside broader discovery of agents. AI Passport and shadow AI detection are expected in Q4 2026. These are announced capabilities, not generally available features we have independently tested.

The practical implication extends beyond this release. As businesses give agents persistent assignments, ending those assignments becomes part of operating the workflow. Our recommendation is to define an offboarding plan before the agent enters production.

Decide whether the job is ending or changing hands

An owner moving to another role does not necessarily mean the workflow should stop. A completed pilot does not necessarily mean it should continue.

Make the business decision explicit. Either the assignment ends, a replacement takes over, or a new owner accepts responsibility for the existing workflow. Each outcome needs a named decision-maker and an effective time.

For a temporary pilot, agree on the decision point at the start. Include what happens if nobody approves an extension. For an ongoing workflow, make ownership changes a reason to review its purpose and scope. An unattended assignment should not acquire indefinite authority because its original sponsor is no longer available.

Keep this proportionate. One business owner can coordinate the decision, with the implementation team carrying out the technical changes. The owner needs evidence that the transition actually happened, rather than a collection of separate teams assuming another team finished it.

Stop the routes that create new work

An agent may receive work from more than the interface where someone originally configured it. Identify the schedules, event subscriptions, and other entry points that can start an execution. Check pending retries and any delegated work that can continue independently.

In the hypothetical pilot, turning off a dashboard button would not establish that Monday's scheduled run has been removed. If a customer-system event can also trigger the agent, that route needs a decision too.

Document which entry points will stop and where future requests should go. When a replacement workflow exists, verify that it receives the intended work. When staff take over, give them a useful queue and the relevant operating instructions. Avoid leaving callers with a successful submission message for a service that no longer has an owner.

The handoff should account for the business calendar. As we discussed in morning handoffs for persistent agents, work can arrive when the people expected to receive it are unavailable. A retirement date needs the same attention to coverage.

Settle the work already in progress

Stopping new assignments leaves a separate question about cases that have already started.

List the unfinished cases and their current business state. Decide which can finish under the existing controls, which should transfer to a person, and which should be cancelled. The appropriate choice depends on the commitment already made and the consequence of stopping partway through.

A prepared customer response awaiting approval is different from a message whose delivery is uncertain. Before transferring the latter, reconcile what actually happened so the receiving team does not repeat an action that already completed.

Give each transferred case a recipient and a next step. Preserve the relevant output and decision history. Marking the agent inactive should not make an unresolved customer request disappear from the operating view.

Set a clear limit on any period allowed for finishing existing work. If an agent remains active to complete a defined set of cases, verify that it cannot quietly accept new ones during that period.

Remove access at the places that enforce it

Disabling an agent in one console does not establish that every credential, integration grant, or delegated permission has been revoked. Verify what the actual platform changes and what remains a separate responsibility.

Map the permissions used by this workflow to the systems that enforce them. Where access is shared with other active workflows, arrange a scoped change that retires this assignment without disrupting unrelated work. A shared service account can make that separation difficult, which should remain a visible design limitation.

Check how revocation reaches delegated agents and existing sessions. Some controls may take effect immediately; others may depend on expiry or a subsequent check. Obtain evidence from the implementation rather than assuming uniform behavior across providers.

This extends the principle in permissions beyond the prompt. Authority needs an enforcement point, and withdrawing authority needs verification at that point. Changing the agent's instructions alone is insufficient evidence that access ended.

Verify closure and keep the record

Use controlled checks to confirm that retired entry points no longer start work and that removed permissions are rejected. Check representative paths that the workflow actually used. Do not attempt to prove closure by trying a more privileged identity.

Confirm that unfinished cases reached their agreed destination and that the receiving owner can find them. Review scheduled resources and subscriptions so continuing costs are either stopped or deliberately retained for a remaining purpose.

Preserve the approved scope, retirement decision, and evidence of the changes under the organization's existing access and retention rules. Someone investigating an earlier action may still need to understand which version ran and who authorized it. Ending execution does not automatically settle the treatment of its records.

For a first review, choose one pilot that has finished or one workflow whose owner has changed. Trace its entry points, outstanding work, and permissions through to a verified closure or an accepted new owner.

If you're moving agents into ongoing operations, talk with Revival Group about building ownership changes and retirement into the workflow from the start.