How an Automated Non-Human Identity Lifecycle Should Work

Your quarterly access review closed on Friday. Forty of the service accounts in it belonged to an engineering manager who never opened the campaign. The campaign closed those items without acting on them, so on Monday all 40 accounts still hold everything they held last quarter.

An automated non-human identity lifecycle is the set of rules and workflows that give every identity a machine uses an owner, a reason, and an end date, then grant, review, rotate, and remove its access without waiting for a ticket. Every one of those workflows eventually asks a question nobody answers. The default it takes on silence decides whether your access shrinks or just gets documented.

You probably have the baseline already, with some discovery, a lifecycle diagram, a rotation schedule, and a least-privilege policy. This piece is about the decisions that stall automation once those exist. It starts with the fields automation reads and the default it takes when nobody replies. Then it moves to who acts, the brakes on removal, what happens when people leave, what to rotate after an exposure, and where AI agents fit.

Give every service account and non-human identity an owner, purpose, and end date

Automation can only act on what the record tells it, so every non-human identity needs an owner, a reason it exists, and a date its access ends before any workflow runs. The owner is who the automation asks. The reason is the thing whose end should end the identity, whether that's a project, a pilot, a vendor contract, or a workload. The end date is when the default fires.

Miss any one of the three and the workflow stalls. With no owner, there's nobody to ask. With no reason, there's nothing to watch, and with no end date, there's no moment to act, so the identity can be reported on but never safely automated.

Auditors already ask for the same fields. Safeguard 5.5 of the CIS Critical Security Controls calls for an inventory of service accounts that records, at a minimum, the department owner, a review date, and the purpose, with reviews at least quarterly to confirm every active account is authorized. Identities missing those fields are what non-human identity sprawl is made of, and they cluster by the source that created them without a ticket.

Filling those fields gets easier when every source lands in one table, which is what Lumos's Non-Human Identity Inventory, now in beta, gives you. It pulls in service accounts, service principals, API identities, and workload roles from AWS (every account at once), Entra ID, and OpenAI, with each one's source, type, last activity, and status. You set an owner and a business justification on each, and Lumos's security agents, remediation, and access reviews work from them. Lumos maps each non-human identity to a human owner from where it was created, what it reaches, which team uses it, and how it behaves over time.

Then decide what kind of end each identity has. It can be a calendar date, an event such as a pilot, project, or contract closing, or inactivity measured against the identity's longest job cycle, so a quarterly batch job doesn't get flagged as idle in its second month. Record the kind of end next to the date, because each one fires a different way.

This week, count the share of non-human identities that have all three fields, broken out by source. Turn automation on only where that count is complete.

Set a default for unanswered access reviews and orphaned accounts

Unanswered review items and orphaned accounts need a written default, because leaving access in place when nobody responds is a decision too. Without one, your automation keeps whatever it finds.

Klue learned what that costs. In 2022, the company created a GitHub personal access token for a third-party vendor pilot, and although the pilot's build artifacts never reached production, the token could still reach Klue's GitHub environment four years later. In June 2026, an attacker used that access to obtain the OAuth tokens connecting Klue to platforms including Salesforce, then reached data in connected customer environments. Neither Klue nor CrowdStrike could determine how the token was first exposed.

Klue hasn't said why the token outlived the pilot, and whatever the reason, nothing in place ended it when the pilot did. Klue has since blocked personal access tokens across the company and moved those workflows to short-lived credentials.

NIST already names the moments silence should end access. Control AC-2(3) in NIST SP 800-53 Rev. 5 asks you to disable accounts within a period you define once certain conditions hold. Those are accounts that have expired, are no longer associated with a user or individual, violate policy, or have been inactive for a period you define. NIST leaves both periods to you, which means the default is yours to write.

An automated non-human identity lifecycle that waits for a yes before removing anything will keep every account nobody remembers. Getting triggers to ask the question in the first place is the core work of non-human identity lifecycle management. The table below, the silence table, covers what happens when the question goes unanswered. Its windows are starting points to tune for your own environment.

‍

We think silence should end access on a schedule a named person can override. The rest of this piece is about making that default safe to run.

The first ask is ordinary review discipline that any identity governance software should run. At Sun Country Airlines, Lumos pulls review data automatically from Active Directory, Azure, and the target apps, and assigns each item to a manager or app owner with due dates and reminders. When a reviewer rejects access, Lumos can revoke it automatically or attach the evidence of its removal to the review, and the airline's managed service accounts and privileged access are now fully certified. What the silence table adds is the step after the last reminder, when nobody has decided at all.

