Automations are often built by the person closest to the problem, using the access they already have. That is a sensible way to prototype. It becomes a problem when the prototype quietly becomes a business-critical process that still signs in as one employee.
The problem in plain language
A bot, integration or scheduled workflow authenticates using an employee's username, password, token or mailbox. When that person changes role, resets their credentials or leaves, the automation can fail, or it can keep access it no longer needs. Either outcome is usually discovered by accident: an invoice run that did not happen, a report that stopped arriving, or an access review that finds a departed employee's account still active because “something depends on it”.
What the buyer is actually trying to solve
The buyer needs non-human workloads to have durable identities, least-privilege permissions, accountable ownership and lifecycle controls that do not depend on individual employees. Search phrases include “service account best practice”, “automation broke when employee left”, “Power Automate running under user account”, “non-human identity management” or “replace personal credentials in integrations”.
The goal is continuity and control: the process should outlive any one person's employment, and its access should be visible and justifiable.
Evidence and system mechanism
Microsoft and the major cloud platforms distinguish workload identities, service principals and managed identities from human accounts. Microsoft's overview of workload identities defines a workload identity as one assigned to software, such as an application, service, script or container, so it can authenticate to other services. It separates these machine identities from human identities and explains why they are harder to secure: a workload may need several credentials that must be stored securely, and it is hard to track when a workload identity was created or when it should be revoked. The same page notes that attackers increasingly target non-human identities, and describes access reviews for service principals and, for AI agents, identities with enforced human sponsorship.
Microsoft's documentation on managed identities for Azure resources states plainly that manual handling of secrets and certificates is a known source of security issues and outages. Managed identities let workloads obtain tokens without anyone managing a credential, and a system-assigned identity shares the lifecycle of the resource it belongs to.
The design principle is consistent: machine activity should use an identity suited to the workload, with scoped permissions and auditable ownership. A personal account is the opposite on each point. Its lifecycle follows a person, its permissions reflect a job role rather than a task, and its activity looks like that person's activity in the logs.
Why this becomes urgent
Automation, identity and security owners carry the control problem; CIO and COO budgets carry the continuity risk. Urgency rises as low-code automation and AI agents move into business-critical workflows. Specific triggers include:
- a key employee leaves, or a leaver's account cannot be disabled without breaking a process;
- a password reset or multi-factor change stops an integration overnight;
- an access review or audit asks who owns an account used by a bot;
- an organisation introduces AI agents that act in business systems;
- a security incident involves a credential embedded in a script or connector.
Economic consequence
Personal credentials create hidden failure dependencies, emergency recovery work and difficult access reviews. The costs typically include:
- outages in finance, operations or customer processes when the account changes;
- urgent investigation to find which credential a failing process used;
- delays to offboarding because disabling an account is unsafe;
- excess privilege, because the automation inherits everything its owner could do;
- weak audit trails, where human and machine actions cannot be told apart.
Quantify the number of critical automations, the people whose credentials they use, the privileges involved, outages caused by credential changes and the effort spent on remediation.
Root cause
Fast prototypes are promoted into production without an identity model, service ownership or offboarding controls. Nobody decides to run a payroll export on a personal account; it simply works that way on the day it is built and nothing forces a change. Contributing causes include platforms where the default connection uses the builder's own sign-in, no approved route for requesting a workload identity, and no inventory of automations. The same pattern appears with API credentials shared across unrelated integrations and with low-code automations that lack support ownership.
Practical intervention
- Inventory production automations and their authentication methods. Record which account, token or connection each one uses and who created it.
- Replace personal accounts with approved workload identities where supported. Use managed identities, service principals or platform service accounts, and federated credentials where they remove stored secrets.
- Apply least privilege and secret rotation. Grant each identity only what the task needs, and rotate any remaining secrets on a schedule.
- Assign a business and technical owner. Every non-human identity should have named owners, ideally a team rather than one person.
- Monitor authentication failures and access changes. Alert the owning team when a workload identity fails to sign in or its permissions change.
Where a platform genuinely cannot support a workload identity, document the exception, restrict the account and include it in access reviews.
Diagnostic questions
- Which automations stop if an employee account is disabled?
- Who owns each non-human identity?
- Are privileges broader than the task requires?
- Can credentials be rotated without redesigning the workflow?
- Can your logs distinguish an automation's actions from a person's?
What good looks like
Automations use governed workload identities, permissions are scoped to the task, ownership is explicit, and offboarding an employee neither breaks nor orphans the process. New automations reach production only once they have an approved identity and an owner, and joiner-mover-leaver processes for people stay separate from the lifecycle of machine identities. For the human side of that lifecycle, see why new employees wait days for system access.
Where Mellorca fits
Mellorca can inventory automation identities, map privileges, redesign workload authentication and establish operational ownership and monitoring. This work typically sits within business automation and managed digital operations.
Method note
This article describes a class of operating problem. The cited platform documentation explains how workload identities differ from human accounts; it does not establish that any particular automation is at risk. Assess exposure from your own inventory of automations, identities and incidents.
Sources and further reading
- Workload identities - Microsoft Entra Workload ID (last verified 10 October 2026)
- Managed identities for Azure resources - Managed identities for Azure resources (last verified 10 October 2026)
- Managed identities for Azure resources - Managed identities for Azure resources (last verified 10 October 2026)