AI agent identity lifecycle: access, review, and offboarding

Expected outcome

At the end of this guide, an AI agent has a traceable non-human identity instead of an inherited human account, a shared production secret, or an unnamed service connector. Its operator can answer five practical questions: what job the agent performs, who owns the job, which sponsor accepts the access, which resources and actions are allowed, and how the organization will remove access when the job changes or stops.

This is an implementation guide, not a general AI-governance framework. Start with the surrounding AI governance tooling guide when the organization has not yet agreed on its governance model. Use this method when an approved agent needs a concrete identity, permission boundary, review loop, and offboarding path. Microsoft Entra describes identity governance as lifecycle and access governance; its agent-identity material adds a human sponsor accountable for purpose, lifecycle decisions, and access reviews. That is a useful operating pattern even where Entra is not the chosen identity system.

The result is deliberately modest: a bounded record, evidence, and repeatable lifecycle. It supports governance but is not legal advice or a compliance certification. A complete program can still need privacy review, procurement review, records retention, threat modeling, and controls specific to regulated data or critical operations.

Prerequisites

Name an accountable owner and a distinct sponsor before issuing credentials. The owner operates the software and responds to incidents; the sponsor confirms that the purpose and access remain justified. One person can hold both roles in a small team, but the fields should remain separate so a handover is explicit. Avoid treating a manager’s approval in a ticket as a durable substitute for either role.

Define one bounded workload: for example, “summarize approved support cases in the staging tenant” rather than “help support.” Record the environment, the inputs, every target system, the allowed operations, data classification, and prohibited operations. This work complements the action tiers in the agent approval workflow guide: an identity can authenticate an agent, but it does not make a sensitive write safe to perform without the required human approval.

Choose an identity mechanism appropriate to the deployment. Microsoft notes that client-credential flows authenticate a service as itself and that app-only permissions are granted directly to the application; because no user is present, the resource must enforce the application’s authorization. Prefer short-lived workload credentials, federation, or certificates where the platform supports them, and keep any secret in an approved secret store rather than source code, prompts, browser storage, or a shared document. SPIFFE provides one example of a workload-identity model that separates workload identity from a person’s login.

Finally, establish an evidence location with restricted access: a change record, ticket system, identity-governance platform, or versioned operations repository. The system must retain the identity register, approvals, permission changes, review decisions, credential references, suspension records, and retirement proof without copying the credential itself.

Workflow

1. Register the proposed agent before creating it

Give the agent a stable ID that is not a display name. Tie it to one workload and environment, such as agent-case-summary-prod, rather than a generic ai-service. Capture the register row first, assign an owner and sponsor, and attach the architecture or approval record. This makes shadow agents visible before credentials make them durable.

2. Issue a dedicated identity and minimal permissions

Create one non-human identity per independently governed runtime boundary. A development agent and a production agent need separate identities, secrets, limits, audit streams, and revocation paths. Start with read-only access where possible. Grant a narrow API role, an allowlisted resource, or an application scope that maps to the documented job; do not grant a broad directory, storage, or connector role merely because a library’s quickstart requests it.

Least privilege is not a one-time checkbox. NIST zero-trust guidance treats access as a continually evaluated decision rather than a location-based assumption. In practice, confirm the workload identity, target audience, tenant or account, request origin, resource, action, and expiry at the enforcement point. If an agent needs to call a tool, bound the tool’s own capability independently from the model’s instruction text. The AI tool permissions guide is the companion design reference for that application-level boundary.

3. Bind credentials to the runtime, not to a developer

Store only a credential reference in the register: vault path, federation configuration ID, certificate subject, or managed-identity name. Do not paste token values, private keys, or client secrets into the register. Set an expiry or review date, record the rotation owner, and test that the runtime can start with the intended credential. Confirm that a revoked or expired credential fails visibly and that logs reveal the identity without revealing the secret.

For an app-only OAuth pattern, validate both the issuer and the application identity or role at the resource. Do not assume a successfully issued token proves authorization. Microsoft’s client-credentials guidance explicitly distinguishes obtaining an application token from the resource’s responsibility to apply permission checks.

4. Review on a calendar and on lifecycle events

Run a recurring access review that asks the owner and sponsor whether the purpose, deployment, resources, action list, and credential path still match the register. Microsoft Entra’s governance overview describes recurring access reviews and time-bound access patterns; use the cadence that fits the risk and change rate rather than borrowing a universal interval. A stable read-only internal retrieval agent might receive a less frequent review than an agent with production write tools or customer data.

Event-driven review matters as much as the calendar. Trigger it when a sponsor departs, an owner changes, a new data source or tool is added, a model changes behavior materially, the agent moves environments, its credential is exposed, or an incident occurs. A sponsor change should pause expansion until the successor accepts the recorded purpose and access. Update the register, approvals, and contact path together; a replacement name without a new acknowledgement is not a completed handover.