Write your own version of the table this month and get a named approver to sign it. Run it in report-only mode for one cycle before it acts, so you can see what it would have removed.

Run automated access reviews for low-risk access and escalate the rest

Automated access reviews should certify low-risk access on their own and send the rest to people. The same split works for every lifecycle action, sorted by how hard the action is to undo and how far it reaches. A change that touches one integration and a change that touches a production database deserve different hands.

Three tiers cover almost every lifecycle action. Agents run the first tier alone, with a record: certifying unchanged, low-risk access that's in use, disabling identities past their end date, expiring time-bound grants, sending reminders, and proposing a likely owner for someone to confirm. In the second tier, an agent drafts the change and a person launches it, which covers removing access a production workload uses, deleting identities after quarantine, rotating shared credentials, and anything that touches more than one team. The third tier stays with people: changes that reach production across the company, exceptions to your silence table, and identities a regulator or customer contract names.

Write the tiers into your AI agent access policies, then roll them out in order, starting with the first. Our CEO has written that Lumos started by assisting with access decisions and moved to acting on its own in low-risk cases first, and lifecycle work deserves the same sequence.

In practice, the routine stops landing in your queue. The Access Review Agent in Lumos's Identity Agent Force runs reviews end to end, certifies safe access on its own, and sends people only the items that need a decision. Another agent on the same team watches service accounts, keys, and tokens and shuts down the dormant or overscoped ones. For fixes that are harder to undo, Remediation Workflows has a Lumos agent build the steps, including manual ones for apps Lumos can't write to, and a person reviews and launches them.

The payoff shows up as attention. Tekion handles more than 1,500 requests a month through Lumos, and 95% of those tickets resolve without manual intervention, which leaves people only the remaining 5%. Those are people's access requests, and the same split carries over to machine identities.

The tiers can shift over time. As agents build a record on a kind of action, that action can move toward the first tier, and anything that surprises you moves back toward people.

Add safeguards to automated deprovisioning before it runs on a schedule

Automated deprovisioning needs brakes before it gets a schedule, because a bad sync can remove access at a scale no reviewer would ever approve. The removals that do the most damage come from the plumbing.

A source returns an empty list after an API change, a connector points at the wrong tenant, or a filter matches everything. Any of the three can disable thousands of identities faster than anyone reads the alert, and the outage that follows can stall your removal program for months.

Four brakes keep that from happening. Stage every removal, so access is disabled first, credentials stay recoverable through a quiet period, and deletion comes last. Cap mass changes, so any run that would remove more than a set share of a source's identities stops and waits for a person, and require a reason to raise the cap.

Build exceptions in, and give each one an owner and an expiry so it doesn't turn into a permanent hole. Treat failed removals as open work, so a removal that errors becomes a task with an owner and a retry, and nothing fails quietly.

We ship Lumos's Sync Circuit Breakers turned on, so a bad sync stops before it lands. They halt any sync that would deactivate or remove accounts or identities in bulk, tripping at 50% for mass deactivation, mass absence, and mass identity deactivation, and on an empty account response. Any change to those thresholds needs a reason and goes into the audit trail. Account Workflows run provisioning and deprovisioning as one set of workflows per app or entitlement, reused by onboarding, movers, offboarding, and access reviews, so a failed removal turns into a task wherever it started.

Exceptions are what keep the default switched on. Marqeta uses Lumos inactivity workflows to reclaim people's unused SaaS licenses automatically, and its identity security team made exceptions part of those workflows, because pulling access from key stakeholders with no notice costs you their support. Log every exception with its owner and expiry, since auditors testing your non-human identity management audit readiness will ask why an identity kept its access.

Before removal runs on a schedule, set the mass-change cap and test it against an empty sync in a staging tenant. Then name an owner for failed-removal tasks.

Prevent orphaned non-human identities when employees leave or change teams

When someone leaves or changes teams, the non-human identities they own have to change hands that day, because revoking them can break production and ignoring them creates orphans. Offboarding is built around a person's own accounts. The service account they created, the token on their personal profile, the integration they authorized, and the shared admin password they knew all survive it by design. Each is one of the everyday non-human identity examples that offboarding built around people never touches.

NIST's account management control covers this too. AC-2 asks you to align account management with personnel termination and transfer processes, and to change shared account credentials when someone leaves the group.

‍

Movers get the same treatment. When someone changes teams and the new team doesn't own the workload, run the table as if they'd left.

The leaver event your workforce identity and access management program already runs can be the same event that hands off what a person owned. Lumos Lifecycle Management grants, adjusts, and revokes access as HRIS events fire, and its leaver workflow revokes across IdPs, local accounts, custom apps, SaaS, cloud, and on-premises apps at once. Approval by Entitlement Owner routes each access request to the owner of the permission and alerts admins when no owner resolves, so ownership gaps surface at request time. Because owners of non-human identities live in the same Lumos inventory, the leaver event and the ownership hand-off run from one record.

