Skip to content

When the app's builder leaves the company

Trigger the handover from the HR leaver or mover event, not from someone noticing a broken app. For a planned departure, before the builder's account is disabled, the app owner names a new maintainer or starts retirement, and moves credentials, secrets, agent grants, documentation and platform ownership to the successor. For an immediate or involuntary departure, access goes first and IT does the handover from the admin side. Apps and agents running on a person's own credentials or OAuth consent break when that person's account is disabled, or stay open if it never is; both are failures you can prevent.

Who this is for

App owners, IT managers and HR partners. You get a timeline from notice to 30 days after the last day, a path for immediate departures, a handover checklist, ways to detect leavers, and what to do when nobody handed anything over. Reading time: about 9 minutes.

No registry yet, so you can't tell which apps the person built? Start with what to do if nobody owns this today, then come back to the checklist.

What happens, and when?

The clock starts when the person gives notice or a role change is decided. The steps below assume a planned departure and that the HR event reaches IT; if it doesn't, see if HR events don't reach IT.

When What happens Who
Notice given, or role change decided The HR event reaches IT. IT matches the person's directory account against the registry's person fields (builder, owner, backup, maintainers, data owner) and the grants that run as a person, and lists every identity, grant or token issued under their name. The app owner names a new maintainer, or starts retirement HR partner, IT/platform owner, app owner
Before the last day, while the account still works The handover checklist below is completed. The successor runs the app once from the runbook with the builder present. New secrets and service-identity grants are created and tested Builder, app owner, successor
Last day The account is disabled once the checklist is done. Old secrets and the leaver's grants are revoked as access is removed. Anything not moved is paused (quarantined) rather than left running on a dead or open identity IT/platform owner
30 days after Confirm nothing broke, no grant or consent issued under the leaver's name remains, leftover personal workspace content is handled under your retention rules and any legal hold, and the registry record is current App owner, IT/platform owner

If the departure is immediate or involuntary

A termination, a hostile departure, a death or any departure where access must end now doesn't wait for the checklist. Standard personnel-termination practice is to disable access at once (for example, NIST SP 800-53 control PS-4)3.

  1. Disable access at the moment of notice: the account, its sessions, and its tokens and OAuth consents.
  2. IT takes admin control of the person's workspaces and apps on the platform.
  3. Quarantine anything that ran on the person's identity, rather than letting it fail silently or keep running.
  4. Preserve before you delete. Ask counsel whether a legal hold applies before anything in the workspace, prompts or logs is deleted (legal points).
  5. Do the checklist from the admin side, using the app record and the runbook instead of the builder. Where the documentation is missing, treat the app as an orphaned app.

What goes on the handover checklist?

Work through this before the account is disabled on a planned departure, or from the admin side on an immediate one. Each item is one line in the app record.

  • Registry: the owner, successor and maintainer are correct, by role and directory account, and the record lists every identity and grant (app registry).
  • Platform ownership: the app, its workspace and its hosting belong to a shared or service owner, not the leaver's personal account. A shared app on a personal account is a never-do; move it now.
  • Copies outside company accounts: the leaver confirms in writing that they hold no app source, exports or company data in personal storage, personal accounts or the chat history of personal AI tools, and transfers or deletes anything they do hold. Anything built on a personal account is moved to a company account now. This also supports the "reasonable measures" that trade-secret protection depends on (legal points).
  • Credentials: the app runs under its own identity (a service account), not the leaver's login. Re-create anything that used the leaver's sign-in.
  • Secrets: create new keys, tokens and passwords for everything the leaver knew or could read, before the last day, held server-side in a secrets manager or a qualifying platform secret store (secrets). Switch the app over, and revoke the old ones when the leaver's access is removed. Rotating earlier, while the leaver can still read the new ones, protects nothing.
  • OAuth consent and agent tokens: for every consent and token issued under the leaver's identity, issue a service-identity grant with the same or lower scope, switch the app over, test it, then revoke the leaver's grant. Revoking first causes the outage this page is trying to prevent.
  • MCP server registrations: list the servers the app's agents connect to, and move their credentials the same way.
  • Scheduled jobs and triggers: each has a new owner and still runs. Many stop when their creator's account is disabled.
  • Integrations and webhooks: connections to other systems are owned by the service identity, and their owners are told.
  • Source and configuration: exported and stored where the successor can reach them, with version history.
  • Documentation: the successor has used the app record and runbook to run the app and found them sufficient. Fix gaps now (document an AI-built app).
  • Data: you know where the app's data lives, who can reach it, and which sharing links the leaver created ("anyone with the link" links especially).
  • Restore: the last restore was tested, or one is done now.
  • Users: told who to contact, and the help-desk routing reads the new owner from the registry.

