Nobody Offboards a Service Account

A controller resigns on a Friday. By Monday the account is disabled, the mailbox is converted, the laptop is in a box, and someone has ticked a line on a checklist that has existed in some form since the 1990s. That process works. It is rehearsed, auditable, and nearly universal.

Now consider the invoice-scanning tool the same controller connected to the accounting system four years ago. It authenticated once, was granted permission to read and write, and has run quietly ever since. No manager is listed against it. No offboarding checklist mentions it. Its credential has never been rotated, and nobody in the building could tell you whether the vendor that built it still exists.

The second identity is the one worth attacking.

Your directory stopped being a list of people

Identity became the security perimeter, and most executives absorbed that message correctly. Budget followed. Multi-factor authentication went in. Conditional Access policies were written. Passkeys began replacing passwords for the workforce. All of it was necessary. None of it was aimed at anything but humans.

Meanwhile the directory filled with everything else: service accounts running line-of-business applications, app registrations and service principals inside Microsoft 365, OAuth grants issued to SaaS tools by whoever clicked accept, API keys embedded in scripts, tokens held by monitoring and data backup agents, automation logins, and credentials sitting in a deployment pipeline that one developer configured before changing jobs.

Ask your IT lead how many non-human identities exist in the tenant. In most companies you will get an estimate rather than a list. That gap — between estimate and list — is the finding, and it requires no statistic to be uncomfortable.

The real asymmetry is in governance, not in count. Human accounts have a lifecycle: hired, promoted, transferred, terminated, with a department that owns each transition. Machine identities have a birth and, usually, nothing after that. They are created under deadline pressure, granted more access than they need because scoping permissions takes time nobody has, and then they persist. Persistence is the whole problem.

Every AI agent you approve is an identity decision

This is the change that moved the subject from a systems administration chore to something worth an executive's attention.

An AI agent is not a chatbot. A chatbot answers a question. An agent takes actions — reads the mailbox, updates the CRM record, files the document, drafts and sends the reply, triggers a step in a payment workflow. To act, it must hold an identity with standing permission to those systems. In many implementations that is not delegated access borrowed from a signed-in user. It is application-level access that works at three in the morning whether anyone is logged in or not.

So when a department head approves an AI assistant for their team, they are not making a software purchase. They are provisioning a non-human account with durable and often broad access to company data, with no visibility into the blast radius. A finance manager evaluating an invoice agent is thinking about hours saved. Nobody in that conversation is asking which mailboxes the agent can read, whether its credential expires, who rotates it, or what becomes of its permissions when the pilot quietly ends and the tool stops being used but never gets removed.

Shadow AI is usually discussed as a leakage problem: an employee pasting a client contract into a consumer chatbot. That risk is real. In our assessment the larger one is agentic shadow AI — tools that were sanctioned, connected, and then forgotten, each holding a live credential into systems that matter. A forgotten browser tab leaks once. A forgotten agent has an account.

A service account cannot be phished, and cannot use a passkey either

Executives sometimes assume machine identities are safer because they are immune to human error. No service account falls for an AI-generated phishing email or a voice-cloned call from the CFO. True, and beside the point.

Nearly every control bought to defend the identity perimeter assumes a human sign-in ceremony. Phishing-resistant authentication depends on a person and a device. Conditional Access reasons about location, device compliance, and risk signals derived from behavior. Impossible-travel detection assumes travel. A service principal presenting a valid client secret from a cloud IP at an odd hour is not anomalous; that is its normal behavior. An attacker holding the same secret looks identical to legitimate automation.

Three structural weaknesses follow, none of them exotic:

• No expiry discipline. Secrets and certificates have expiration dates. When one is about to lapse and break a production integration during month-end close, the fastest fix is to extend it. Extension becomes the habit. Rotation never does.
• Permissions ratchet upward. Access that is too narrow causes a visible failure. Access that is too broad causes nothing at all. So it only ever grows.
• No leaver event. People resign. Integrations are simply abandoned, and abandonment produces no ticket, no notification, and no signal to anyone.

Which is where IT security and ordinary operational hygiene stop being separable disciplines. The credential that would let an intruder exfiltrate a document library is frequently the same one running a nightly export nobody remembers commissioning.

The register nobody wants to build is the whole deliverable

The remedy is unglamorous and mostly non-technical, which is why it keeps getting deferred in favor of buying another tool.

Start with an inventory of every non-human identity in the environment and, beside each one, the name of a living employee who owns it. Not a team. A person. Ownership converts an orphaned credential into something with a lifecycle, because an owner can be asked once a quarter whether the account is still needed and held to the answer. Expect the exercise to surface accounts that cannot be attached to any current business purpose. Finding them is the return on the effort.

Then the boring controls, in order: an expiry date on every credential with rotation actually performed rather than deferred; permissions scoped to the specific data the workload touches; secrets held in a managed vault rather than a configuration file or a script; and platform-native workload identities wherever the cloud provider offers them, so there is no long-lived secret to steal. Assume friction. Rotation breaks integrations, and those tickets reach the help desk at the worst possible moment, so schedule the work around close rather than through it.

Last, gate deployment. No new agent or SaaS integration gets connected without a named owner, a documented permission scope, and a review date.

A prediction, offered as such: cyber insurance questionnaires will move past "do you enforce MFA" and start asking how non-human credentials are governed. Underwriters follow claims, and claims follow the path of least resistance. Companies that can answer with a register will price better than companies that answer with a shrug.

What to settle before the next agent pilot

The executive decision here is narrow and worth making explicitly. Machine identities are assets. They hold standing access to your most sensitive systems. Most of them have no owner. Assign one — then require that every future agent, automation, or integration arrives with an owner, a scope, and an expiry date before it arrives with access.

Pro Link Systems has supported Los Angeles businesses from Woodland Hills since 1999, long enough to watch the interesting risk migrate from the network edge to the login, and now from the human login to the one no person ever performs. This work is not difficult. It is simply nobody's job until someone decides it is.

If you want an inventory of the non-human identities in your environment and a straight assessment of what each one can reach, that is a conversation worth having with our managed IT services team.