The scene is always the same and it never looks serious. Somebody on the team leaves — better offer, new city, contract ends — there is cake, there are good wishes, and there is an offboarding checklist somebody works through diligently: hand back the laptop, close the email account, pull CRM access, settle the final paycheck. All correct. And somewhere, the flow that person built fourteen months ago to sort the invoices arriving by email still fires at 7:05 in the morning, like every day. Nobody writes it on the checklist, because the process is not broken. It works. That is exactly the problem.
The thesis in one line: at a company with no platform team, AI operating risk does not come in through an attack, it comes in through a resignation. No intrusion, no vulnerability, nothing an antivirus picks up. Just a live process running under the identity of someone who is gone, and logic that lived in their head. The failure does not land on the leaving day: it lands weeks later, when a token expires, when a password gets rotated, or when somebody decides — with perfectly good judgement — to finally close that account nobody has used in months.
And when it lands, it lands with no trail. This is not a code error a log will explain: it is a process that stopped happening and that nobody misses until a customer asks about their invoice.
What happens to automations when an employee leaves: nothing, until a credential expires
The mechanism is worth understanding, because intuition gets it wrong here. When a person leaves, their automation does not stop. Flows are not tied to an employment contract: they are tied to credentials, and credentials outlive the person by design. An API token is valid until its expiry date. An OAuth grant given to a tool stands for as long as the account that granted it exists. A key pasted into a connector panel has no idea whether the person who pasted it still works here.
So nothing visible happens on the last day, and that creates the false comfort that there was no dependency. There was, and it shows up at one of these four moments, always weeks or months late:
- The token expires. Almost every integration credential has a shelf life. The day it runs out, the flow starts returning an authentication error nobody reads, because the alerts were going to the inbox of the person who left.
- The account actually gets deleted. At first the user is usually just suspended so nothing breaks. Months later, in a license cleanup — which is a cost conversation, not a risk one — it gets removed. And every authorization it granted goes with it.
- Something changes on the other side. The vendor updates its API, the bank changes the statement format, the CRM renames a field. The flow needs a ten-minute fix that only somebody who understands why it was built that way can make.
- A new exception shows up. The edge case the logic never covered. The person who left knew what to do with it because they decided it; whoever is left does not even know the decision existed.
This is not shadow AI, and counting agents does not fix it
It gets confused with two neighboring problems, and the confusion is expensive, because all three are fixed with different levers.
Shadow AI is unauthorized use: people running tools the company never approved. That is unmet demand, and it gets solved by offering a sanctioned route. Inventory is a counting problem: not knowing how many automations you have or what they touch. That gets solved by looking.
The offboarding one is something else: it is lifecycle. An automation can be perfectly authorized, perfectly inventoried and perfectly described in a spreadsheet, and still be fragile, because what it lacks is not permission or a record: it lacks a living owner and an identity of its own. An inventory tells you the flow exists. It does not tell you it runs on Rachel’s credentials, and that Rachel left in March.
The practical difference: shadow AI and inventory are solved with a snapshot. Lifecycle is only solved with a process, because people will keep joining and leaving your company for as long as the company exists.
The data: the market still cannot revoke an agent’s credentials
There is one number worth looking at closely — not because it describes small businesses, it does not, but because of who it measures. In its 2026 Identity Security Landscape report, based on a survey of 2,930 security leaders worldwide, Palo Alto Networks publishes two figures that, read together, describe this hole better than any anecdote: 99% of organizations have already adopted AI agents, and only 37% can revoke an agent’s credentials. Only 30% keep an immutable audit record of what those agents do. Source: How to Assess Maturity When Machine Identities Outnumber Humans 109:1, Palo Alto Networks, May 2026.
The scope matters and it should be said plainly: this is a global survey of large enterprises, with a security team, a budget and a CISO filling in the questionnaire. It is not a sample of small or mid-sized companies in Spain, Portugal or anywhere else. But that is exactly why it works as a floor: if two out of three organizations with a security team cannot cut off an agent’s access, the question of what happens at a forty-person company where the head of operations built the flow on a Thursday afternoon answers itself.
The same report points at exactly where the gap sits: most organizations can explain what each agent is for, and far fewer can define what it accesses, how that access is limited, when its permissions get revoked and which other systems inherit that access. This is not a problem of not knowing the purpose. It is an end-of-life problem.
| What the offboarding checklist does cover | What it does not cover | What breaks |
|---|---|---|
| Email, laptop, CRM access, final paycheck | The credentials their automations run on | The flow stays alive under the identity of somebody who is gone |
| Handover of accounts and open tasks | The judgement they used on the edge cases | The first new exception, and nobody knows how to resolve it |
| Taking the person off the mailing lists | Redirecting the error alerts from their flows | The failure happens and the warning goes to a closed inbox |
| Signing off the exit paperwork | Writing down who inherits that process | The process loses its owner without anybody deciding it |
The three questions missing from your offboarding checklist
This does not need a project. It needs three questions in the exit conversation, asked before the last day, while the person is still here and still happy to help:
- What identity does each thing you built run on? Not «what did you build»: which account. The useful answer is a list of flows and, next to each one, the account or the key it uses. If any line says «my account», you have just identified Monday’s work. This is the question that decides whether a departure is paperwork or a deferred incident.
- What did you decide that is not written down? Every useful automation has a layer of judgement that is not in the configuration: what counts as a duplicate invoice, when an email deserves a human reply, which vendor is always the exception. Half an hour recording that person walking through the edge cases is worth more than any manual they write in a hurry.
- Who does this have to notify when it fails? Not «who did you notify». Who has to be notified from now on. A flow whose alerts go to an inbox that is about to be closed is a flow already failing silently — you just do not know it yet.
The three fit in a forty-minute meeting and clear most of the risk. The full version of the first one — which identity, with what scope, and what it can touch — is laid out in the guide to an AI agent’s permissions, which is where it gets decided whether this exit conversation is awkward or trivial.
What to do if you have already lost the person
The common case is not the preventive one: it is the reactive one, with the person gone three months and nobody sure what is still running. Work order, cheapest first:
- Do not delete the account yet. Closing it for hygiene is tempting, and it is the fastest way to turn a latent risk into an outage. Suspend interactive access — so nobody can log in as them — and leave the integration credentials alive until you have finished step 3.
- Look at what is still happening under that identity. The access logs of your main tools (email, CRM, ERP, the automation platform) tell you what activity is still running in that account’s name. That is your real inventory, far better than the one you would build from memory.
- Reissue every credential in the company’s name. Create a service account with permissions scoped per flow and re-authenticate the connections. It is boring work, an afternoon of it, and it is the only step that removes the problem instead of postponing it.
- Redirect the alerts to a team inbox. Not to another person: to an address that survives the next departure. This is what turns the next failure into something somebody reads.
- Write the logic down as you recover it. Whatever the logs and the people still here tell you, write it down right then. That document is not going to get written later; it never gets written later.
If during step 2 you find a flow that has been failing for weeks without anybody knowing, the problem is no longer the departure: it is that nobody was watching. That is a different conversation, and it is in the guide on who answers when an automation goes down.
The design mistake happened earlier, the day it was built
Everything above is damage control. The cause sits at a much earlier and much cheaper moment: the day somebody built the flow with their own account because it was what they had at hand and it worked. Nobody did anything wrong. Nobody decided otherwise, that is all, because the decision was not on anybody’s list.
Three rules stop it happening again, and none of them cost money, only agreement: no automation runs on a person’s account — service accounts with scoped permissions, always; every live flow has a name next to it, the person who answers for it, and that name gets reviewed whenever somebody changes role; and alerts go to a team inbox, never to an individual. The three together turn a departure into admin, which is what it should be. The full frame for that decision is in the guide to governance and control of AI automation.
And there is one case no internal rule reaches: when the person who built the system was never on the payroll. If your automations were stood up by a consultant or an agency, the day the contract ends this exact scene repeats, except there is no exit conversation and no goodbye cake. Which is why maintaining what runs is a service and not a favor: somebody has to maintain the AI agents once whoever built them is gone, and that question gets answered before signing, not after.
An automation only one person understands is not an asset. It is a debt with an unknown due date, and the date is set by the job market, not by you.