Governance and lifecycle for agent identities

Why this matters

Agents multiply faster than humans. Left ungoverned, you end up with hundreds of "shadow agents" — created by a departed dev in Copilot Studio, running against production data, with no owner. Microsoft's governance surface for agents is deliberately built to prevent that pattern by borrowing every mature Entra ID Governance construct (sponsors, access packages, lifecycle workflows, access reviews) and extending them to agents.

Cross-ref: Module 9 (Governance + compliance) covers the framework side (EU AI Act, NIST AI RMF, ISO 42001). This lesson is how Microsoft implements the identity-lifecycle half of those obligations inside a tenant.

Learning objectives

1. Set up the sponsor + owner model that gives every agent an accountable human.
2. Use access packages to grant time-bound, reviewable access to agent identities.
3. Configure lifecycle workflows so sponsor departures don't orphan agents.
4. Use the M365 admin center agent registry as the operational surface.
5. Detect and remediate shadow agents and at-risk agents systematically.

1. The sponsor + owner model

Every well-governed agent has two humans attached at creation:

Both are Entra user objects assigned to the agent identity at creation. Both are queryable via Microsoft Graph. Both receive notifications.

Sponsor is the more important one for governance — it's the human on the hook when auditors ask "who owns this?" and when the sponsor leaves the org, Microsoft auto-transfers sponsorship to their manager (Section 3).

1.1 Rule: agents without sponsors are broken

An agent with no sponsor is not merely inconvenient — it appears in the M365 admin center's "Agents without owners" tile as a critical risk. Treat missing sponsor as a P2 ticket. In the MTN reference architecture, the Registry service refuses to onboard an agent without a sponsor.

1.2 Sponsor assignment via Graph

PATCH https://graph.microsoft.com/v1.0/agentIdentities/{agent-oid}
Content-Type: application/json

{
  "sponsors": [
    { "id": "alice@mtn.co.za" }
  ],
  "owners": [
    { "id": "bob@mtn.co.za" }
  ]
}

You can (and should) assign sponsors to blueprints too — that becomes the default sponsor for any agent identity created from the blueprint if the creator doesn't override.

2. Access packages for agents

Access packages are Entra ID Governance's answer to "give this principal a bundle of access, on approval, for a bounded time, with periodic review". They already work for users; in 2026 they work for agents.

2.1 What can be bundled in a package for agents

• Security group memberships (which then grant application access, SharePoint site access, etc.).
• Application OAuth API permissions, including Microsoft Graph app permissions.
• Microsoft Entra roles (from the allow-list of roles agents can hold).

Package = "the CRM agent needs: crm-app-users group + Graph Sites.Selected on crm-team site + Directory Readers role, for 90 days, renewable, requires sponsor approval".

2.2 Three ways an agent gets a package

Approval rules configured on the package decide who has to approve. Typical pattern: sponsor + resource owner both approve for sensitive scopes.

2.3 Time-bound + renewal

Access-package assignments have an end date. As the date approaches:

• Sponsor gets a renewal notification (via Lifecycle Workflows).
• Sponsor can request extension (may re-trigger approval).
• If ignored, assignment expires → agent loses the bundled access.

Result: agents never accumulate access silently. They lose it, or a human explicitly renews it. This is exactly the JML discipline you'd apply to humans.

2.4 Configuring a package for agents — quick outline

1. Create the package resource-catalog with the groups / apps / roles to bundle.
2. Create an assignment policy. In Who can get access, choose For users, service principals, and agent identities in your directory → All agents (or a filter).
3. Set approval flow (sponsor / owner / manager, in stages).
4. Set expiration (30 / 60 / 90 / 180 days). Enable renewal.
5. Publish the package.

Now any qualifying agent (or its sponsor) can request it from My Access.

3. Lifecycle workflows — sponsor JML

Sponsors are people; people leave. Entra ID Governance's Lifecycle Workflows for agent identity sponsorship handle the handover automatically.

3.1 The auto-transfer rule

If a sponsor's Entra user is disabled or deleted, sponsorship of all their agent identities is automatically transferred to their manager (the manager attribute on the sponsor's user object).

Consequences:

• There is always a human on the hook.
• Manager gets notifications about the transfer.
• Manager can then delegate, keep, or plan deprecation.