Don't: leave apps or agents on a leaver's personal credentials or consent

An agent that runs on a person's OAuth consent breaks when the account is disabled, or keeps working with that person's access if it isn't. OWASP lists improper offboarding first among non-human identity risks1; the stolen-token case is the Salesloft Drift incident on agent security (AP19).

Don't: on a planned departure, disable the account first, or leave it enabled indefinitely

Disabling first breaks apps the owner hasn't moved; leaving the account on "for the app" keeps a former employee's access alive. For a planned departure, move the app, then disable the account, and quarantine anything not moved by the last day. This doesn't apply to an immediate or involuntary departure: then access goes first, and "the app needs it" is never a reason to keep it.

How do I detect leavers automatically?

Don't rely on people remembering. Send HR leaver and mover events to an IT workflow that opens a task for the app owner, listing the person's apps from the registry's person fields. Back it with the registry's health checks: an owner-left check on platform inventories (vendor guidance describes a daily one; build the capability, because that vendor's starter kit is no longer maintained2), identity-provider reports of grants tied to disabled users, and inactivity notices.

If HR events don't reach IT

Reconcile monthly by hand: export the list of people who left or changed roles, match their directory accounts against the registry's person fields (builder, owner, backup, maintainers, data owner) and against the grants that run as a person, and open a handover task for each match. Expect to find some apps by breakage or help-desk tickets until the feed exists (A-035).

What if no handover happened?

Don't delete anything and don't leave it running unexamined. Follow the orphaned app recovery guide, then reassign it (re-answer the six tier questions first), graduate it if a trigger has fired or it's Critical (graduate to IT), or retire it, preserving data first if a legal hold might apply (retire an app). An app with no owner doesn't stay in service (app ownership).

Not legal advice

Not legal advice. This page summarizes laws as of October 2026 for a general audience. It was written with an AI legal-research persona and hasn't been reviewed by a lawyer for your situation. Ask your counsel.

Three legal issues come up when a builder leaves.

  • Who owns what the builder made. For employees acting within their job, US and Canadian copyright law generally gives the employer ownership by default. In the US, a work an employee prepares within the scope of employment is a "work made for hire", and the employer is the author (17 U.S.C. §§101, 201(b))45. In Canada, the employer is the first owner of a work made in the course of employment under a contract of service, unless an agreement says otherwise (Copyright Act s. 13(3)); moral rights stay with the author unless waived6. Agreements decide the edge cases:

    • Contractors and temps generally own the copyright in what they make unless there's a signed written assignment. US work-for-hire agreements cover only certain kinds of commissioned work, and software usually needs an assignment; Canada requires assignments to be in writing and signed (s. 13(4)).
    • Work outside the job, or on personal time or equipment.
    • Inventions: some states limit what an employer can require employees to assign (for example, Cal. Lab. Code §2870)7.
    • Anything built on a personal account, where the AI tool's terms may give output rights to the account holder and the business may be unable to get into the account.

    Code or content an AI generated may have no copyright at all. The US Copyright Office's January 2025 report says prompts alone don't give enough control to make the user an author8, and the D.C. Circuit held in Thaler v. Perlmutter (March 2025) that copyright requires a human author, and the Supreme Court declined to review it on 2 March 2026, so that ruling stands9. The business can still protect the app through contract, confidentiality and trade-secret measures. See IP and licensing. - Personal data about the leaver. The workspace, prompts and logs may hold personal information about the leaver. Quebec's private-sector act, and Alberta's and British Columbia's PIPAs, cover employee personal information101112. PIPEDA covers employee information only at federally regulated employers (federal works, undertakings or businesses, s. 4(1)(b)); its commercial-activity reach (s. 4(1)(a)) covers customer information in the app, not the leaver's own HR data at a provincially regulated employer13. In the US, the CCPA has covered California employees' and applicants' personal information since 1 Jan 2023, for businesses above its thresholds (annual revenue over $26,625,000, as of October 2026)14, including the rights to know and to delete, which a leaver may use. Limit access to the leaver's personal files, and handle them under your retention policy. - Legal holds. Prompts, outputs and agent logs can be electronically stored information. Once litigation is reasonably anticipated, deleting a leaver's workspace or logs can breach the duty to preserve. In US federal court, if information is lost because a party didn't take reasonable steps, the court can order measures to cure the prejudice, and harsher sanctions such as an adverse inference need a finding of intent to deprive (Federal Rule of Civil Procedure 37(e))15; state and Canadian courts have similar duties. Ask counsel about holds before you delete or retire anything.

Questions to ask your counsel

  1. Can we keep and use the leaver's app and prompts, and do their employment terms, a contractor's agreement or the AI tool's terms limit that? Did any contractor or temp build or change it, and do we hold a signed written assignment?
  2. Is anything in the leaver's workspace, prompts or agent logs under a legal hold, and how does counsel tell IT when a hold starts and ends?
  3. What may we do with personal information about the leaver in the app or its logs, and how do we answer a leaver's request to access or delete their data held in our AI tools and app logs?
  4. Do our retention schedule and hold process cover AI tools, and can the tools suspend deletion on a hold?

Assumptions and evidence

  • A-035 (Low): we expect IT to receive HR leaver and mover events in time to trigger handovers, or to reconcile monthly by hand; test this by counting how many leavers' apps are found by breakage or help-desk ticket rather than by the leaver event.
  • A-044 (Low): we expect agent and automation identities, grants and tokens to be inventoriable and tied to an owner role cheaply; test this by counting grants under a leaver's name that survive the 30-day check.

Evidence: vendor guidance, an OWASP list, a federal security control catalog and legal research (statutes, a court rule and one appellate decision); no quantified post-mortem of handovers in AI-built apps. Facts on this page are as of October 2026.

  1. OWASP, "Non-Human Identities Top 10" (2025), NHI1 Improper Offboarding and NHI2 Secret Leakage. https://owasp.org/www-project-non-human-identities-top-10/ [primary], accessed 2026-10-21. ↩

  2. Microsoft, tenant hygiene guidance: a daily check for resources owned by former employees; the starter kit is no longer actively maintained. https://learn.microsoft.com/en-us/power-platform/guidance/coe/after-setup-tenant-hygiene [vendor], accessed 2026-10-21. ↩

  3. NIST SP 800-53 Rev. 5, control PS-4 "Personnel Termination" (2020, updated; still the current federal control catalog). https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf [primary], accessed 2026-10-21. ↩

  4. 17 U.S.C. §101, definition of "work made for hire". https://www.law.cornell.edu/uscode/text/17/101 [statute], accessed 2026-10-21. ↩

  5. 17 U.S.C. §201(b), works made for hire. https://www.law.cornell.edu/uscode/text/17/201 [statute], accessed 2026-10-21. ↩

  6. Copyright Act (R.S.C. 1985, c. C-42), ss. 13(3) and 13(4). https://laws-lois.justice.gc.ca/eng/acts/C-42/page-3.html [statute], accessed 2026-10-21. ↩

  7. California Labor Code §2870, employee inventions. https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=LAB&sectionNum=2870 [statute], accessed 2026-10-21 (our fetcher was blocked; URL pattern matches the official code site). ↩

  8. US Copyright Office, "Copyright and Artificial Intelligence, Part 2: Copyrightability" (29 Jan 2025). https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf [regulator], accessed 2026-10-21. ↩

  9. Thaler v. Perlmutter, No. 23-5233 (D.C. Cir. 18 Mar 2025), https://media.cadc.uscourts.gov/opinions/docs/2025/03/23-5233.pdf [court]; certiorari denied, No. 25-449 (U.S. 2 Mar 2026), docket https://www.supremecourt.gov/docket/docketfiles/html/public/25-449.html [court] and case page https://www.scotusblog.com/cases/thaler-v-perlmutter/ [secondary], accessed 2026-10-21. ↩

  10. Quebec, Act respecting the protection of personal information in the private sector, CQLR c. P-39.1. https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1 [statute], accessed 2026-10-21. ↩

  11. British Columbia, Personal Information Protection Act, SBC 2003, c. 63, s. 1 ("employee personal information"). https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03063_01 [statute], accessed 2026-10-21. ↩

  12. Alberta, Personal Information Protection Act, SA 2003, c. P-6.5. https://kings-printer.alberta.ca/documents/Acts/P06P5.pdf [statute], accessed 2026-10-21 (the official PDF fetched, but its text wasn't extracted, so the content is unverified). ↩

  13. Personal Information Protection and Electronic Documents Act (S.C. 2000, c. 5), s. 4(1). https://laws-lois.justice.gc.ca/eng/acts/P-8.6/page-1.html [statute], accessed 2026-10-21. ↩

  14. California Civil Code §1798.140 (definitions of "business" and "consumer"); the employee and applicant exemption expired on 1 Jan 2023; revenue threshold adjusted from 1 Jan 2025 (next adjustment 1 Jan 2027). https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.140 [statute], accessed 2026-10-21 (our fetcher was blocked; threshold per the CPPA adjustment notice, https://cppa.ca.gov/regulations/cpi_adjustment.html). ↩

  15. Federal Rules of Civil Procedure, Rule 37(e), failure to preserve electronically stored information (a court rule, US federal courts only). https://www.law.cornell.edu/rules/frcp/rule_37 [court], accessed 2026-10-21. ↩