Why are we paying agents ghost salaries in the form of permanent privileges?

Our headcount says 2,400 employees.
Our cloud estate says 9,000 identities.
Who are the other 6,600?

They’re not all bad news. Many are essential: service accounts, workload identities, OAuth apps, CI/CD bots, “helpful” automation scripts, and now, AI agents acting like junior engineers with infinite enthusiasm and zero sense of self-preservation.

But, a chunk of them are orphaned agents: digital employees with privileges and credentials… and no manager, joiners/movers/leavers with no HR file, and no exit interview. OWASP has effectively made this official by ranking Improper Offboarding as the #1 non-human identity risk, because stale identities tied to deprecated services get forgotten, stay active, and become a quiet access path for attackers. These cheery little chatbots and AI personal assistants (like OpenClaw) are being embraced by time-poor colleagues, tried once, twice, falling by the wayside, ticking over in the background, and rapidly coming in and out of vogue.

Why This is Now Everyone’s Problem

Two shifts in business thinking, along with the meteoric rise of LLM use in the workplace, are making orphaned agents a more pressing issue than ever:

GenAI is Showing up Outside our Identity Plane

Verizon’s 2025 DBIR executive summary reports that 15% of employees routinely access GenAI systems on corporate devices, and of those, 72% use non-corporate emails as account identifiers, while 17% use corporate emails without integrated authentication, suggesting use outside our corporate policy controls. 

That’s the seed of an orphaning problem: accounts created outside SSO, with no lifecycle, then later connected to real workflows (“just paste this token into the tool”).

Secrets Still Don’t Die When we Think They Do

GitGuardian reports 70% of secrets leaked in 2022 remained active years later, meaning exposed credentials hang around long enough to become infrastructure. 

If our agent is using a long-lived key, and that key leaks, we don’t just have “a leak”. We have a resident credential.

What Orphaned Agents Look Like in Real Cloud Estates

Orphaned agents tend to be, but not exclusively, one of the following:

AWS: Roles and Keys That Outlived Their Workloads

• IAM access keys created for automation users that no longer exist (or no longer should).
• IAM roles created for projects that got re-org’d, renamed, migrated, or abandoned.
• Cross-account roles that used to be justified by “we’ll clean it up later”.
  
  

AWS gives us the raw signals to find this: IAM Access Analyzer can flag unused roles, unused IAM user access keys, and show last accessed information to support permissions right-sizing. But have you ever attempted to decipher the information it delivers? The Rosetta Stone didn’t hold the key to translating that.

Microsoft Entra ID: Service Principals and OAuth Apps With No Adults in the Room

• App registrations created during a PoC, then kept “just in case”.
• Enterprise apps that still have permissions, credentials, and consent grants.

Microsoft now has explicit hygiene recommendations such as Remove unused applications (the staleApps recommendation) and guidance on access reviews to reduce stale assignments and produce audit evidence. 

Google Cloud: Service Account Keys That Shouldn’t Exist (But Do)

• Exported service account keys sitting in CI/CD variables, config files, or repos.
• Keys that are never rotated because “nothing breaks until it breaks”.

Google’s position is refreshingly direct: if you don’t need service account keys, disable key creation and upload via org policy; and use Workload Identity Federation to avoid long-lived keys in the first place. They’ve even moved to automatically disable leaked service account keys detected in public repos (a sign of how common the problem is). 

How Ghost Employees Turn Into Incidents

Orphaned-agents become dangerous during an imperfect storm of circumstances:

1. Authentication that bypasses human controls
   Non-human identities typically don’t go through MFA, conditional access, or “did you mean to sign in from Moldova at 3am?” prompts. They authenticate via keys, client secrets, certificates, and federated tokens.
2. Privilege that’s broader than reality
   Most non-human identities were over-permissioned to reduce friction. Over time, they only use a fraction of what they could do, but nobody trims it because “the pipeline might break”.
3. No lifecycle
   Humans leave; HR triggers offboarding, services get deprecated, but nobody files a ticket to “fire the bot”. OWASP’s top-ranked NHI risk is literally (and I don’t use the word literally lightly) the failure point: identities aren’t removed when the service is gone, leaving exploitable access behind.

In payroll terms: you wouldn’t tolerate a ghost CFO with signing authority. In cloud terms: that’s a stale service principal with a broad role assignment and a client secret that never expires. It’s the sort of thing auditors find and their eyes go wide.

A Working Architecture Pattern

If we want to reduce orphaned agents without a litany of spreadsheets, plate juggling, and barely concealed panic, the methodology is consistent across cloud estates:

Build A Unified Inventory of Human + Non-Human Identities

Not just “we have IAM roles”. We want: identity → owner → environment → purpose → auth method → permissions → last used. If any of those fields are blank, we don’t have inventory, we just have hearsay and folklore.

Make Ownership Mandatory

We have to treat each agent identity as a digital employee with a job description (what it’s for), a workplace (account/subscription/project), and a contract (how long it’s allowed to exist).

If an identity can’t be mapped to an owner, it should be treated as suspect by default.

Prefer Short-Lived Tokens Over Long-Lived Keys

Workload identity federation and STS-style flows reduce “keys that live forever”. Where long-lived credentials must exist, enforce rotation and expiry, and treat “never rotated” as a severity signal. 

Right-Size Permissions Using Usage Signals

Use last-accessed and unused-access findings to trim policies toward least privilege (carefully, iteratively, with blast-radius awareness). AWS explicitly positions this as a workflow: inspect unused access, then refine. 

Replace Standing Privilege With Just-in-Time Access

For agents that occasionally need elevated permissions (deployment, break-glass remediation, migration jobs), grant access only when needed, only for the task, then revoke automatically. That shrinks the window where a compromised identity is truly valuable.

Produce Continuous Evidence (Because Auditors Exist)

Entra ID access reviews explicitly support recurring reviews to prevent stale access and provide auditor-friendly proof. Do the same for non-human identities: recurring reviews, automated flags, documented remediation.

Where A Modern Cloud Identity Security Platform Fits

Doing all of the above manually is “technically” possible. It’s also a nightmare across multi-cloud environments and assorted UIs, with potentially more issues than Vogue. Seriously, good luck with that, I suggest our Trustle free trial to get started instead - it takes as little as 30-minutes to set up and will give clear insight into what non-human employees, with what permissions, are hanging around.

A modern cloud identity security approach (think: multi-cloud entitlement discovery + governance + automated just-in-time access (JIT) and continuous evidence, all in one place) helps by:

• Continuously discovering identities and entitlements across clouds.
• Attributing each workload/agent identity to function/environment.
• Prioritizing risk (standing privilege, sensitive resource reach, stale usage, credential age).
• Enforcing least privilege and time-bound elevation.
• Generating audit-ready proof that orphaned agents are being found and “offboarded” continuously.

Which is really the goal: treat agents like employees. Hire them deliberately. Manage them properly. Fire them cleanly. And stop paying ghost salaries in the form of permanent privileges.