Pull every non-human identity whose owner left in the last 90 days. That list is your first hand-off batch.

Scope secret rotation by what an exposed credential could reach

After an exposure, rotate every credential the exposed path could reach, since an attacker who got one secret will try the ones stored next to it. Zeabur, a cloud deployment platform, shows what a narrower rotation leaves behind.

In October 2026, according to Zeabur's preliminary incident report, an attacker used the company's AWS keys and a shared cluster admin token, created in January 2024 with no expiry and stored in plaintext in a configuration repository. From there, the attacker read secrets across Zeabur's shared clusters and records from its platform database. The rotation Zeabur ran after an August incident hadn't covered those credentials, and the report corrects its earlier claim that all internal admin keys had been disabled or rotated: "That statement was incomplete."

The same report found a deploy key for a decommissioned service still valid four months after the service shut down. Two days before publishing it, Zeabur announced it would wind down operations, naming both incidents among its reasons.

Set rotation scope by reach. That means every credential stored alongside the exposed one (the same repository, vault path, CI context, or host), every identity the exposed one could read or create, and every credential that belongs to a decommissioned service. Rotate, cut over, and revoke the old values, then search your logs for any use of an old value after the rotation time. If you're working out how to secure AI agents, apply the same scoping to every credential an agent can read.

Automated credential rotation makes that job fast, and it covers only what's on the list, which is why the list has to come from reach. Routine rotation belongs after ownership and right-sizing in the order of fixes for service account governance, while incident rotation can't wait for either.

Scoping by reach depends on knowing what each identity can touch. For on-premises and hybrid directories, Lumos's Active Directory NHI connector, in beta, maps the hosts, services, and groups each service account, computer account, and managed service account can reach, Domain Admins included. Owners can revoke access or rotate credentials for a non-human identity straight from the review, and Albus can stage a revocation with its supporting evidence for a person to approve.

Put retired services on that list every time. Nobody watches a service's keys after it shuts down, and Zeabur's deploy key was still valid four months later. Retiring those keys on schedule is one of the cheapest steps in non-human identity breach prevention.

Check AI agent access at every MCP tool call

AI agents change what they reach with every task, so the last lifecycle check has to happen before each tool call, where AI agent access control decides what runs. A coding agent acts with its person's access, picks up a new MCP server midweek, and runs shell commands and file edits nobody provisioned, and a quarterly review sees none of it. For agents, non-human identity access management has to cover each call, since the grant says little about what the agent will do with it.

Lumos MCP Governance puts that check in front of every tool call in the coding agents it supports, with a hook that returns allow or deny before the call runs. It records the server, tool, inputs, person, and verdict, including servers employees added locally, and covers MCP calls, Bash commands, file edits, and browser use at a target of under 50ms per check. It ships set to Allow, so you write the policies, using the call history it collects as your evidence. The Agent Ownership Finder gives every new agent an owner before it starts work.

Then fold agents into the same lifecycle as everything else, which is where AI agent identity and access management meets the rest of your identity program. Each agent gets an owner, a reason, and an end date in the same inventory as your service accounts, takes the same row in your silence table, and falls under the departure hand-off when its owner leaves. That's the baseline AI agent identity governance builds on. Agents also bring triggers people don't, such as a new MCP server appearing, which AI agent lifecycle management handles stage by stage.

Every new agent tool your engineers adopt adds identities nobody filed a ticket for. Keeping agents in one inventory with your service accounts, under the same defaults, means the lifecycle you built for machines covers them on day one.

Design non-human identity automation for the owner who never answers

Many of your non-human identities will hit a question nobody answers, whether it's a review item, an end date, or an owner who left. The default your automation takes at that moment is one of the most consequential settings in your identity program, so write it down.

This month, fill in owner, reason, and end date and get the silence table signed. This quarter, turn on the brakes, wire departures to ownership, and write the reach-based rotation runbook, then hand the routine to agents and keep people on the exceptions. An identity nobody will vouch for should lose its access, not keep it.

Lumos runs that lifecycle in one place. It keeps people, non-human identities, and agents in one inventory with owners and reasons, and runs joiner, mover, and leaver changes from HRIS events. It removes access through one workflow engine with circuit breakers, puts the Identity Agent Force on routine reviews and dormant credentials, and checks agent tool calls with MCP Governance. Book a demo to see what your automation would do with the next question nobody answers.

‍