5. Rotate, suspend, and retire deliberately

Rotation is a planned change: issue the new credential or federation binding, verify the intended runtime, cut over, revoke the previous credential, and attach evidence. Never treat a secret-store version increment as proof that the old credential is unusable. Confirm logs, access reports, and a negative test where feasible.

For an incident, execute suspension before diagnosis if continued access could increase harm: disable the identity, revoke active credentials or sessions, stop queues and scheduled jobs, preserve relevant logs, and notify the owner and sponsor. Decide whether a narrower recovery is justified only after the incident record identifies affected data, actions, and dependencies. The enterprise AI assistant governance pilot offers a useful staging model for keeping early deployments narrow while evidence is accumulated.

Retirement is not deleting a name from a dashboard. Disable the identity, revoke credentials and delegated access, remove group and application-role assignments, stop scheduled invocations, delete or archive configuration under the applicable retention policy, and verify that the agent cannot authenticate. Preserve offboarding evidence: the date, operator, revoked grants, credential versions, final review, affected systems, and any remaining records or exceptions. Close the register row only after those checks are complete.

Reusable template

Use one record per identity and keep links to authoritative systems rather than duplicating sensitive values.

Field	Record	Decision test
Agent ID	Stable non-human identity and deployment boundary	Can logs, permissions, and retirement evidence be joined to it?
Owner	Named operational responder	Who handles failures and rotations?
Sponsor	Human accountable for purpose and access review	Who can confirm the agent should still exist?
Purpose	One bounded business or technical job	Is the description specific enough to deny unrelated work?
Environment	Dev, test, production, tenant, and region as relevant	Is it isolated from higher-risk environments?
Credential location	Vault reference, federation binding, certificate subject, or managed identity	Does the record avoid exposing the secret itself?
Permitted resources/actions	Explicit APIs, data sets, roles, tool calls, and denied actions	Is every permission necessary for the stated purpose?
Review date and expiry	Next scheduled review plus time-bound access where used	What happens if review or extension is missed?
Change and rotation record	Approval, credential version reference, validation, and revocation proof	Can an operator prove the old path was removed?
Suspension and offboarding evidence	Incident suspension ID, final disablement, revoked grants, and residual exceptions	Can the organization show that the agent no longer authenticates?

An issuance checklist can be recorded as: register approved; owner and sponsor confirmed; environment isolated; least-privilege grants tested; credential reference recorded; logging enabled; review date scheduled; and suspension/retirement runbook linked. Treat any numeric service-level timing in a local checklist as an organization-specific example, not an industry standard.

Failure modes

• Shared service principal: several agents and humans use one credential, making attribution, review, rotation, and targeted suspension unreliable. Split the identity before adding scope.
• Sponsorless automation: a team creates a useful agent during a pilot, then the original requester leaves. Freeze changes and assign a sponsor before the next review date.
• Permission creep: a narrow retrieval agent gains export, write, or administrative scope “temporarily.” Record the change, require explicit approval, set expiry, and test revocation.
• Secret copied into configuration: the register points to a ticket comment or repository value instead of a protected store. Revoke and replace it; do not merely redact the display.
• Review theater: reviewers see a long permission list without the actual purpose, evidence, or action boundary. Present the register and recent access evidence together so a reviewer can decide.
• Incomplete incident response: the scheduler is stopped but the credential remains valid. Suspend both execution and authentication paths, then verify denied access.
• Offboarding without proof: a dashboard object is deleted while downstream roles, cache entries, tokens, or queue messages remain. Require the final negative authentication check and a recorded exception for anything retained.

Acceptance criteria

Before treating an agent identity as ready, verify all of the following:

1. The register has a unique agent ID, owner, sponsor, purpose, environment, credential location, permitted resources/actions, review date, expiry, and offboarding-evidence fields.
2. The deployed runtime uses its dedicated identity, while development and production do not share credentials or broad roles.
3. A resource authorization test proves the allowed action succeeds and a prohibited action fails. A token alone is not sufficient evidence.
4. Logs correlate work to the agent ID and omit secret material; the owner can locate the relevant approval and change record.
5. A scheduled review and event-driven review triggers exist for sponsor changes, scope changes, rotation, and incidents.
6. A non-production suspension and retirement exercise proves that access can be disabled, revoked, and evidenced without relying on an individual developer’s memory.

Next step

Run the template against one existing production or near-production agent before creating a catalog-wide policy. The first pass usually discovers shared credentials, undocumented tool scopes, missing sponsors, or environments that need separation. Then connect the identity record to the system’s approval, audit, and incident processes. For tool-using workloads, follow the MCP security checklist to validate connector authorization separately from the identity’s initial issuance.