The AI Agent Whose Builder Already Left

Somebody in operations builds an automation inside a sanctioned platform to solve a problem in their own workflow. It works, other people come to depend on its output, and eighteen months later that person leaves.

‍

The platform still lists the automation. Nobody inherits it, because it was never anybody's asset to begin with, and the offboarding checklist has no line for a thing that was never recorded as belonging to the person departing.

‍

Which Failure Mode Is Worse?

‍

There are two and they are opposites, which is the distinction that determines whether deprovisioning helps at all.

‍

An automation running under the leaver's own credentials stops when the account is disabled. Something breaks, somebody complains, and the organization discovers the dependency it did not know it had. The failure is disruptive and it is the safe outcome, because the automation announced itself.

‍

An automation holding its own credential continues. No account was disabled, nothing failed, and it keeps reaching whatever it reached before under an identity nobody is reviewing. It produces no signal at any point, which makes it the case worth worrying about.

‍

Deprovisioning Is Not the Control

‍

Disabling a leaver's account addresses the first case by causing a visible failure and does nothing for the second. An organization that has never had an automation break during offboarding may be running entirely on the second kind, and enumerating what each identity holds is the exercise that finds them.

‍

What Can the Platform Tell You?

‍

A useful amount, and it is worth being precise about the boundary because the queryable half gets mistaken for the whole picture.

‍

The platform knows that the automation exists, who created it, what connections it holds, what triggers it, when it last ran and how often. All of that is available from an administrative interface without asking anyone, which makes the technical inventory a query rather than a project.

‍

What It Cannot Tell You

‍

Why it exists. What business process depends on its output. Whether that output is still correct. What happens downstream if it stops. Which edge cases the builder handled and which they knew about and ignored. None of that was ever written down, because the person writing it was solving their own problem rather than documenting a system.

‍

What Does Inheriting It Involve?

‍

Two things that get conflated, and only one of them takes seconds.

‍

Reassigning the record is administrative. A name changes in a field, the automation carries on, and a report showing every automation with an owner comes out clean. Understanding it is the other half, and it means reconstructing the purpose, the dependencies and the correctness criteria from the artifact rather than from the author.

‍

Which Produces a Nominal Owner

‍

Somebody whose name sits against an automation they cannot explain. Asked whether it is still working correctly, they have no basis for an answer, and asked whether it can be switched off, they have no way to know what depends on it. A register showing full ownership coverage can therefore be entirely accurate and describe nothing useful, which is a version of the problem accountability resolving to a person or to nobody runs into.

‍

What Should Be Done With One Nobody Understands?

‍

Turn it off deliberately, which is the uncomfortable answer and usually the cheaper one.

‍

The two available options are running something nobody can evaluate indefinitely, or stopping it in a controlled way and observing what breaks. The second discovers the dependency at a moment of your choosing, with the person who notices available to explain what they needed, which scoping an agent incident afterward is considerably harder than. The first discovers it during an incident, when the automation has done something unexpected and nobody can say whether that was normal.

‍

Why Does Nobody Choose That?

‍

Because switching something off is an action requiring an owner, and leaving it running is not. The asymmetry is organizational rather than technical, and naming it is usually enough to get the decision made, particularly where the automation touches production data.

‍

When Is the Discovery Opportunity?

‍

During offboarding, which is the only moment anybody systematically goes through what a departing person had.

‍

Access reviews happen on a cycle and look at entitlements rather than at things built. Asset inventories look at applications rather than at automations inside them. Offboarding is the one process that examines an individual comprehensively, and it currently covers accounts, devices and physical items. Adding a query against the automation platforms for anything that person created is a single step that catches the population at exactly the right time.

‍

What Should That Step Produce?

‍

A decision per automation rather than a list. Transfer with a real handover conversation while the person is still available, or switch it off before they leave, which is the option that stops existing once they have gone. A list generated after departure produces the nominal ownership problem instead, and retiring an automation properly sets out what the second option involves.

‍

How Should the Exposure Be Priced?

‍

Price it by what the automation can reach rather than by what it does, since nobody knows what it does.

‍

An orphaned automation with read access to a reporting database is bounded by that database. One with write access to a system of record can change production data on a schedule, and the consequence is whatever an unreviewed change to that system costs. The reach is knowable from the platform and the behavior is not, so the reach is the only defensible basis for a figure. An AI data fabric supplies the reach from observed activity rather than from the platform's own declaration.

‍

Which Ranks the Population

‍

Write access first, external effect second, regulated data third. An orphaned automation that sends messages outside the organization or alters records that feed a regulatory report sits above one that produces an internal summary nobody reads, and AI risk quantification, or AIRQ, priced on the action set rather than on observed behavior is what produces that ordering.

‍

What Stops This Happening Again?

‍

A decision at build time rather than a process at departure, since the problem is created when the automation is made and only discovered when somebody leaves.

‍

The standard remedy is decoupling identity from automation, meaning a service identity rather than a personal credential, secrets held centrally rather than in the automation, and the definition stored somewhere shared rather than in a personal workspace. All three are sound and all three make the silent failure mode more likely rather than less, since an automation with its own identity and centrally held secrets is precisely the one that keeps running.

‍

Decoupling Needs a Second Half

‍

An owner distinct from the builder, recorded at creation. Decoupling without that produces a durable automation nobody is responsible for, which is a worse position than a fragile one that breaks and gets noticed. The technical fix and the accountability fix have to arrive together, and the difference between the builder and the owner is where that gets established.

‍

What Is the Minimum Record?

‍

Three fields at creation, all of which the builder can supply in a sentence each. What the automation is for, who consumes the output, and who should be told if it stops. None requires documentation discipline and all three are exactly what cannot be reconstructed later.

‍

What Should Be Established This Month?

‍

Three things, and the first is a query rather than an investigation.

‍

Every automation in the sanctioned platforms whose creator is no longer employed, which the administrative interface answers directly. For each, whether it runs under a personal credential or its own, since that determines whether it is still running at all. Then for those still running, whether anybody can state what depends on the output. An AI Interaction Data Fabric joins the platform record to the identity behind it, which is what makes the second question answerable across the population rather than one at a time.

‍

The Visible Failure Is the Safe One

‍

An automation built by somebody who has left fails loudly if it ran on their credentials and continues silently if it holds its own, so an organization that has never seen one break during offboarding may be running entirely on the silent kind. Reassigning the record takes seconds and transfers nothing, since the platform can supply what an automation is and never why it exists, what depends on it or whether its output is still correct. A register at full ownership coverage can be accurate and describe nothing. For anything nobody can evaluate, switching it off deliberately discovers the dependency at a chosen moment rather than during an incident. Kovrr's AI Security and Governance Platform records which automations exist, what each can reach and whose identity it runs under.

‍

To see which automations in your environment run under identities nobody owns, book a demo mapped to your own estate.