Do not let an AI agent outlive its sponsor

HR events should trigger agent review, not silently transfer authority

Enterprise agents are starting to look like workers in product language while behaving like a web of non-human identities in technical systems. Ema's September launch illustrates the span: one onboarding request can touch HR, payroll, identity, devices, and email. Microsoft now documents agent sponsors, technical owners, access expiry, sponsorship transfer, and mover/leaver lifecycle workflows. The operational implication is immediate: when a worker changes role or leaves, every agent tied to that person needs a decision.

That does not mean HR should administer service principals or inspect token caches. HR owns authoritative worker events and effective dates. The business sponsor decides whether the agent's purpose continues. IAM and IT resolve identities, credentials, runtimes, and access. Security tests containment. Privacy and records teams decide what state must be retained, deleted, or held. Finance and procurement close licenses and commitments. A safe workflow preserves those boundaries while making one lifecycle result visible.

The rule is simple: an agent's authority must not outlive its sponsor, documented purpose, or current risk decision. Implementing the rule is harder because the "agent" is rarely one object. It may include a directory identity, an app registration, a service principal, a user-like account, several OAuth grants, connector workers, browser sessions, a container, scheduled jobs, subagents, a memory database, logs, backups, vendor accounts, and cloud spend.

Current practitioner discussion reflects the older non-human-identity problem: organizations discover more machine identities than people, many without a live owner, and owner fields that outlast the person who set them. Agent autonomy makes the defect more consequential because a stale identity can select tools and produce external effects rather than merely support a predictable daemon.

Build one canonical agent record across systems

A directory inventory is necessary but incomplete. HR and IAM need a join record that explains what each technical object means in business terms. Give every production agent a stable internal ID that survives vendor display-name changes. Link it to the human sponsor, backup sponsor, technical owner, runtime, blueprint, credentials, tools, data, cost center, purpose, risk tier, review date, and planned end date.

agent_id: agt_hr_onboarding_014
purpose: prepare_and_route_new_hire_setup
business_sponsor: hr_operations
backup_sponsor: people_systems_director
technical_owner: enterprise_automation
risk_tier: consequential_write
planned_end: 2027-03-31
identities:
  - entra_agent: 7d8f...
  - app_principal: 39a2...
runtimes:
  - worker: onboarding-prod-v12
connectors:
  - hris: read_worker_event
  - iam: create_request_only
  - ticketing: create_and_update
state:
  - memory_store: mem_882
  - audit_log: log_117
review:
  next_access_review: 2026-10-11
  expiry_required: true

The record is a relationship graph, not a manually maintained spreadsheet of names. Its sources should be authoritative APIs where possible: HRIS for worker events, IdP for principals and grants, runtime platform for deployments and schedules, connector registry for tools, data catalog for state, and finance systems for cost. Human owners review relationships and purpose; they should not retype every technical fact.

Separate sponsor and owner. Microsoft's Agent ID model makes that distinction explicit: sponsors hold business accountability for purpose and lifecycle decisions, while owners handle technical configuration and credentials. A sponsor should be able to suspend or request retirement without gaining power to rewrite authentication. A technical owner should not extend business authority simply because a runtime still works.

Define lifecycle triggers beyond employee termination

Microsoft documents automatic sponsor transfer to a departing sponsor's manager and mover/leaver tasks that notify managers or cosponsors. Those are useful continuity primitives, not final business approval. A manager may not understand the agent's technical access, affected data, regulatory commitments, or incident history. Transfer should create a time-limited review obligation, not a perpetual inheritance.

Set expiry by default. Direct grants without expiry, review, or approver loops accumulate quietly. An extension should require the current sponsor to restate purpose, users, data, tools, risk tier, and planned end date. If no one can defend the access, expiration is the control working.

Run lifecycle change as an evidence workflow

1. Validate the event and affected relationships

Start with the authoritative HR or business event. Record type, effective time, source, worker, manager, legal entity, and HR owner. Then resolve every agent where the person is sponsor, backup, owner, approver, operator, credential donor, cost owner, or escalation contact. Avoid string matching on names; use stable person and agent IDs.

2. Decide whether purpose continues

The employment event does not itself decide the agent's fate. The business sponsor or successor must state whether the workflow remains necessary, who is affected, what consequences follow, and whether service continuity is required. Choose transfer, reduce, suspend, expire, retire with retention, or emergency contain. A changed purpose creates a new approval, not a metadata edit.

3. Compute effective access, not catalog access

Join direct grants, group membership, roles, access packages, OAuth scopes, delegated rights, connector methods, runtime privileges, network routes, and downstream accounts. Compare what the agent can actually do with the approved purpose. NIST's 2026 concept paper highlights identification, authentication, authorization, delegation, action attribution, and data-flow provenance because these controls compose across the whole action path.

4. Sequence containment and continuity

For routine retirement, prepare fallback and communicate before shutdown. For a credible incident, contain first. Disable token issuance, revoke sessions, rotate keys, stop runtimes, freeze queues, block network paths, and suspend connector workers in an order that does not leave a different route active. Capture partially completed work and outstanding approvals so a successor can decide whether to cancel or finish them.

5. Apply retention before deletion