Requirement: sponsors' manager attribute must be populated. Enforce it via HR sync or a Lifecycle Workflow that blocks user creation without a manager.

3.2 Notification cascade you can configure

Off-the-shelf Lifecycle Workflow tasks that are relevant for agents:

• Notify cosponsors (Notify cosponsors of change in agent identity sponsors) — 60/30/15 days before a sponsor's leaving date.
• Notify manager of impending sponsorship (Notify manager about upcoming agent sponsorship) — before the transfer.
• Post-transfer confirmation to the new sponsor.
• Trigger an access review on the agent identity when sponsorship transfers (optional but recommended).

3.3 Access reviews for agents

Periodic (every 6-12 months) access reviews that include agent identities. Sponsor attests: "yes, this agent is still needed and still correctly configured" or "no, deprecate". If sponsor doesn't respond, escalate to their manager; ultimately auto-deprecate.

This is straight ISO 42001 A.6 (AI system lifecycle) evidence at audit time.

4. The M365 admin center agent registry — daily driver

The Agent registry in the M365 admin center (Agents > All Agents > Registry) is where operators live. It aggregates every agent visible in the tenant — Microsoft-built, ISV-partner, published-by-org (LOB), and shared-by-creator.

4.1 Top-level counters you must monitor

4.2 Filters and views

• Status — enabled / disabled / pending review.
• Publisher type — Microsoft / external partner / published by org / shared by creator.
• Channel — where the agent is exposed (Copilot, Teams, Outlook, SharePoint, M365 apps).
• Platform — what built it (Copilot Studio, Foundry, Bedrock, custom, etc.).
• Data source — embedded knowledge / fine-tuned model / neither.

The filter surface answers "what agents are running in Teams from Copilot Studio with fine-tuned models?" — the kind of question compliance asks.

4.3 Registry actions

• Refresh / Search / Sort — obvious.
• Export — CSV of all agents (feed into your CMDB, compliance evidence).
• Add agent — upload a manifest .zip for LOB agents.
• Manage pinned agents — controls prominence in user-facing surfaces.
• Block / delete on a per-agent basis.
• Custom view — column selection for daily ops.

The registry is your operational governance surface. Access packages + lifecycle workflows are your policy governance surface. Use both.

5. Shadow agents — the anti-pattern to detect

A shadow agent is any agent in the tenant that has one of:

• No entry in the Agent 365 agent registry.
• No owner assigned.
• No Microsoft Entra Agent ID (running as a plain service principal).

These agents bypass every governance control you've built. They're marked Critical in the Agents at risk view.

5.1 How they appear

• A developer creates a Copilot Studio bot with automatic Agent ID assignment turned off.
• A team spins up a LangChain agent using a plain M365 service principal in a subscription.
• A user creates a shared agent in Copilot; the user then leaves the org.
• Someone tests an ISV agent from AppSource, never registers it, forgets to remove it.

5.2 Detection

• The M365 admin registry surfaces them via Unmanaged agents and Agents without owners tiles.
• Weekly Graph query: enumerate agentIdentities vs enumerate servicePrincipals where any activity in the last 30 days matches AI-agent-shaped patterns (calls to Graph AI endpoints, model APIs). Diff the two — anything acting like an agent but not in agentIdentities is suspicious.
• Purview + Defender correlate their own signals; if either flags an unknown principal touching sensitive data, treat as shadow.

5.3 Remediation

1. Identify — from admin center or Graph query.
2. Block the agent (registry action) to stop further activity.
3. Reach out to the creator (if still in org) or their manager for context.
4. Either: migrate to Agent ID (create blueprint + agent identity, hook the code up) OR delete.
5. Post-mortem: how did it slip through? Usually it's an off-by-one policy — e.g. Copilot Studio setting not enabling auto Agent ID assignment tenant-wide. Fix the policy.

Enable auto-provisioning of Agent IDs for Copilot Studio agents (preview) in Power Platform admin — one setting that eliminates the most common source of Copilot-Studio shadow agents.

6. "Agents at risk" — cross-platform view

The Agents at risk tile on the M365 admin center Overview page aggregates high-severity risk from three security platforms:

The tile surfaces the top three highest-aggregated-risk agents so ops can prioritise. Clicking through opens the filtered registry.

Per-agent, the security flyout (from the Risks column) shows:

• Total aggregated high-severity risk count.
• Per-signal-source breakdown.
• Review link into the source portal (Defender / Purview / Entra) for full investigation.
• Block button for immediate kill switch.

Note: the Risks column shows only high-severity risks. Low + medium risks still live in the source portals — build a habit of also checking Entra ID Protection (Lesson 10.6) and Purview Insider Risk directly.

7. Sponsor management via self-service portals

Two portals for humans (not admins):

• My Account (https://myaccount.microsoft.com/) — sponsors/owners see their agents, can enable/disable, view activity + access, trigger deprovision.
• My Access (https://myaccess.microsoft.com/) — sponsors can request access packages on behalf of their agents.

Rule: teach sponsors these portals. They're the ones responsible; if only admins can act, sponsors won't.

8. End-to-end governance checklist for a new agent

Use this at onboarding review:

• Blueprint created with descriptive name + tags + verified publisher.
• Blueprint uses managed identity + FIC (no client secret in prod).
• requiredResourceAccess declares actual needs; inheritable list is intentional.
• Sponsor + owner assigned; sponsor's manager attribute populated.
• Custom security attributes stamped (Environment, BusinessUnit, DataSensitivity, RiskTier).
• Conditional Access policy verified via report-only.
• ID Protection CA "Block High Risk" template applied.
• Access package created for any recurring high-value grants.
• Access review scheduled (6 or 12 months).
• Registered in M365 admin center registry (not shadow).
• Sign-in + audit logs forwarded to SIEM.
• Runbook exists (deprecate, incident response).
• Sponsor knows they own it (in writing — email confirmation).

Save this as your "agent go-live gate" template. Any agent that fails a checkbox does not ship.

9. Common pitfalls

1. Manager attribute missing on sponsor — auto-transfer breaks silently. Enforce at HR sync.
2. Access package with no expiry — defeats the purpose. Always time-bound.
3. Ignoring the "Unmanaged agents" tile — that number should trend to zero, not grow.
4. Sponsors who never open My Account — reminders + training. If a sponsor never engages, escalate to their manager.
5. Deleting a risky agent before investigation — you lose audit context. Block first, investigate, then delete.
6. Access reviews scheduled but nobody attests — configure fallback (auto-remove access, auto-notify manager) and stick to it.
7. Publishing multitenant blueprints without a governance model for the customer — you're offloading policy to them; provide a security baseline recommendation.
8. Registering agents in the admin center registry but never using access packages — you have visibility but not enforcement. Both matter.

10. Hands-on lab (3 h)

1. In Entra admin center, create a Lifecycle Workflow template that fires when a sponsor is disabled: notify their manager, transfer sponsorship, kick off an access review on all their agents.
2. Assign a sponsor + owner to two of your test agent identities.
3. Populate the sponsor user's manager attribute.
4. Simulate the sponsor leaving (disable the user). Verify:
   • Sponsorship auto-transfers to the manager.
   • Manager gets a notification (check My Account).
   • An access review appears in the manager's queue.
5. Create an access package bundling Sites.Selected + a security group + a directory role. Set policy: "For agents", requires sponsor approval, 60-day expiry.
6. As the (new) sponsor, request the package on behalf of the agent from My Access. Approve. Verify the agent gets the group + permission.
7. Manually create a "shadow" test agent (plain service principal, no blueprint, using an M365 API). Observe it appear in the "Unmanaged agents" tile.
8. Block that shadow agent from the registry. Confirm access packages / policies also refuse it.
9. Run an access review; complete it as the sponsor for one agent (keep) and skip another (auto-deprecate).

11. Self-check

1. What does Entra do when a sponsor's user account is disabled? What attribute must be populated for this to work?
2. Three ways an agent can be granted an access package. Which requires human approval?
3. What does the Unmanaged agents counter mean in the M365 admin registry?
4. Name three signal sources aggregated by the "Agents at risk" tile.
5. Which portal do sponsors use for self-service (view / disable / request access)?
6. Give three items on the "agent go-live gate" checklist.

12. References

• ID Governance for agents
• Access packages for agent identities
• Agent sponsor tasks in Lifecycle Workflows
• Agent registry in M365 admin center
• Manage owners and sponsors of agents
• Vendor-neutral Lesson 9.1 — Governance + compliance frameworks.
• Vendor-neutral Lesson 1.2 — Identity models for agents (the registry pattern).