Agent state may contain employee data, decisions, approvals, business records, security evidence, financial records, or legal-hold material. Classify files, memory, logs, traces, embeddings, backups, exports, and vendor copies. Retention is not the same as keeping the agent runnable. Preserve required evidence in a controlled archive while revoking execution authority.

6. Reconcile after the tools report success

SCIM can standardize create, update, and deactivate operations. NIST correctly notes that it does not itself authenticate or authorize. A 200 response therefore proves only that one endpoint accepted one lifecycle operation. Query the IdP, connector, runtime, scheduler, cloud, vendor, and data systems after execution. Test stale tokens, alternate hosts, restored backups, group inheritance, and blueprint re-creation.

Worked example: the onboarding agent whose sponsor transfers

An HR operations lead sponsors an agent that reads accepted-offer events, prepares identity and device requests, creates onboarding tickets, and drafts welcome communications. The lead transfers to another division. The HRIS mover event is authoritative at 18:00 Friday.

A weak workflow replaces the sponsor field with the former lead's manager and continues. A strong workflow opens a lifecycle case. It resolves the agent ID to an Entra agent identity, app principal, HRIS read grant, ticketing write grant, device-management request connector, email draft connector, two scheduled jobs, a memory store containing onboarding exceptions, a cloud worker, and a vendor subscription.

The successor confirms the purpose remains, but discovers that the agent still has permission to send email even though the approved workflow only allows drafts. IAM removes the write scope and issues an access package expiring in 30 days. IT verifies the runtime digest and scheduler. HR validates that the new sponsor understands exception escalation. Privacy marks historical case memory for 90-day retention and blocks it from new inference. Finance transfers the cost center.

The case closes only after independent queries and negative tests confirm the old authority is gone. The goal is not paperwork. It is preventing a routine personnel move from preserving unreviewed agent access for months.

Use a closure equation that exposes missing proof

complete = all([
  sponsor_current,
  purpose_approved_or_ended,
  identity_state_verified,
  active_sessions_zero,
  credentials_revoked_or_transferred,
  effective_access_matches_decision,
  runtimes_and_schedules_match_decision,
  pending_effects_resolved,
  data_disposition_approved,
  downstream_accounts_reconciled,
  costs_closed_or_transferred,
  continuity_tested,
  critical_exceptions_zero
])

This is intentionally stricter than “directory account disabled.” It also avoids the opposite error: deleting evidence too early. A retired agent can be unable to authenticate while its audit trail remains under approved retention. Record states separately: runnable, authenticating, authorized, scheduled, storing data, billable, retained, deleted, and legally held.

Use independent evidence for each condition. The executor's success message is one observation. The verifier should query authoritative state, attempt negative authentication where safe, inspect schedules, compare downstream grants, and validate the fallback. If a vendor does not expose session or deletion evidence, close the item as an accepted exception only through a named risk owner.

Failure modes to design into the runbook

A global “disable all agents” control can be necessary in an emergency, but Microsoft warns it can break product experiences and push teams toward less visible service identities. Prepare targeted containment before the incident: individual identity, blueprint, connector, runtime, credential, network, and tenant controls with known dependencies.

Pilot the lifecycle on existing low-risk agents

Begin with ten to twenty agents that have bounded read or draft authority. Do not wait for a leaver. Run simulated mover, sponsor departure, inactivity, incident, vendor termination, and planned retirement events. Measure whether the graph resolves every linked object, whether named owners accept tasks, and whether closure evidence arrives before the deadline.

Track orphan rate, agents with human credentials, sponsor coverage, backup-sponsor coverage, direct grants without expiry, median transfer time, session-revocation time, runtime-shutdown time, downstream mismatch rate, state-disposition exceptions, cost leakage, failed negative tests, reactivation count, and critical exceptions. Segment by risk tier and vendor; one high-risk orphan should not disappear inside a good average.

Set stop rules. Pause onboarding of new agents if the inventory cannot resolve identities to runtimes, if HR events do not reach the lifecycle queue, if direct grants evade expiry, if stale sessions survive disablement, if required records are deleted, or if no qualified sponsor accepts transferred accountability. Expansion follows repeatable closure, not the number of agents created.

FAQ

Why should HR participate in agent identity governance?

HR provides authoritative worker lifecycle events. Those events can invalidate sponsorship, approval authority, escalation paths, cost ownership, or delegated access. HR triggers and verifies the people-side event; IAM, IT, security, business, privacy, records, and finance owners perform their respective lifecycle controls.

Is this the same as permission change control?

No. The existing AI Agent Permission Change Control guide evaluates one proposed capability change. This workflow governs the whole identity and operating graph when the sponsor, purpose, activity, risk, vendor, or agent lifecycle changes.

Can SCIM fully offboard an AI agent?

No. SCIM standardizes identity lifecycle operations across domains. It does not authenticate, authorize, stop runtimes, revoke every delegated token, delete memory, reconcile costs, or prove downstream closure. Use it as one transport and verify the rest independently.

Should sponsor transfer be automatic?

Automatic transfer can prevent an orphan, but it should start a time-bounded review. The successor must understand purpose, risk, access, data, dependencies, costs, and incident duties before accepting long-term accountability.